Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUSHclient
General
Separate windows - ideas, anyone? :)

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	Separate windows - ideas, anyone? :)
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Shadowfyr] In reply to Norbert> [quote]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.[/quote] 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> [quote]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.[/quote] 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.... [quote][quote]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.[/quote] Well, you won't have lost any existing logging.[/quote] 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. [quote]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.[/quote] 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. [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3 4

Posted by

Linda Sweden (164 posts)

bio

Date

Tue 21 Mar 2006 11:53 PM (UTC) [ quote ]

Amended on Tue 21 Mar 2006 11:57 PM (UTC) by Linda

Message

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.