Separate windows - ideas, anyone? :)

Following on from the "we want separate windows" threads, and the "chats to their own windows" comments, I am working on implementing a "filterable window(s)" idea into MUSHclient.

Before I get too far down the track, some feedback would be helpful about what aspect you, the player, *really* want these to achieve.

You can already have separate windows for chats using the internal notepad idea, but I gather that this does not totally solve the problems we are trying to solve.

At this stage, the separate windows are planned to be:

• Independent windows which can be moved, resized etc.
  
• You can have any number, per world.
  
• They will be fast.
  
• Each one will be tied to an open world (eg. they might show chats for a session)
  
• They will show text in colour (the same colour as arrives from the MUD)
  
• You can add to them in scripting, specifying the colour of the text to be shown.
  
• They can be any length (you specify), eg. 10,000 lines.
  
• You can specify a "wrap column", eg. column 80
  
• When they fill up they will automatically discard the early lines, like the output buffer, so they will not eventually fill up and stop, or slow down.
  
• You can specify in scripting where each one is (in pixels) so you can have various windows (eg. chats, inventory, status information) at pre-determined places on the screen.
  
• You can "feed into" them from triggers, aliases and timers, with a new "send to" option.
  
• Various script routines will let you manage them, eg. clearing their contents (for doing a new inventory), closing them, moving them, etc.
  
• You can specify the font (eg. Lucida Console 18 pt)
  

A simple example would be to make a trigger that catches "tells" or "chats", like this:


Match: CHAT: *
Send: %0
Send to: Pane
Pane name: Chats


If you have any ideas or comments now would be a good time to make them. Possible extras might be:

• Multiple fonts per window (eg. a different font for chats rather than tells).
  
• Background picture (eg. your inventory could have a picture of a bag in it)
  
• Logging the contents of these windows as they are written to (eg. a log of chats from the chat window)
  
• Copy from the window (click and drag, then Ctrl+C)
  
• Possibly different styles (eg. no title bar, no scroll bar)

At present I am envisaging that these windows will still be "child" windows of the main MUSHclient window. I am not a big fan of programs that stick extra windows all over the place, thus they would still be clipped to whatever space you have allocated to MUSHclient (of course, this can be the whole screen).

I am also not expecting the windows to be "split" windows with input areas, they are basically extra output windows.

I think that the main reason people want external windows is so they can keep them on top of others so they will be notified of tells or whatnot, so I think the window should have the ability to be spawned externally, perhaps being transparent/clickthrough in XP/2k... Other than that, the window is a great idea. Some people may want to change size, fonts, etc, RTF-style, but I'm against having external RTF windows for the reasons we've discussed many times before (speed, coding, etc). If anyone wanted anything like that they could still use my window on top of MUclient's built-in windows.

How about an "always on top" option? Not ontop of Other programs, just ontop of everything in MC. So that one could maximize their world inside MC and then have a window ontop of it, in the corner or whatnot.

Of course, upon writing this, I began to wonder how you would determine order if multiple windows were "always ontop". Some method of preference would have to be established, whether it was an "order" or layer type thing, with conflicts on the same value being solved by... who knows what, or some other method entirely.

Hmm.

On your main list: All features.

Though.. One minor issue. Merely positioning the window is not enough, you need to be able to set its size as well. Otherwise it will open in the place you want, but with a indeterminate size, possibly of the edge of the screen. This is especially bad if it tries to auto-size itself to the number of lines you ask for, which could end up taking up the entire available space, instead of just showing say 20 lines at a time. Some way to read these things as well would be useful, since then the positions could be saved for later use through an alias.

Or... If you where to implimented an event manager like in the other forum thread, moving or changing the size could signal to plugins and/or the main script that the size or position changed and let the plugin automatically retrieve and store the new location and size. In an case, at minimum you need to know how big and where the window is from in the script, as well as setting it somehow from the same.

On the second list:

Maybe - Multiple fonts per window (eg. a different font for chats rather than tells).

Nice idea - Background picture (eg. your inventory could have a picture of a bag in it)

Absolutely - Logging the contents of these windows as they are written to (eg. a log of chats from the chat window)

Absolutely - Copy from the window (click and drag, then Ctrl+C)

Maybe - Possibly different styles (eg. no title bar, no scroll bar)

