MC Minimize to Tray option

How about a minimise to tray option?

Why was this never replied to, Nick? Missed it? :).

It's a great idea, taskbar space is considered valuable real-estate by some, and minimising to the tray would be a great addition, and very easy to code.

Ah yes, missed that one. And how do you do it exactly?

You basically use Shell_NotifyIcon() with either NIM_ADD or NIM_DEL to add/remove the icon to/from the system tray, and ShowWindow() with SW_SHOW/SW_HIDE to show/hide it from the taskbar.

You use the uCallbackMessage variable of the NOTIFYICONDATA structure when using Shell_NotifyIcon() with NIM_ADD to select a user message to receive in your program, so if you defined WU_TRAY as (WM_USER + 1) (probably higher than this, no doubt you're using a few user messaages already :), and set .uCallbackMessage = WU_TRAY;, then you can capture messages in WU_TRAY (messages such as clicking to restore the window, or what have you). This is where you'd also handle right-clicking and the showing of a menu, if you added that.

As far as MFC goes, I have no idea, maybe there's a class? But this is how you do it with the API alone.

Also, somehow I doubt someone that can add all of MUSHclient's features and keep it stable will have little problem with such a simple, and common, piece of programming :P. HTH!

True, kthx. I have the Visual Basic code if you need an example, should be a breeze to convert it to C++.

OK, thanks guys. I now have the basic concept working. But the question is, apart from having a nice icon there, what do you actually want it to do?

I can think of a couple of things:

Double-click

Restore MUSHclient window (if minimised) and bring to the front.

Left-click

• Don't know for sure - maybe show a list of active worlds, with the count of unread lines, so you can switch to any world?
• Some other thing?

Right-click

• Show another menu - eg. the normal right-click menu for the active world?
• Show a nested menu of all MUSHclient menus (eg, so you can do "new world", or "quick connect" or whatever.
• Some other thing?

I'm not sure if a context menu is really needed. What you do need is a global option that enables/disables minimising to the tray, but I'm sure you've already added that, or are adding it. I can't really think of anything you would need to quickly do with a right-click tray menu without opening up MUSHclient first.

One other thing you could do however, is the option for MUSHclient to always appear in the tray, and be able to enable/disable showing it on the taskbar. That's assuming what you're doing now is minimising to tray, then restoring the window, whilst removing the tray icon when it's restored?

So there should be perhaps three options:

• Minimize to tray
• Always show icon in tray
• Hide program from task bar

I don't use "flashing" the task bar myself, but you could animate the tray icon instead of the task bar icon if the task bar slot isn't there. Of course, you would only be able to hide the program from the task bar if you're always showing the icon in the tray, otherwise you'd lose the program altogether! (except in the task manager)

Are you sure? So if you turn off "minimize to tray" and turn on "hide program from task bar" then once the program is minimized it is "bye bye"?

Making "minimize to tray" merely a different sort of minimize is simple, so simple that I assumed you would want more, like some sort of menu or something.

The program goes "bye bye" as far as the user is concerned. If it's not on the task bar and not in the system tray, how do you bring it to the foreground unless you use the Task Manager or something similar? As I said in my first post in this thread, the main point, for me, was "task bar real-estate", so personally I wouldn't need a menu, but maybe Poromenos can think of a reason for one?

Well, you could use radio style buttons to have three options:
Minimise to tray
Minimise to taskbar
Minimise to both

Or, use checkboxes, and have two options
Minimise to tray
Minimise to taskbar

If someone turned both off, he would effectively hide MUSHClient, and then he would perhaps cause it to reappear by launching it again (i mean that if you launched it again it would activate the old copy rather than run a new one). I think that the radio boxes are the best option, and there should also be a function to change MUSHClient's tray icon, so that you can maybe hide it from your *coughBOSScough*... As for the right click menu, I can't think of anything that would be useful, apart from Restore/Exit... Maybe you could just add the tray function for now and someone will come up with an idea...

I think it might be nice to have a context menu on left-click that shows a list of connected worlds and maybe marks those that have had activity in some way. Additionally, allowing you to select that world to maximize MUSHclient with that world as the active one could be good for 'stealthy' MU*ing. ;)

See, ideas already :p
So you could have the menu show like:
1) My World 1*
2) My World 2*
3) Your world

and you could click on a window to activate and show MUClient, perhaps... The asterisk there means that there is new activity in that world... Or something like that, anyway.

Well, although showing worlds in a context menu could be useful, I would prefer it be even simpler than that:

When the user hovers the mouse over the icon, a tooltip appears listing the open worlds, with bold names being worlds that have had activity since minimizing.

A single left [primary] click should restore the program.

A single right [secondary] click could present a simple context menu:
This assumes your options for minimizing are simply standard 'minimize to task bar', OR 'minimize to system tray'. (You could change the toggle via the menu when in Systray mode)

Now, if you really want to get creative, you could develop additional [animated?] icons, to represent different scenario's:

You might change the icon slightly if any world has had activity.

You might develop a whole series of icons (perhaps simply colour changes to the lamp), and allow the user to code icon changes via scripting. Eg: World.TrayIcon "1" or World.TrayIcon "red", etc...

If you added such a feature, you might also add a mother-flag that enabled/disabled icon usage. The user could decide if they wanted to allow scripts to change the icon. Under such a scenario, it would be sensible to also present that option in the right [secondary] click context menu I offered above.

Got a bit of a cold Poromenos? ;)

Yes, well perhaps if you wanted to MUD away quietly the logical thing would be to have a tray icon that looks very similar to the "volume control" icon, which is normally in the tray. It is not that unusual for multiple tray items to appear when the system is undergoing one of its frequent, ah, idiosyncracies.

