[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Separate windows - ideas, anyone? :)
Separate windows - ideas, anyone? :)

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

Pages: 1 2  3  4  

Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Thu 03 Jun 2004 12:23 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #1 on Thu 03 Jun 2004 01:00 AM (UTC)
Message
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.
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #2 on Thu 03 Jun 2004 01:59 AM (UTC)
Message
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.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #3 on Thu 03 Jun 2004 02:08 AM (UTC)
Message
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.
[Go to top] top
Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Reply #4 on Thu 03 Jun 2004 02:22 AM (UTC)

Amended on Thu 03 Jun 2004 02:31 AM (UTC) by Magnum

Message
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.
Quote:
I am also not expecting the windows to be "split" windows with input areas, they are basically extra output windows.

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.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #5 on Thu 03 Jun 2004 02:30 AM (UTC)

Amended on Thu 03 Jun 2004 02:39 AM (UTC) by Flannel

Message
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?
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #6 on Thu 03 Jun 2004 02:39 AM (UTC)
Message
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.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Norbert   USA  (61 posts)  [Biography] bio
Date Reply #7 on Thu 03 Jun 2004 03:34 AM (UTC)

Amended on Thu 03 Jun 2004 03:35 AM (UTC) by Norbert

Message
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.
Norbert

-Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens
It's a dumb question... skip it.
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #8 on Thu 03 Jun 2004 03:44 AM (UTC)
Message
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.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #9 on Thu 03 Jun 2004 04:04 AM (UTC)
Message
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.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #10 on Thu 03 Jun 2004 04:27 AM (UTC)
Message
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.
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #11 on Thu 03 Jun 2004 04:45 AM (UTC)
Message
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.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #12 on Thu 03 Jun 2004 05:52 AM (UTC)
Message
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.
[Go to top] top
Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #13 on Thu 03 Jun 2004 06:56 AM (UTC)
Message
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.
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #14 on Thu 03 Jun 2004 08:25 AM (UTC)
Message
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.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] 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.

120,536 views.

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

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

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]