If I am feeding the stuff to a window, I am absolutely going to want to log it. The point is to get stuff out of the main window that otherwise interferes with playing and placing it into a window by itself. I wouldn't however ever want to lose this from a log, just because it is being sent to another window. That would be really pointless. Same with copying from it. You may want to copy a line from chat and post it to a tell, without the ability to copy and paste....

For styles... A mini title bar, like you see in things like Paintshop Pro would be nice, but if you lose the title bar, then you also lose the ability to close it easilly. The scroll bar however should imho stay. A mini bar uses the absolute minimal font size for the name and control buttons that are 1/2 the size of normal, so that it takes up 'only' as much room as needed, instead of wasting all of the space a full bar requires.

Multiple fonts would be nice, but not necessary. It would be helpful to seperate stuff out in some cases, but until such a time as the <font> tag is also supported in Mushclient itself and it becomes silly for it to not also exist in a seperate window... For now, it would be really nice in some cases, like someone using a custom font for output from a plugin.

As I recall, some people who have requested this feature would like to have separate command boxes for each window.

Oops, missed the last line of your post.
Perhaps you should reconsider. Indeed, if each 'child' window had it's own auto-say setting, then it might be much easier for people to just type away in one of these subwindows.

I can imagine this being especially useful for the chat plugin, snooping someone and commanding them. With auto-say on, and set to command <player>, this would be very convenient.

Wouldnt multiple fonts get messy (laggy, bloated, etc?)
I mean, sure change a font for a window, but mutliple fonts within the same window? Shrug, maybe Im remembering this wrong. But, I know we dont do it in MC for this reason.

And yeah, we would need some way to determine placement AND size for windows. However, pixels might not be good, unless you can also return the width of... their screen? the MC window itself? Something, for portability in plugins. As long as were not using twips.
Perhaps percentages or something, no I dont think thats anygood? We just need to make sure we dont make it too difficult to program windows within distributed plugins. Obviously it would be the total screen? And not the MC window. But perhaps we can have a function to return the width of the main MC window as well. Since that way you can deal with MC windows that arent maximized. Hmmm, with this will we be seeing world resizing programatically?
In a nutshell, pixels yes, but also need to know the width(s)/height(s) of our environment.

And yeah, I agree, some lite version of a titlebar. And probably no bottom bar? I guess those could be options.

I guess the next question going to be, are all these things going to be accessed as object properties (Object oriented)? Or just like triggers/etc with a function that asks for a Window Name?

Now that I read magnums post:

I disagree, theres no real reason to have other command windows. Most people just want a second window they can throw output to. Snooping would, have to be done via a plugin (because you cant trigger the world.notes)? Why not then, just open another world for snooping? Thats what I do, just have a world for snooping. And you can still chat in your original window, or otherwise, just connect to the chat world via chat.

Could a toolbar be added like the activity toolbar, in order to easily click and bring the window that has activity to the front in case it does slip behind all the world and notepad windows?

Maybe with customizable icons so that the user could use icons that relate to what they are using the windows for.

Hmm, If these new windows support hyperlinks (MC hyperlinks) then you can just make a window that acts as a toolbar for your other windows/worlds, and can display whatever youd like about the windows and new text.

Different styles sound like a must, especially if you plan to make the extra windows have a status bar by default. I like my external windows as plain as possible - a miniframe with a couple of caption buttons and a thick border for sizing. Anything beyond that just eats up screen space in most cases. Also, being able to both get and set the window sizes and positions from a script sounds like a good idea, perhaps it would be possible to add callbacks for setting/getting the main world window size/position also? Then one could lay out the windows programmatically and rearrange them on the go as needed, without having to fumble with the mouse each time. Suppose I wanted a window to filter chat/tells/says/etc. to be up at all times, but I also wanted another window for sending certain text to in a situation when I want the main output window to display as little non-essential information as possible (i.e. when fighting), then I could bring up the 'fighting' window and resize the 'chat' window to accomodate for a new arrival from a script, and when done purging adrenaline I could kill the 'fighting' window and make the 'chat' window take up all available space again.

Actually.. In terms of font, I was thinking of use with specific types of data, not streamed along with the other contents. It also isn't quite a relevant for a secondary window, since the main window will still run as fast as before.

As for an input option. This is something other clients do provide in some of them. It is useful if you for some reason want to respond to chat or channel traffic, but for what ever reason can't have the main Mushclient window visible. Being able to quickly click over to a 'always on top' window and send someone a response, while still viewing a web page they just told me about would be useful in some cases. There are likely to be other similar situation where simply displaying the text is of minimal use.