I will say I like magnums Idea of being able to change the look of the tray, that way, say you were being talked to or something, you could change the color of the tray to let yourself know this was happening and such.

Perhaps Nick, you could have a few different icons to choose from, a Boss one, a disconnected one, and then a normal one (the lamp?) which is somewhat changable.

mIRC does the minimize to tray thing nicely. At least, as far as the Icon goes with disconnecting, connecting, connected, activity, et al.

Also, some programs have been adding a fourth button on the top left, which is a minimize to tray icon, it looks like a dot on the bottom right sort of like the minimize button. Im sure you can find an example of what Im talking about.

I suppose if you really wanted to make it customizable, you could also support completely custom icons, basically display any small gif or whatever as the icon as well as the built in slew of MC ones.

(that way you have your command to change with arguements (Magnums Example), and then if you were custom, youd add a filename as well as the "custom" value)

I suppose a lot of that doesnt make complete sense.

Just one point to think about.. If Explorer crashes, or more rarely someone intentially shuts it down to force a Registry update, then most icons in the task tray die. The programs themselves continue to run, but are inaccessable from the tray. This happened to me often enough when I had a flacky video card on this system that I dropped a copy of the internet connection thingy into the other program tray, so if I lost my blinking connection icon, I could use the other program to disconnect. This is much less of an issue with Mushclient, but it does tend to be annoying. I have no idea how or if you can make sure it stays in there if Explorer goes down. Only 2-3 of the 14 tasks I have running seem to restore themselves if their icon is lost. You may take a look around to see if there is some info about how to avoid this.

However, since you can always alt-tab to get back to Mushclient, this is a lot less critical than if is was something like Display Settings, your virus scanned, volume controls, PGP or even the dang internet connection icon. When one of those goes AWOL, it can be quite a major pain.

You can refresh the icon every minute or so, that'll make sure it's always in the tray...

Hm, << GREAT >> to see this idea rolling out at last, this one will get a huge thumbs up from everyone.

Nick, LOVE the idea of a <mumble>-click (left/right? i suppose you could make that an option like ICQ does for it's users) menu to display unread lines of text, don't let that one die.

Something else to maybe consider while your mapping the idea out is a 'floating' MC icon... although personally these don't toast my bread. Just something to think about, while you're on this theme, that users may bring up later and you'll thnk, 'Gees should have done that while doing that other thing...'

p.s. _being_ a 'coughBOSScough', i have to laugh - i've been waiting for this opt. in MC for ages as well, so the staff stop asking 'what the hell is that you're doing?'. <<laugh>>

Tnx Nick:) Regards Ashlan

This will probably cause a lot of retribution amongst users, but it is something i have always wondered about. So, simply for Nick's interest...

I have never understood, but always admired, the reason behind offering such a great program fully capable without registration. Simplemu*, for example, offers an unlimited trial version of their client with only 'limited capabilities', which is great. If you like it, you register, you aquire a bit more bling-bling. When i found MC, i registered it because it's great, by far superior to any other i could find, and i had the spare dollars; so i hope they bought you a cold beer somewhere a long the line way back when i registered:) <cheers>

Now, an option like this one, which i imagine the majority of users will have been waiting for, would be ideal as an 'added capability after registration'. Before you all start hollering, have a think about the work that goes into providing us with a great piece of software. This, 'skins', transparancy - why not encourage a few more people to hit the coffers with some copper when it comes to these program cosmetics?

I'm a big advocate of encouraging people to register MC when i point them to it. I'll be interested to see if anyone agrees with my stance on supporting good software - i mean, i'd have taken it for free, but i could smell nick's blood and sweat on the thing when i downloaded it.... hee.

I also would think this kind of "cosmetics" feature (or, even the scripting array) could be a "registered version only" feature.

I believe the reasoning is mainly that it's hard to really evaluate a client unless you can actually see all of its features. Otherwise you're "in the dark" and just trusting the developer that they're telling the truth about the registered version being better.
That being said, I always have thought that Nick gives away a bit too much. :-)

Yeah - it's a fine line i hadn't thought of - and NOW i remember why i never registered simplemu* - good point Ksilyan.

So, what do you do? I mean, it's reputation precedes it - most game hp's i've browsed even promote MC by name, so, maybe that's enough to surpass trust issues. I am sure nick could muster up the odd testimonial. And, i mean, take away the cosmetics like skins and you have a fully operational client anyway. Skins is like the cyber technologies version of McDonalds, 'Would you like fries with that?' - i mean, if I wanted fries, i would have f*ing asked, wouldn't I? People will *BUY* the client for the extras if they are that way inclined. You know, i registered already, and i had the choice not to. If I was the sort of persn who didn't care about registering software, but I had to register to get a few skins on my client, i probably wouldn't, because skins don't really flip my pancakes. But, say, 30% of people might, so nick wins a few more dollars than he is right now.

Then, where's the line? You need to register simplemu* to really USE triggers (eg) and a few other more BASIC things ( i forget what) - that's too limited a trial basis. I couldn't really USE the program extensively, test it's capabilities, to get a feel for it. So, i passed on it. i'm not saying nick should go that far, but hey, it's his wallet:)

I'm REALLY interested to know what nick has to say!

That's quite funny. I hadn't thought that it would be the *boss* that was using MUSHclient and trying to keep it quiet from his staff. Good one. Maybe we should rename the "boss key" the "staff key". ;)

Registration

