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.
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.
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.
Well, you won't have lost any existing logging.
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.
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. |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2 3
4
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top