However, being able to turn off features you don't need is a must, so allowing you to disable the input box when not needed is good. The real question is is the input should go direct to the mud from there or be handled some other way, so you can send it where you need it to go, like a callback to the specific plugin that created it.

I do agree with Flannel about how it is generally easier and less confusing to access functions through object properties, instead of a mess of world.this, world.that stuff. A seperate function like:

MyWindow = World.NewWindow
MyWindow.Width = 500

would be a lot easier to deal with than
world.createwindow "somename"
world.setwindowproperty "somename", "blah", blah

Imho, this method of using setproperty and other non-object like features gets out of hand quite rapidly and some of the extra stuff you have to do to use them is confusing, especially if you are trying to remember all the insane 'non-optional' stuff you have to give the client to make it work, especially the moment you decide to extend the capabilities of triggers or these new windows and suddenly have to remember not only the mess of junk you need to just create one in the first place, but also what 'option' you need to change/set to get the new features.

This is one thing you didn't plan too well. ;) It would be nice I think to see this new feature a bit more friendly, even if you do:

World.NewWindow(<Name>)
World.Window(<Name>).Width = 500

Which frankly makes a bit more sense anyway, since it makes it obvious that Mushclient controls it and not the script.

I agree, the object oriented thing came into mind when thinking about world.[etc], If/when Nick sets up resizing/moving the world windows, it would be logical to use world.width or [window].width. Eh, Im short on time, that explination will have to do.

As for the input, Shadowfyr, Nick said he wasnt planning on letting it be always on top (of other applications) so, the input sort of becomes moot. Unless Im missing something.

Not planning to have it and having it, because not having that option makes it less useful, are two different things. That's the whole point of feedback. ;) Problem with MDI is all the windows get in each others way. The problem with non-MDI is it is often difficult or impossible to keep track of where all the damn windows are. Having the option to force them to the top can be a god send, at least unless you are using something like:

http://www.hamar.sk/sphere/
Screen shots> http://www.hamar.sk/sphere/screenshots.htm

However, as sort of Cowboy Bebop-Ed's Computer this sort of is, the inactive windows are static I think, which still doesn't solve the problem of both a) knowing where they are and b) knowing what is going on in them. It is kind of nice to do both. ;) Of course, I may be wrong about them being static.

I'd like to second (third?) the idea of placing windows in objects. It would make more sense to do:

world.Note ("Hello world")
world.ColourNote ("red", "white", "Hello world")
chat.Tell ("Hello world\n")
chat.ColourNote ("red", "", "Hello world")

than using callbacks. I don't know about world.chat.Tell though - it might seem more logical from the syntactical point of view, but why get obsessed with syntax in liew of clarity of use? ;) As for the options of having an input field and setting windows to stay on top, I think the more features the better. Though those aren't exactly essential and if they don't appear from the very start of this new feature then I won't cry over it.

Shadowfyr, I hope youre not using spherexp. Its absolutely horrid with the current version, or was when I fooled around with it... a while ago. But its just wrong with the current interface. Needs headgear and a glove or something.

Anyway, I would have to agree. Having the option to make windows semi-independant of MC would be useful in certain situations. ie being able to minimize MC and still have it shown.
Its extremely useful for windows with input. And perhaps with a status type thing, that you can use to relay info while looking at another window.

I would say if we were to have other windows, they wouldnt have taskbar items. They would still be children. I suppose if theyre independant of MC being restored (ie if they were able to be always_on_top) then they wouldnt be restrained to MCs dimentions.

Yeah, I agree with Flannel completely. Even with SphereXP :p It's a great idea with a horrible implementation... For MC windows, there should ideally be an option to have the window be "internal" or "external"...

The point of making a toolbar is to be able to bring the windows to the front easily. Making another window would not solve this problem because that window could just as easily get lost behind world windows and notepad windows. I play with MUSHclient maximized and all the worlds maximized. Maybe put the toolbar on the Separate window, then only have the one window, that has ALL of the extra windows inside of it. This would avoid useless clutter on the screen. The activity toolbar works great already, it shows when connected, new activity or even when a world is loaded by changing color. A separate window will be custom to the player, so the ability to customize the toolbar to have maybe a letter instead of a number would be utilizing something that is already known to work. Utilizing the toolbar would also help retain MUSHclient's look.