As for the registration issue, my first point is that I think it is hard when programs offer "limited" features before you register. For example, a database might allow 100 records before you register, then you register and find out why - it runs like a dog when you put 1000 records into it.

MUSHclient already does that in a small way - the spell checker cuts out after reporting a smallish number of spelling errors (10, I think). That way you know it works, but can't keep using it without registering.

I think the problem is that by making more and more features "registration only" you may push people to register, however you may just push them to find the crack site that lets you use it for nothing. I am reluctant to mention that such places exist, however searching for "MUSHclient" in Google returns lots of hits these days, which I am pleased about, but in about the first or second page it takes you to a crack site.

Warning

Just in case you are tempted, I want to make a serious warning here. A lot of cracks involve running some sort of "decracking" program that allegedly removes the copy protection, or nag screen, from lots of software. Now it probably does do that. However you ask yourself, what else does it do? Is this how the vast number of Internet worms are propagating (apart from people opening email attachments)?

Think about it. If you run a "crack MUSHclient" program you are already doing something that is technically illegal - subverting the nag screen and altering the program in an unauthorised way. So, if the "crack" software also installs a backdoor onto your computer you are not in a good position to go and complain. It would be like a burglar trying to get his stolen TV fixed under warranty.

What to do?

I like the idea of having the program being well-regarded and openly available. As you know, the evaluation period never expires, so you can evaluate as long as you want. However I am going to be motivated to keep adding improvements only if people pay, at least some of them.

To be honest, I think around 1% of downloaded copies are paid for, so I think the way of fixing that - assuming it needs fixing - is to simply get more publicity, so that it is 1% of a greater user base.

If you can do so, and haven't already, I would appreciate a mention on the web page for your MUD, at least alongside the other clients. A year ago certain competing clients got mentioned on practically every MUD web site, but MUSHclient rarely. Maybe mention words like "free evaluation", "very reliable", "actively supported" and so on.

Spread the word around, and MUSHclient will continue to provide good fun for playing MUDs for many years. :)

Hee, yes well, i'm running a hotel - the reception staff are hardly going to have time to be on a mu*, and let's be honest, the majority of mu*ers are old blood these days. That's my big goal on mu* - promote them as social, colourful, choose your own adventure type chat programs. If people contact me on icq/msn blah blah i tell them, 'hey, download this client from here, come have a look, that's where i'm at'. The programs are smaller, more stable, banner free, no gimmicks, porn pop up free <ICQ!> - why not mu*?

1% ??? That's it? Well, nick, all i an say is, a BIG thanks:)

About registration, whenever I try to "convert" someone from zMud, the first question they ask is if MUClient is free. They have probably already paid for zMud and they don't want to have to pay again to use a client they might not like. Right now, I say "yeah, it just has a small delay in the beginning, but you can use it as long as you want", and they are happy. If i said "yeah, but you can't use half the features", I don't think anyone would try MUClient even with my bashing zMud all the time :p So this way, you attract more user who will start using MUClient and eventually register it.

I don't play any MUDs, so I don't know how popular MUSHclient is with that half of the playerbase, but when it comes to promoting MUSHclient to MUSHers, I do find that on the whole most new players select SimpleMU instead (after being recommended both clients) and that few who have used SimpleMU are interested in switching to MUSHclient.

My impression is that the spawned windows is one feature that often wins people over to SimpleMU, despite the fact that it actually has some features crippled in the evaluation version. I also think people might like the fact that the worlds toolbar seems to be for a theoretically unlimited number of worlds; rather than using a limited number of pre-made buttons, it uses tabs generated on the fly. Currently, however, new activity isn't indicated on the tabs, but this should be doable. I use a text editor called EditPlus where a red asterix is added to the tabs for files with new, unsaved information, for example.

On the whole, I do think that to some degree the fact that SimpleMU is preferred by many MUSHers comes down to the approach of not putting certain features into the client because they can be more or less solved with scripting (although the spawned windows can't be adequately handled, given that notepad is size-limited and does not offer a separate input window, and not tabs either of course). It may have lead to the client being perceived primarily as a MUD client rather than a client that is as useful for all coderbases.

Personally, I still think that MUSHclient is the more complete package, but that even so there are some really tempting features in SimpleMU, and for a lot of MUSHers those seem to win out.

Linda, thanks for those comments.

Perhaps if there is a "killer feature" that is the one thing that stops people registering, even if it is available indirectly via scripting, that I should look at adding in as built-in one.

Things like "minimise to tray" I think are just cosmetic, but perhaps the two you mention, a better list of open worlds and spawned windows, might be sensibly added.

I'll have to look into that. :)

As most people here know I try to resist bloating the program with lots of features just for the sake of adding features, and I note that the SimpleMU download is about twice the size of MUSHclient's, but maybe a couple more things like that are not really bloat.

Linda, I know you requested this "spawned windows" idea late last year. Can you outline a bit more how this works?

1. Is it like the notepad windows where you choose some sort of text (eg. a regular expression) which makes the matching lines go to the other window?
   
2. What are the major differences between spawned windows and the current technique you can use in MUSHclient (ie. "send to notepad")? Is it colours?
   
3. Would the spawned windows just be extra windows sitting around which you can bring to the front and view if you feel like it?
   
4. Do you expect to select text from them, save them, log them etc.?

It is certainly true that MUSHclient is a much sleeker download. Although, I get the impression that this is becoming less and less important to a lot of people. Not saying it isn't a good thing to keep it small, because it is, but I think a lot of people aren't too bothered by a size increase.

However, if a size increase also means a noticeably larger memory footprint, then yes, a lot more people do care. And I know that a few years ago, SimpleMU was much more of a memory hog than MUSHclient. But from what I have heard from users of the last versions, it has been extensively recoded and I haven't heard any complaints about the memory usage lately.

As for the spawned windows, lets see how well I can explain it after testing SimpleMU briefly earlier today.

1) More or less, yes. You setup a spawn on say <Public> *, and the first time it matches that string, it will spawn a second window (pretty much identical to its world window) to which it then redirects any incoming text that matches <Public> *.

