Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ MC Minimize to Tray option
MC Minimize to Tray option

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2  3 4  5  

Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #30 on Fri 19 Mar 2004 02:38 AM (UTC)
Message
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.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #31 on Fri 19 Mar 2004 05:16 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Dave   Australia  (93 posts)  Bio
Date Reply #32 on Fri 19 Mar 2004 05:24 AM (UTC)
Message
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".
Top
Posted by Poromenos   Greece  (1,037 posts)  Bio
Date Reply #33 on Fri 19 Mar 2004 02:34 PM (UTC)
Message
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...
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #34 on Fri 19 Mar 2004 06:06 PM (UTC)
Message
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.
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #35 on Fri 19 Mar 2004 07:41 PM (UTC)

Amended on Fri 19 Mar 2004 07:43 PM (UTC) by Shadowfyr

Message
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...
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #36 on Fri 19 Mar 2004 08:25 PM (UTC)
Message
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.

Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #37 on Fri 19 Mar 2004 09:14 PM (UTC)

Amended on Fri 19 Mar 2004 09:15 PM (UTC) by Shadowfyr

Message
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.
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #38 on Fri 19 Mar 2004 09:25 PM (UTC)
Message
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?
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #39 on Fri 19 Mar 2004 10:06 PM (UTC)

Amended on Fri 19 Mar 2004 10:09 PM (UTC) by Shadowfyr

Message
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.
Top
Posted by Linda   Sweden  (164 posts)  Bio
Date Reply #40 on Fri 19 Mar 2004 10:10 PM (UTC)
Message
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.
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #41 on Fri 19 Mar 2004 10:38 PM (UTC)
Message
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.
Top
Posted by Poromenos   Greece  (1,037 posts)  Bio
Date Reply #42 on Sat 20 Mar 2004 01:13 PM (UTC)
Message
Ctrl+Tab cycles between world windows...
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #43 on Sat 20 Mar 2004 06:31 PM (UTC)
Message
Thought there was one, but couldn't find it looking at the help file.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #44 on Sat 20 Mar 2004 09:30 PM (UTC)
Message
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.

Quote:

Sometimes MDI makes sense, other times it just gets in the way.

...

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.


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

227,681 views.

This is page 3, subject is 5 pages long:  [Previous page]  1  2  3 4  5  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home