And as for I think they all are great and would love to see them all added, but I had to pick only one to be added it would be

And if this separate window thing goes bust and doesn't work I'd like to see the ablitity to have more than one logfile per world, then I could just log my chats instead of having to create these little windows in the first place.

I would like the ability to have these extra windows in a tabbed interface, with a keyboard shortcut to move between them for each world.

Also, please make sure the matching trigger can match on multiple things...I really like in DAOC how I have tells and says in one window, and more broad messages in another for instance. Also there are muds where the chats have a different format for the current player vs all other players:

You -chat- something.
Someone else -chats- something.

Ugh... Until Nick fixes the, "Whoops! Somehow I forgot the size of all your worlds/windows", we don't need more MDI's But beyond that, not everyone uses Mushclient maximized. I don't for several reasons - 1) external editors and notepad, the internal one requires changing the size of the world window or buries it, neither is a good thing imho. 2) A looping traceroute/ping setup I wrote using QBasic, so when I get a lot of lag I can see if it is a router to the mud or some clown admin doing a global search for something 'on' then mud. I can also see when any network lag stops and I can play safely again. 3) Anything else I can manage to fit in the space to the right of the client, including the firework gadget I made for Mushclient that is designed to return the size of the desktop and of Mushclient and sandwitch itself in the space available.

Personally, the fact that Mushclient's Notepad and other windows are MDI is bad enough, I don't need something else cluttering up the inside of the Mushclient window, at least not unless it used a more advanced solution, like remembering how they where tiled and which ones I wanted to have appear with the world window, if any. Even then, I at least would find it seriously annoying. But then, I always suspected that people who use something often enough get used to the screwy interface, which btw probably explains Linux Gimp. lol

<Rant> Floating tools = good thing, Image windows that resize themselves to bury those tools and the other images, so it is hard to switch between them = bad idea. A MDI where most tools are in a single out of the way row to one side, you get 90% of the desktop to work on the image in, movable tool options float over the current image and your menus are always visible makes sense. Gimp steals like 60% of your work space with windows containing all the crap that should only be visible when the mouse moves over it, not when you get desperate and start hunting for the option to make it visible, and they should never disappear under the image you are working on, let alone hide it from you, both of which is equally stupid.<End Rant>

Anyway. The point of having windows or even toolbars with 'minimal' profiles is to stack them in a way that is useful. If you are layering windows one on top of the other, so they bury each other, then you are using them wrong in the first place. If the program forces you to do this, then... that's a design defect. Heck, a simple toolbar to switch between worlds could be an icon sitting in one corner of the desktop that changed color, blinked, stuck its tongue out at your, etc, when activity happen, then when you moved your mouse over it, expanded to show a full bar with buttons and the current state of every world, just click on the one indicating activity. **Minimal profile**, so they do what you need, without always getting in the way. Think outside the box, instead of trying to make everything look and act like one, then wondering why the big box you stick them in looks crowded. ;)

I think the idea is to have extra windows plus to the main world window, not extra windows underneath the main world window. To rephrase Shadowfyr - if you have to stack those extra windows on top of each other then you are either doing something wrong, or if the program forces you to do it that way, then there's a problem with that program. Instead of stacking windows there should be a way to hide/show, size, and position them dynamically, which will allow you to change the layout without having to live with more toolbars, buttons, tabs, whatever.



You can already do that using multiline regexp triggers.

You can already do that. Triggers, and then write to file.



I think it was more along the lines of, you can currently do that either with multiple triggers, or many regexp's that are piped (|) together.



As for the "toolbar" world idea, Nick would probably have an ability to keep a window ontop. So this new window wouldnt get lost.

And I think the activity toolbar is plenty cluttered as it is. We always get requests to make it include pictures, or have 3.452 X 10^42 buttons, or whatnot, which really are more trouble than theyre worth. Although I will say If I had to pick something, I kind of like shadowfyrs solution. Having them roll out when you click on them etc, like the File menu.

Yes that does seem to be the prevailing opinion in this thread, but just because it is the prevailing opinion does not mean it is the best or that it will meet everyone's needs.



Thanks. So if I have different needs than you, I'm doing something "wrong". That is a good way to argue.

Every MMORPG that I have played has this sort of interface, and I find it very useful.

My opinion on this subject is in this thread: http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=3839

Naturally part of the position would be its height and width.