It seems you can also combine this with another trigger, matching on whichever command you use to speak on <Public>. This automatically takes anything you say that starts with that command (+pub * in this case) and sends it to the spawned window rather than your main world window even when you have the main world window in focus and are typing into the main world's input box.

However, the spawned window does have its own input box as well. I forgot to test if you actually need to use +pub when speaking in the spawned windows input box or not. But whether or not SimpleMU does it, I think it would be ideal if you, when you talk in the spawned window using its input box, don't need to use +pub to speak on <Public> but simply can type in what you want to say with no prefixed command at all. That sure would cut down on miscoms and mispages.

2) The major difference between using the notepad and 'real' spawned windows are: A) The spawned window has the same size limit as a regular world window. B) The spawned window has its own input area, so you can flip to the spawn window and talk there directly. C) The spawned window shows up on the main list of world tabs rather than just on the drop-down list of open worlds/files, making it very easy to flip to them even for those of us who point-and-click. ;)

3) Essentially, they are extra world windows, yes, which can be brought to the front like a normal world window.

4) Yes. I think you should be able to select text from these windows, save them and log them separately from the main world log.

Personally, I do think it would be best to redesign the world toolbar as well if you do decide to do spawned windows, to make them more visible. If you were to go for tabs, you could perhaps have it setup so that spawned windows always group together with their parent window. And you could perhaps make it optional whether spawned windows show up on the world toolbar or not.

Another option (but that one sounds iffier) might be that only world windows become tabs on the world toolbar, and spawns become some kind of submenus to those tabs which you could access by clicking on or hovering over the tab in question. But then it would be harder to show new activity in the spawned windows.

If anything's unclear, I'll give SimplMU a closer look and see if I can explain it better. :)

Btw, the features that SimpleMU removes or cripples until registration appear to be: pause on more, text editor, spell-check and thesaurus and live spell check.

Hmm. Ok, having seen what Linda thinks SimpleMU does, here is my take:

MDI vs. Floating.. Error windows, notepads, etc, etc. etc. All these being MDI is bad design. Often you want them to exist parallel to, but not completely seperate from the world. The problem is that the only way to place both windows on the main MDI frame at the same time is by resizing the main MDI window 'and' the world window, nether of which I want to screw with. This is why I like something like Poromenos' external one better. You can put it anyplace you want and the client doesn't have to be maximized to fit it, so you can stick other stuff in the spare space you my have too. For me this is an optimal situation, since I often have a looping tracert in a DOS window (with a real small font) going on the right side of the screen, I may have SciTE visibly under the client so I can easilly click between the client and editor, etc. Making me maximize the client to fit a new window in it is not going to make me or about 50% of the people that have requested such a feature happy.

Input/Output... I would say that being able to tell the window to use a default option, like always applying bs or say, chatall, etc. is a good idea. By the same token, since this is going to be bound closely to the world, I wouldn't mind seeing parallel displays. What do I mean? Simple, if I 'omit from output', but also 'send to window' I don't want to see plain text in the window, I want to see the original lines in full color. This is the one *major* flaw in any external option anyone ever makes, you have no real means to properly capture the *real* original contents to send if you try to omit it. It makes no sense for an inbuilt window to have this sort of goofy limitation.

As for tabbing... Bit more complicated, but one solution is 'don't use the standard tab system'. Use something more like the button bars in Opera. Each button has an image, text name and a little down array. Hit the down arrow and you get a drop down menu. I am not sure how/if you can add such to a tabbed system, but it would solve the issue of bringing up linked windows, especially since it may be a good idea if going non-MDI on them if they minimized or otherwise hid themselves when their world isn't in focus, at least as a default behaviour. There may be times someone wants to tell the window to remain visible when in another window (which you couldn't do with MDI btw).

I'm probably dreaming, but something like http://dave.community.net.au/mc-spawnwindows.png would be very, very nice. :)

Hmm. interesting Dave. It still has the same MDI problem I mentioned, but it a tad less annoying, since it basically looks and acts like a split screen. For a chat type window this may work quite nicely.

However, an example of where MDI is a pain is when an error occurs. The error window either buries the world or gets hidden behind it. In some case there is no visible dialog to indicate that something went wrong and especially in the case of debug info from MXP or the like, which not only produces no obvious sign anything happened, but doesn't move the error window to the front either. With a window that was floating and completely seperate (and even in the case of error was 'always on top') this wouldn't be an issue, since it would be quite obvious a new window had been created.

Like I said.. Sometimes MDI makes sense, other times it just gets in the way. You have to decide on a case by case basis which works better. Personally, while I like Dave's concept, for chat content, I want something with the *same* number of lines in the display, even if I have to set the font for it a bit smaller. Cutting my normal output in half in order to provide a window that also doesn't show as many line is not something I want. On the other hand, if such a window could be 'docked' above/below the normal window, but I could specifically make them floating to start, I would withdraw my objections.

Also, another advantage is that it become increasingly likely that at some point people will not only have, but use cards that support multiple displays, being able to stick some windows in the 'other' display is important. MDI either completely prevents this or at the very least makes for a very bad use of it (as in a big split down the center of a window never designed to exist on two seperate displays).

Ok. So this is not 'currently' a big issue, but it is something that does present a potential bonus for those that do have it. And as I said, many cards now support two displays, but the cost of the monitors is the only thing really preventing there wide spread use. But even if you don't have that, then at high resolutions (yes not every one has 15" monitors and use 800x600 resolutions) there may be more room 'outside' the client that in it. Not having a way to take advantage of that is dumb imho.

I think what can be achieved, and fairly easily too, is a variation on Poromenos' extra window.

My main problem with VB programs is that they tend to be large, slow, and also I tend to not get them to work. :P

For instance, the "fancy hit point bar" I wrote in VB I had a lot of trouble getting to work on a different PC.

So, if I could make a nice, fast, compact spawned window, written in my language-de-jour (C++) then I would be happy. In fact, since virtually everything you need to write such a thing is already exposed in the scripting interface, I think it is just a case of doing the actual work of doing a nice window with coloured text, lots of lines, fast scrolling etc.

Similarly the "multiple world switching window" that Linda talks about could be probably written as a separate program.

Now in case you think this is too much complexity, it would probably involve:

a) downloading a DLL or EXE and putting it somewhere handy (eg. the MUSHclient directory)

b) installing a plugin that calls it and feeds things to it

Then, if the source code (for the spawned window) was publicly released someone else could take it and add to the general idea.

The thing is, you've already got great code for text windows in MUSHclient itself. Wouldn't you just be reinventing the wheel if you used a separate program? In my altered screenshot idea, you could simply have a Send To: Custom Window (1), Custom Window (2), ..., and be able to name these windows (like how I've named them Chat, OOC, and Tells). Ideally, Send: wouldn't send anything, as the whole line would be matched and sent, colours intact. Basically you want to redirect output from your main window into these "chat" windows. Plugins, DLLs, and external programs just seems like too much of a "hack".

I remember that the health bar wouldn't run on my PC at first, but that was only because I wasn't loading the world from the beginning and the plugin was OnPluginConnect :P I think my window solves at least part of what Linda wants easily. It is also easy to add callbacks to it, so that you can add a text box have it call a specific sub in a plugin when you type something in it...

I must admit that I don't follow the technical aspects of things entirely, but on the whole I think that what Dave says makes sense. The world windows in MUSHclient work very well, so why create something different? I much prefer the idea of the spawned windows behaving precisely like the world windows (except for prefixing anything said in their input boxes with their specified prefix) than having them work somewhat differently.

Would it really add much size or memory usage to the program to add that capacity while still using the basic structure of the current world windows? It seems like an awful lot of extra work to accomplish this with a plugin, really.

Sigh.. So, I guess I am the only one concerned with the fact that if I want an external spawned window I still end up having to use a external application and that the mean to *currectly* translate the lines to that window, especially if the trigger used 'omit from output' doesn't exist?

I very much agree, that no matter how good or wonderful an external window application is made, unless it does a whole heck of a lot more that provide a simple window, it is a hack *and a bad one*. But I stand by the assertion that the MDI design is a pain in the ass when dealing with multiple windows, especially if even 10% of the users would like a way to have those windows side by side, without messing with the current size of either the world window or the main client window. Sorry Linda, but searching the forum you will find at least as many people with this concern as people that want one that worked exactly the same as the existing windows. That said.. I think having such a spawned window is probably more important than the technical issue of if you can/can't drag it out of the main client area to sit it next to the client instead. I can always use something like Poromenos' window to do that anyway.

Also, I absolutely think that a tab interface of some sort would make life a lot easier, especially if all associated windows got listed in the *worlds* tab, not someplace else or all as seperate tabs.

Example:

http://www.geocities.com/shadowfyr2/MC_Tab_Small.png

This is a Paintshop Pro tweak of the top of the client. Basically, you make the worlds tied to buttons, which resize as more worlds get added. It is possible that eventually you may end up with some that are like "Ages of ..." to fit more, but unless some nut opens 40 worlds, this isn't a major issue. Now.. Behaviors of the buttons would be:

Click - selects the world of course. I have it changing the color to make it more visibly obvious which world you are dealing with. But since the button ends up in a down position, this isn't critical and it may be better to use color as an indicator of new activity.

Right-Click (on the button) - produces the drop down shown, which lists all the windows 'tied' to that world.

This imho provides a nice clean expandable interface, while not taking up too much room. Worse case, you may need to make the bar grow by one line if they open more that 7-8 worlds (or are using a lower res than me of course..) and the text starts to get too obscured to tell them appart. A normal tab system wouldn't look as good and having every single window be a tab would really turn into a total mess.

Hmm.. Though some way to tell 'which' of the sub windows you are in it needed too. I didn't consider that...

Well, obviously there will be disagreements, but just as you want an external implementation of spawns, I really don't want one. In fact, I wouldn't even use external spawned windows, I would just fine it too awkward. So obviously, I'll argue for an internal implementation, because the other one is of no interest to me as it isn't really the feature I am asking for. :)

Also, I am fairly sure it would be possible to do an internal solution that can be turned either on or off as the user desires and then have those who wish to use scripting add on an external one if they so wish instead. So in that sense an internal solution would have the potential of pleasing more users, whereas an external solution alone would only please maybe half. And that's after all why this was brought up again: how can more people be enticed to use and register MUSHclient.