Can't help thinking you will run out of screen real-estate with lots of windows all with little input boxes under them. Plus, looking a bit funny.



I was thinking of script functions like the other things. Something like:


CreatePane "name", "title", top, left, height, width, flags, textcolour, backcolour




However, maybe you are right. :)



I would expect that multiple triggers could all send to the same window, thus different sorts of chats could all end up together.

---

That's all I have time for at this moment, will comment further later ...

I understand that not everone uses Mushclient maximized, but do you understand that not everyone uses Mushclient like you do? From someone who does use Mushclient maximized I would find this helpful and useful to me.

Just because I don't use them like you doesn't mean I'm using them wrong, it's my preference.

My big box doesn't look crowded to me, I only have one window on the screen at a time because they are maximized.

I also understand that you can make files and call them log files using triggings and scripting. But that requires a lot of knowledge about scripting to get it to check and see if the files exist already and to create a new one for each day or time. Which would be a lot easier if I could use the script functions(LogSend,OpenLog,IsLogOpen, WriteLog, CloseLog) already defined in mushclient to make these files of specific information from the world and to continue to log everything else into another logfile.

Well, you won't have lost any existing logging.



I'm not sure what the difference really is. If you make the MUSHclient window large, or maximised, then they are not really "cluttering up" the screen any more than they would be if they were not clipped to the MUSHclient frame. You only have so many pixels on the screen, however you look at it.



Not necessarily. I never could get the Activity window to stay on top. Sometimes the libraries I used have their own ideas. Anyway, with (say) 8 worlds, all of which had 5 extra windows, do you really want them all "on top"? And which is *really* on top?

I had an idea that maybe when a world became inactive all its extra windows would disappear, to reduce the clutter, but maybe you *want* at least one extra window to stay visible so that you can keep an eye on progress.

How about letting the user explicitely specify certain windows as "always on top" and then treating the rest as child windows of the main world one and hiding them when the world window loses focus? That way you would remove responsibility from yourself for keeping track of what stays on top and what disappears, since that's not something you can plan but should be handled by the user according to his/her requirements. But there should still be a way to quickly hide any window - topmost or not - perhaps by doubleclicking on its caption or hitting a button there.

I already posted this, but Ill repost, it was in the middle of a paragraph or something.



Basically an "order" type thing, much like triggers. Higher (Or lower, for that matter) would appear ontop of other ones with a lower (or whatever) order/sequence/[whatever terminology].

In reply to Norbert>



True. I wouldn't mind if you could have them internally for those that need them, but float them for others. This isn't impossible, though MS probably doesn't exactly make it easy with MFC. Same with Nick's comment about always on top. The most effective way is to use the API to set the zorder to topmost. This doesn't exactly prevent other topmost windows from covering it, but it does prevent it from being covered by the applications own windows "or" most other stuff. But, the key point here is that if for some reason it isn't practical for Nick to make them work both ways...

However, at worst, this would mean maybe have two different window types. One which will work MDI, but others that are more versitile. If nothing else, some people may even be using dual-head video cards, in which case, the maximum space for both a full screen Mushclient 'and' other windows effectively doubles. It also depends on your screen resolution. I use the highest my card can produce, so using a 12 point terminal font (which is fatter than the Lucida), I still end up with 110 columns of text and have 'almost' the full width of Mushclient still available for other windows. I would sort of like to use it for something. ;)

I understand that some people never have more than one thing visible at a time, but for those of us that can, it makes a difference, especially if the window includes stuff like maps, graphics (currently unsupported in Mushclient itself), notes, etc. We need something that solves both problems, not something that basically ends up being a color version of a notepad.

Comments to Nick>



Well.. That is why hiding (disabling it) by default would be useful. You don't want every window to have one, but when you do need it....



More a concern of what happens if you intend to omit the lines in question from the main output. That after all is sort of the point, getting all the stuff you don't need to see in the middle of your RP, combat, etc. out of the way, but still having it logged and visible in the secondary window. I don't log often, so I am not sure what does or doesn't happen to logging with 'omit from output', but as long as it doesn'y also 'omit from log', this isn't a problem. However, the tendency for more current functions to kill the line, then call scripts, etc. can be. The copy of such lines to the secondary window 'must' happen before it it omitted.