As for the tabs, I have to say I quite like your example image. :) That would be a very nice to way to handle things. How about giving each subwindow a number? Then the main tab can display the number of the subwindow you are currently in (and if no number is displayed, you're in the main window). Similarily, new activity could be indicated with some kind of marker, again perhaps with a number to indicate subwindow activity. Hmm ... that part would require some creativity, but I think it is a nice approach.

Yeah.. A number would be a good idea. I had the windows sorted in my example, but if each new window was tagged with a number, starting with 0 as the main, then you could even optionally allow certain hotkeys/macros to select the window number and quickly jump between them. This would require a world specific command like 'SetSubWindowFocus <number>', but if creating such a window from the script returned the number it was assigned, 'num = world.NewWindow("MyWindow")', then this is easy to deal with. The commands:

integer World.NewWindow (Name BString)
integer World.FindWindow (Name BString)
World.SetWindowFocus (WinNumber Int)
String World.GetWindowName (WinNumber Int)
World.ClearWindow (WinNumber Int)

Maybe some others.. You may want to get line info in them, just like you do with a world for example. Though, this imho gets even clunkier when dealing with seperate windows.

---
But on a related note I never really liked styles. I would have preferred something that did a CopyLineAsHTML type command, which I could then parse and change as needed. Though a means to also 'PasteHTML' or the like would be needed to, instead of the insanely complicated Colournote mess you have to code now. Style runs and things don't account for anything but colors and basic stuff and will only become increasingly less useful if/when Mushclient starts inlined images or other things. For example, can styles tell you if the text on a line is a 'URL link' or the like? It is far more complicated than it needs to be imho. As something of a power user I would prefer to replace one tag in a line and repost the changed version, than deal with the complicated mess that arises when you have to loop through the entire contents of the line to find what you are looking for. I am sure others feel the same. Its confusing, complicated and often impractical the way you have to do anything now.
---

As for showing activity, as I said, it is real easy to change the color of the buttons, since the default color is grey, changing it to the light blue I have for new activity would make it obvious which ones had recieved some. A single character like a * isn't very visible and could even prove useless is some user decided to name the world *My Mud* or something. After all, the world name displayed can be anything.

True, a colour change for activity is a good idea. But it might also be nice to distinguish between activity in the main window and in one of the sub windows.

Maybe it would be possible to let it be user configured where the spawns are? As in, whether they're a regular world window that takes up the whole MUSHclient window, or if they're a popup or some kind of sidewindow?

Hmm. I am not sure how/why a sub window would have new activity if the main window didn't... Maybe the single character trick added to the drop downs for indicating which had activity would work.

As for defining where they show up.. Don't think that matters. I would be nice to have a side window, but since most such windows are ones I want to do more than display text in, this isn't that big an issue. I don't mind in the least making a custom design for something that doesn't need to actually be a full window. Its is trivial to make such a thing and designing it to do whatever you want. Making one that is actually built into the client and works like my example obviously isn't.

As for capturing lines. If the triggers send to the window and the window support "all" the same things as the normal world, then this is equally trivial, since you don't even need to use a script to send it there. Everything including links and any other stuff added to the client as inline later will get copied straight across. The fact that reading such content from a window in scripts is complicated and frustrating is an entirely seperate matter that I wouldn't mind seeing resolved at some point, but I have been fighting Nick over that issue for a long time.

If you are spawning all your paged conversations to a subwindow, and the new activity is a page, wouldn't that be activity only in the subwindow?

Then again, I guess if the main window indicatives activity, you could just right-click on it to see in which window the activity took place. But if you want to allow people to switch straight to a subwindow with a key combination (if that is at all possible), it would be nice if the main tab indicated which subwindow had the activity.

Hmm.. Yeah, which infortunately brings you back to having every window be a tab, since there is no other practical solution. Dumping extra stuff on the button just takes up space and after you get a certain number of main windows, adding extra stuff to the button means either cutting off the name or cutting off the indicators. Neither is a good thing. I think this is one of those cases of needing to compromise.

Nick could always have the hot keys be something like 'ctrl-<' and 'ctrl->' by default and make them mean 'Previous subwindow' and 'Next subwindow'. This isn't any worse that alt-tab for programs and would let you quickly cycle through them to find the one that changed. This would be a much better compromise than cluttering up the contents of the tabs or adding even more buttons for each window. It also allows existing hotkeys to cycle between worlds like normal. Though... Come to think of it, no such hotkeys even exist to jump between worlds. Maybe 'alt-<' and 'alt->' to cycle worlds and 'ctrl-<' and 'ctrl->' to cycle the windows for each world.

Ctrl+Tab cycles between world windows...

Thought there was one, but couldn't find it looking at the help file.

Ctrl+Tab is a standard Windows function to switch MDI client windows. Noteably some of their own software have hijacked those keystrokes for other uses, but it generally works.

I use it all the time, and assumed everyone knew about it, but as they say "don't assume".

I have amended the MUSHclient documentation to mention it on one of the "getting started" screens.



Sigh. This shows how hard it is to please everyone.

I was thinking initially that another application would allow a non-MDI window (eg. on another monitor even) because it would not be a "child" of the MDI frame.

However Linda is saying she prefers the windows to be inside the MUSHclient frame.

It is true that the current coloured windows are "already written" however if you saw the code you would realise that it is heavily tied up with receiving new lines, selecting, copying, logging etc.

A "subset" (eg., chats only) is basically a rewrite (of outputting code) because the current way it works is to find a particular line (eg. if you scroll backwards) by doing something like taking the pixel position, dividing by the number of pixels per line, and indexing into the scrollback buffer to find that line.

Once you start getting subsets (matching regular expression) then it either has to be done differently, or another copy of each line is made.

Something can be done, it just isn't a 5-minute job.

Obviously, I don't know much (read: anything) about the coding side of things. Heck, I don't really know what an MDI is. :)

When it comes down to it, it is obviously the decision of the person responsible for doing the code; I am simply giving my opinion of how I think it should work. And from a user point of view, or at least this user's point of view, some kind of pop-up window as the only option for spawned windows is undesireable.

Ideal, as I see it, is a solution that allows either internal windows that behave more or less like regular world windows or external windows that behave in some other fashion, but I have absolutely no idea how doable or not that is. But it must certainly have the best chance of pleasing the most users. :)

MDI is Multiple Document Interface. It is basically the "window within a window" that characterises MUSHclient, and a lot of other programs.

The "outer" window is called a "frame", and inside it the inner windows appear, and are clipped to the frame edge.

This is nice in many ways, it stops the program's windows from taking over your entire desktop, however there are times when you might want that. :)

I appreciate your suggestions, whether they are easy to do or not, is not your problem. I will see if there is a way of achieving that, or something similar, without huge amounts of effort or "software bloat".

Ah, thanks. That makes sense of that acronym. :)

I guess what this partly comes down to (apart from what is doable or not in an effective fashion, which I agree is important) is what different users are used to. I know a lot of people don't like tabbed browsing, for example, and although it took me a fair while to try it, I've gotten so used to it that I'd cry if someone took my tabs away now. ;)

Forget the first rule of design Nick. K.I.S.S. lol

But seriously, I didn't realize things where bound so closely to the window. It is possible to make windows that behave like MDI, but can float as well, it just isn't often done, since the APIs don't directly provide it. In any case, if the existing windows are so closely bound, then making a new type may be more practical, in which case there is nothing stopping it from supporting either MDI or non-MDI depending on user choice. I still think that a direct way to feed capture text 'with color and other stuff' to it is a good idea or someone is going to scream about some things not working as right.

Then again, maybe a complete rethinking of the existing design to de-couple some of the mechanics of text processing from actual display is in order. Doing it now would be significantly easier that later, when something else gets added and makes it even more complicated to fix.

Heyhey nick - O/S W2K w/regular windows updates etc > 'minimise to tray' minimised to tray & task bar? i have tried reboot, various option... not much luck;) Glad to see it happening though!!!

Regards, Ashlan

By the way, it would be nice if the user could use their own icon. The way you do that in VB is you load the icon in a picture box and pass it to the API. Maybe you can pass an icon's hWND in C++ or something...

The minimize to tray only will take effect next time you start MUSHclient, as it has to set up a "hidden" window as the owner of the main window.

However I have made a slight change in 3.47 which may fix it.

As for the choosing custom icons, that is added to 3.47.

I am experiencing an odd effect which I am pretty sure started after upgrading. I always run MUSHclient maximized, and all worlds with it, but now that I flick from one world to another, I am seeing the window of a new world maximize, as if it had been minimized before. If I flip away, and then back, it happens again.

Oddly enough, it only seems to affect one world, and so far I haven't been able to find any setup differences that look like they could possibly matter.

Sounds like an old problem:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=37

What causes it, I'm not sure. Read that post and see if it helps.

OK, I think I reproduced it. :)

If the flickering world was mimimized before, then it thinks that it needs to "restore" it, and thus you get the flicker.

This is how I fixed it...

1. Un-maximize the individual world windows.
2. Make sure none are minimized (ie. they are all just ordinary window panes)
3. Exit MUSHclient in this state.
4. Start MUSHclient again
5. Now you can maximize the windows and it shouldn't flicker

Don't know if this has been addressed yet, but when I minimize MUSHclient, and use the tray icon to restore it, it doesn't come back maximised like it was before I minimized. Also, currently there's no option to "Minimize to tray". When I minimize, I'd like the task bar entry to be removed, and a tray icon added. Then, when I click on the tray icon, I'd like the task bar entry to be returned, and the tray icon removed. Is this possible? :)

Try 3.47, see if that fixes the "no task bar" problem. As for the maximizing let me know if that still happens.

I just installed 3.47, and have minimize set to both, I always play with mushclient maximized and when I minimize it goes to the taskbar and the tray, if i click on the taskbar to restore mushclient it returns maximized, if I click on the tray it returns not maximized.

Sounds like it needs a bit more work. :)

Nick, when you right click the taskbar, perhaps you can have a minimize to tray option? Also somewhere in the main menu structure have a command (File / Edit / View etc).

Also, having a fourth button next to the minimize (minimize to tray, minimize(to taskbar, normally), maximize, end task)... like this:
http://neal.bussett.com/tray.png (K-sens)

Just noticed that there was no way to simply click something and shrink it to tray. I know sometimes I want to get rid of MC completely, but dont normally want it to minimize to tray.

Ah yes, another icon. Another client I know has a heap of them and I think it is confusing, myself.



How were you planning to get it back?

Minimize to tray. Want to get rid of it from the taskbar. Sorry, that was a confusing statement.

I want it to normally minimize to taskbar, but then sometimes (for whatever reason) want to get rid of the taskbar, and minimize to tray.

As far as I can see it is hard to swap from the taskbar to the tray while the program is running. The way I hide it from the taskbar it to "fudge" it as belonging to a hidden untitled window or some such thing, however that has to be done at program startup.

This demo seems to do it:

http://www.codeproject.com/shell/trayicons.asp

you do need to 'create' an account to download the zip files. Just use a throwaway email addy.

I can also email them to you.

Hope this helps.

Hopefully this will allow you to hide the taskbar icon "on the fly".

http://www.codeproject.com/useritems/hidetaskbar.asp