True. The key here though is "if you make the MUSHclient window large, or maximised". As I said above, there are two cases where this is a major issue. 1) when you intentionally avoid making the window as big as necessary, so that you can see other programs/windows behind it. My Fireworks plugin requires this. 2) Someone with Dual-head video that may find it more convenient to place some or all of those extra windows on the other display.

While the second is a bit less likely for most people, a lot of us seem to be doing the first, and for the simple reason that some things need to be visible for us 'along side' the client, not underneath it. In general, for what I am likely to use these windows for, I don't need them to be really big and I have plenty of room in that slice of relatively unused screen space. I have 0 room in the client itself.

I also agree with Ked. There should be "always on top" *and* "always visible" options. An 'always visible' would stay if a) you minimize the main client or b) switch between worlds. While those that are merely 'always on top' will simply minimize the moment the client does or you change to a different world. One posibility is to allow the script to decide when and if to minimize/restore the window. That way the script can use loss or gain of focus to decide what windows should remain visible. It could be done both ways, though the ability to hide/show such windows from script is something that could prove good anyway. The main difference between it being an option is that you don't have to worry about minimizing all the ones you don't need to stay visible.

OK, thanks for your comments. As far as possible I'll make little things like that options.

I know this is dredging up an old thread, but I did want to add something:

Not every feature needs to be in this from the start, people. Jesus. I haven't been lurking around here much lately, I admit, but extra windows have been on the wish list for about three and a half million years at this point, and they don't need to do everything from the very beginning. Can't they just exist first, then we can figure out what additional options they need to serve the needs of the users?

Nick, rest assured, some of us will just be happy to have windows that work with colors and automatically empty themselves, as opposed to the Notepad. ;) Toolbars, 'always on top', auto hide... even size and position can be fixed every time you open it if necessary. SimpleMU*'s been able to filter WHO's into separate windows for how many years now, and people want to quibble over specifics? Just get the basics finished first so that those of us who do not care what format they are or what extra-special options they have can use them. Polish later!

(And much extra love for Nick for finally getting to this. Makes me feel positively giddy!)

My window does all that too :( Besides, it's nice to know as much as possible from the start, because later on you may find that a needed feature cannot be implemented in the design you made so far.

Mmm. I love this idea. Personally, what i'd like to use 'seperate windows' for is mostly chats and perhaps pages and other such notices, much like other people..

You see, I have a very large monitor/resolution and keep everything wrapped at 80 characters. Its hard for me to read otherwise, its just 'odd'. That leaves like almost exactly half of my screen blank.

I'd love my <Public> chats to all go into one window up over that big black void. The thing is, i'd like them to have an edit window, whre if I click in there and type, it'll automatically be sent with a '=pub' prepended.

Other windows I wouldn't want this, on verify notices, and everything. So if it were an option that'd rule.

Its veery important to me that these get logged together in the right order, but I'm pretty sure someone said that would be the case.

What would be _really_ neat would be the ability to 'tile' all the child/subwindows of a world within a specified rectangle, so I could just add a window and call 'tile' or something and they'd fill in all that black space. Alas. :)

Problem with most 'tile' commands it that they do exactly that, not dock the window in available space, but rearrange every damn window to fill an equal area. very annoing if that isn't what you intended.

Nice to know someone else does the same thing I do and has lots of extra space outside their main window. With all the negative comments I seemed to get to the idea of external windows, I was beginning to wonder. ;)

That's my setup too, I just haven't found a use for an external window. I just pay attention to the mud output :p

Shadowfyr, theres a lot of us with resolution that makes our characters smaller than three feet tall. Ive been doing the notepad window thing for... a while. Started with just one, now its three. I have to screenshot it while distributing my plugins, since people dont seem to understand what it is Im talking about. But yeah, its common, and I think will be moreso as monitors tend to get larger.

Actually, if we do eventually get scriptability for sizes/etc I think it'll become a lot more common. Much less unweildy for the normal user.

Any updates on how this idea is going Nick?

in my opinion it wouldn't be worthwild to have command prompts for each window.. seems like it would just waste space. Or.. if you really need it, you could have a toggle for whether to display it or not?

one thing that'd really help me with this is if you could just say, World.SetPane "";World.SetPane "You have this affliction that affliction & etc." so that I could ues it with my pk, heh I don't really have a use for any other sort of thing.

I hit a few technical problems with the panes. They drew OK, but it was annoying things like making them go away when the world closed.

The stuff about "you have this affliction" you would do with a small notepad window.