I'm not sure that showed how to hide/show on the fly, and in any case was for a dialog-based app.

However, what I really wanted to say was that I don't want to get further and further into operating-system dependant code, stuff like trays that may not even work under earlier versions of Windows. Once you start doing this stuff, making apps disappear when the OS generally expects them to be there, you start adding bugs, or potential bugs. What will happen under Windows 2005 for example?

To quote an old saying "on that path lies danger".

I understand that nick. But really, Why cant MC function like every other thing with a minimize to tray option? Where, when you have it up, it displays in the taskbar, and then you minimize it to the tray, and the taskbar button goes away. You can also minimize normally, or maybe even not. (AIM is an example of this, whereas MSN you click the X to minimize to tray).

Eh, those are poor examples Im sure, I just dont think MC should have to be in the taskbar all the time, or none of the time. Since fishing for MC in the tray is a pain when I just want to switch to another window. Whether its a "on minimize, put into tray and not taskbar" or a special function to minimize it to the tray, doesnt really make much of a difference. I just dont agree with the all or nothing nature of it currently.

Just to add my 2 cents here.. Minimize to tray "by definition" means it should not also appear in the task bar. Some programs do show a task icon, but also a task bar, but those applications are ones like WinAmp, Netscape, etc. The tray icon is a 'server' application that quickly loads the application after you have loading it once, but it is *not* the application itself. Ones that do true minimize to tray do so as a way to avoid appearing in the task bar when you don't want it there, not as a way to appear in both, which is just plain stupid and completely pointless imho.

Eh. I guess we’ve got a difference of opinion, or something.

When I picture minimize to tray, I think of it as when I’m 'not using' the program, it should be in the tray. Then, when I’m actively using it, or maybe using it partially, but haven’t 'told' it to go away (clicking minimize) (so, I’ve just opened another window on top of it, or whatnot) it still shows up in the taskbar (and the tray, its always in the tray). Then I can click on the taskbar and get it back, rather than having to go fish in the tray.

For example, say I was using my text editor, with MC, to edit my script. I have them both open, and I’m going between the two, I want to be able to click the taskbar and toggle between them.
Then, once I’m done, and MC is just sitting idle, because of whatever reason (say I’m AFK on mud and doing something else on my computer, or my chat server is running, but nothing else) I’d like to minimize it, and have it go away.

So in a way, yes, Shadowfyr, I’m agreeing. I want to be able to minimize MC to tray when I’m not using it (for my chat server) but then have it in the taskbar when I am using it. I want to "minimize" it to the tray, but when its not minimized, I want it to show up in the taskbar, so it’s not unwieldy.


Kind of off topic, is it just me championing this idea? I know personally I’ve gotten annoyed in the past with certain users who have asked for something to be built-in that I didn’t see a reason for as it could be done through scripting or whatnot. Is this the case in this topic? Am I being the obnoxious user that keeps pushing an issue no one cares for? Or is no one else piping up even though they’re interested?

I can see why Flannel would want that option, although I'm on dialup and never idling on the MUD, so I don't have any need for it personally. And by the way, the Winamp Agent only acts as a server when you have it turned on, if it's off Winamp gets minimized to the tray and/or taskbar from the application itself. What I do when I write tray apps in VB is hide the form when it is minimized, which removes it from the taskbar, and show it again when the window is restored through the tray icon. Can you not hide/show forms at runtime in C++?

Heya!

"As most people here know I try to resist bloating the program with lots of features just for the sake of adding features, and I note that the SimpleMU download is about twice the size of MUSHclient's, but maybe a couple more things like that are not really bloat."

The SimpleMU installation ships with a 800KB thesaurus and a much larger help file size due to screen shots.

Overall, the Executabe/Dll size is about 200KB larger that MUSHClient's 800KB. A negligible amount with today's PCs.

Kathleen
SimpleMU Author

Ah, I didn't know that. Thanks for the clarification.

I am glad there is another client author out there who believes in keeping things compact.

There are actually other clients which are *much* larger, whose names I could have mentioned, however I mentioned SimpleMU because comparisons were being drawn to MUSHclient in this thread.

Other clients which seem to me to be going down the "bloat" path are:

Client "A":

Client installer: 6.32 Mb
Required MDAC database components: 5.3 Mb
Required JET database engine: 2.82 Mb
Total: 14.44 Mb

Client "B": 6.52 Mb

Client "C": 10.8 Mb


Compare these to MUSHclient's current download size (version 3.49) of 1.43 Mb. This includes a spell-check dictionary but not a thesaurus.

Yes, I have to agree some of the other client installations are getting very large.

I've personally avoided trying to introduce functionality that would have heavy dependencies on things like MDAC since not only does it add more installation support issues, but limits its usuability from machine to machine.

I still have many users who run SimpleMU of removable media, something that couldn't be done with a lot of system dependencies.

The download for SimpleMU is about 3MB I believe, but that's about as large as I would like it to get.

Cheers,

Kathleen

Flannel, to answer your question - you don't have my vote :) When it comes to various GUI icing, the first thing on my list of priorities is some way of improving the scripted control over the GUI. I'd prefer effort to go into allowing me an easier way of redirecting output to windows, controlling positions of those windows, their style properties, etc. WinTin has a nice setup which looks like some sort of a Sash window for each world, which can be tweaked from a script. However, that is probably not dynamic enough, though I don't know much on this matter to say whether you can name a Sash or resize/nuke it programatically at runtime. But I certainly think that being able to create and dynamically manage a collection of windows for each world using callbacks would present a very nice enhancement to Mushclient.