In recent versions you can position notepads, resize them, change their text and background colour. That would make it easy enough to pop up a suitable message window.

And, you could write your own tiling, since you can now find the size of most things as well.

ahh nice, thanks for the idea nick, didn't know I could do that

Also another idea, anychance you could toggle whether or not your notepad windows stay on top (just on mushclient)?

I don't think it can be done. The "on top" is a global thing, not in a MDI frame window.

You can simply resize them to share the window with the world. Put them on a side, and shrink the world window.

Nick, what about when you move the window you also bring it to the front? Just like if you moved it by dragging.
Either that, or add some sort of z direction.

Also, (not nessisarily a new function suggestion) but is there any way to restore/minimize? setting to 0,0,0,0 dimensions to minimize for instance? I guess using that method, you wouldnt have any way to restore. Since you'd be setting a value however you did it. Unless you allowed like 0,0,-1,-1 to be restore or something.
I dont think maximize would really be needed, since it would steal your focus from the world, and that just doesnt seem right.

Umm. Flannel, shrinking the world window and making it 'fit' in the main window is what most of us have been fighting against. We don't want to have to maximize the main Mushclient window just to fit it, since any external applications we try to use with it then get buried behind Mushclient. Applications do manage to have secondary windows on as always on top. Yes, it is a 'global thing', but I don't think it is necessarilly limited only to the applications primary window. If it was, then tool windows, like the ones in Paintshop Pro wouldn't work.

Ok.. Done a bit of hunting... Seems what would be needed is to create a non-MDI window (I know this is possible, just not 'standard'). Then come the next trick. Do you want the window to be above everyone else, or only above everything when Mushclient is visible?

http://www.developerfusion.com/show/72/9/

At a guess, I would say using the 'frmFind.Show vbModeless, frmMain' example, where in this case frmMain would be the current world window would do the job, if you simply want it to be on top, when Mushclient is on top. Though I have no idea what effect this would have one a window that is 'supposed' to be moved outside the main window. You might have to use the first example from that page instead.

Hiding and unhiding it when you switch between worlds is an option that could be provided as well. In fact, "auto-hide", "hide when world is not visible", etc. could all be in a right click menu for the window. Same with something to bring up a dialog to set the pre-append text for a input window, or even if it 'has' such a window. Of course, there is the issue that saving those setting can't really be done. In a plugin, there is no way for Mushclient, currently, to write to the plugin with the settings, same with the main world.

http://www.codeproject.com/wtl/wtlsnap.asp

Gives an example of the auto-hide functionality, though most applications that use them tend to set the title bar size to about half normal and same with the font, so that when not in use, they are less annoying. For some uses this would be quite helpful to have. It also includes examples of docking code, though of course, since the idea is to make the window external, it needs to 'snap' to the outer edges of the client when room is available, not the inside.

I am asking on a C++ forum if there are any better examples around, but maybe these will help. Trying to find exactly what you want through google isn't precisely simple. lol But some combination of the snapping/floating functionality is probably what most people are looking for. The auto-hide and other tricks are just nice additions. Also, since MDI vs. SDI are behaviours, not specific states for a window, it should be possible to use the 'pin' for a different purpose, like 'pinning' the window to the client, so it behaves like another MDI, for those that don't want it floating next to the client. The existing purpose for it is sort of the same, except that it forces it in the open state. A different icon might be better for that, like an open book or something.

Anyway, thought I would try to help. I don't know what problems you are actually running into, but this is one time I really wish I did know C++, so I could work out a real example. :(

I suppose it can be done, the activity toolbars are a sort-of case in point.

The problem with this sort of thing is that you (I) end up spending a lot of time working out how to fit these ideas into the existing framework, sometimes with unexpected side-effects.

A couple of recent things that had strange side-effects:

• The Accelerator idea caused the checkmark to disappear from the Info Bar and main Toolbar menus.
  
• Putting the document name into the "document title" made it be impossible to save it.

These are so from left field that you don't even expect to have to test for them.

sorry for not posting earlier, but it'd be convient if I could have one notepad window stay on top if one world was active, or if just mushclient was active and I could script it so that the notepad window was not on top if I switched worlds, know what I mean? The latter preference would probably be easiest for you to do?

I don't think the "on top" attributes of windows allow such fine-tuning.

Something I read suggested that to make a window sit on top of another MDI window, you have to reassign it 'parent', so it is the child of the window you want to be on top of. Or in other words, you set parent = world_window, instead of parent = MDI_window. Otherwise, you have to tie the state of the world window to the others, so that when ever its state changes, all other windows associated with it are brought to front as well. However, currently notepad windows are probably not tied to any specific world. Its complicated.... Fixing it would probably require making notpads objects tied to each world and require other worlds to access them through special functions that take account of the world they are bound to, not just the notepads name. Its an either or. Either they are children of the world or the MDI, not both.

Or I assume that is the problem.

Hmm. Think I have found proof that floating windows can be done the way I suggested.. Download mIRC, if you don't have it, then enter something like:

/window -do @Fred 0 700 300 200

Into the command window. This will cause an 'always on top' window to show up, which remains on top of all other windows, even if you switch to a completely different applications. I assume it must still remain tied to the MDI, though it is external, since it also appears as one of the tabs in the interface.

Oh, and mIRC is from:

www.mirc.com

Obviously the only major difference is the adding of a few things like being able to pop it in and out of the main window itself and some behaviors, like the "snap to the main window if dropped near the edge (+/- say 6 pixels)" stuff.

I'm sure it can be done if enough time is put into it. mIRC doesn't necessarily use MFC, so they are not necessarily using the same tools as me.

Ah, yeah. That is true. MFC and other high level libraries probably won't do it. They are mostly designed to allow you to make stuff that acts and looks like an MS product. Thus making it not act in such a limited way... lol

I doubt the code would be too complicated. Most of it would simply be adding a few lines in to add to or override MFC behaviours. Finding how though...

Anything happening with this? I'd love to have this feature.

I don't really want to spend a lot of time trying to work out how to shoe-horn fixes like that into the MFC libraries, which themselves are very big and hard to comprehend, if you try to do something which is not designed into them.

After reading a lot of the ideas for this and how someone already suggested using tabbed windows, i want to agree to it. what makes it easy for me to use zmud's windows is my ability to tab them. i ahve all the windows tabbed in the top so that i am able to change to them just in one click. the notepad system that is currently set into MC opens another window in the but if i change to the world (which is normally maximized) i will have to restore the world so that i could read the context of the notepad, and that what i've been trying to avoid. the idea about being able to make windows that float on top is somewhat like the status window in zmud which i use but its not necessary at all. its all in the taste really but yeah for me the tabbed windows, or even the ability to be able to see windows like mirc or zmud has it would be nice, having to minimize or restore the window to its original size to be able to see the other windows could get someone killed in a mud heh. sorry if i make no sense or whatnot, i havent slept in 2 days and i think its starting to affect my ability to think.

Is this idea for separate windows still being pursued/considered? Base on what I have read, it sounds very nice. I only skimmed over most of the posts, but I like what I am seeing. Has a window docking feature been brought up? That is, actually attaching these windows to the world window, so that they can be resized together (as opposed to being resized independently).
I find that I can accomplish much of what I would use these windows for with notepad windows, but I also see these windows making things much easier, and the ability to have the window show the colors exactly as it appears in the world window would be very nice.
I like that they would be child windows to the main MC window, like notepads, because I too do not like having my programs spit windows all over the place.

So...Is this going to be a feature available in a future version of MC?

I know its been a long time since this was last discussed, and I am not sure where the spawns/separate windows stand today, but I just thought I'd mention an implementation of spawns in a new client that I found really, really nice.

In this particular client, a sidebar is used for the current connections (essentially taking the place of the activity toolbar & the tabs in MUSHclient). This approach allows for a very nice structure of worlds & spawns, like this:

*World One
*****Spawn X
*****Spawn Y
*World Two
*****Spawn Z
*********Spawn A
*********Spawn B

Each world, and each spawn window, has its own activity indicator. You can also choose whether or not to expand or collapse each world to show or hide the spawns beneath it. Spawns can be several levels deep, so you could make a spawn 'folder' called Channels where you keep all your channel spawns, and another 'folder' called Pages where you keep all your page spawns. The 'folders' don't need to be active spawns themselves, they can just be placeholders used for grouping the related spawns.

I have to say that it makes for a very clean and well-structured interface, using this sort of approach. It also seems to make for a very natural treatment of spawns as precisely the same kind of window as a 'main' world window. Just separate in the sense that all the output you see is what matches the pattern, and all the input uses whatever prefix you setup, so that it all goes onto the right channel or to the right person.