I'm listening to this broken record about notepad and colors etc for a day now here on the forums, and I was wondering if the following could be implemented?
Instead of not being able to dock the notepad to the world window, nor being able to change the color of specific words or lines, I suggest implementing frames to world windows, so that it would be possible to split your world window and have an area beside it that would accept any input via scripts.
The second one could be limited so that it can't be typed on directly, it can't be switched to either (this in fact is a feature which i like, since switching to the notepad windows constantly is irritating, and yes there was an alias to this, but come on ;)). As it's a frame it would follow your window where ever you move it, and if I'm guessing right, it wouldn't be a notepad window, it could be made to accept any kind of coloring.
Not exactly. Did a 5 minute picture manipulation to explain myself further. Now with the side panel there being another window, those green statuses could all be in different colors, but most of all. they would follow my window around not being a notepad.
A 3-way split is an interesting idea, and might be achievable without too much hassle. I had most of the code already written to write to coloured windows but was having problems with when they got created/destroyed. Your idea of a split would solve that issue.
I am hampered a bit by what the MFC libraries offer. I *think* they offer the second split, in which case it should be fairly easy. If not, it is a major hassle.
There is a bit of a problem splitting on the right like in your example, because the splitting stuff insists on a "balanced" split, like this:
What can be done fairly easily is a split at the top, like this:
Now if I did this we could have full colour drawing to the top pane (extra text), with the others behaving as normal. That would be OK, woudn't it? You could put status stuff there, or chats, or whatever.
The second option looks a lot better to me. The fourth pane wouldn't be particularly useful if you can't adjust the size without adjusting the command window to match. I can still think of plenty of uses for that extra little window though.
In my experience in using the frames in VB, you CAN have the panes be unbalanced, in 2 methods, TRICKING the 4the pane to use a 1 as the height or in other words making the 4th pane use the remainder of the height of these panes (1+2)-3. OR you COULD make pane 3 overlap pane 4 by setting the height of pane 3 to be the height of pane 1 + 2.
There is another option and that is make the split NOT encompass the input area, but be split IN the upper section of the already existent split. That would be a split in a split, but that might be the easiest way to accomplish this. The only foreseeable issue that would occur is the window sizing based upon number of characters, as it would not typically include the NEW split section.
I think the upper and lower method WOULD work, but be a little more difficult to discern from actual mud text, as it would be "inline" with the rest, IF possible the side split would IMO be much better in terms of being visually pleasing, and then again the option to choose which method would be even better :)
Yes, I gather I could make the left-hand side one view of 2 panes, and the right-hand side a second view with one pane. It is all getting a bit complicated, and I think the top pane could work OK. You can always have a different colour scheme (eg. white background).
Well I was waiting to see how much enthusiasm there was for it. Ten days elapsed without any comment, after I said it was possible. This sort of thing takes quite a bit of work - there is the code needed to actually put the text in the third window, resizing it, having an option to see it or not, handling clicking in it, and so on.
I of course would like to see it implemented and a couple of friends of mine that i develop scripts for ( As I ask for opinions on how I should proceed with my plug-ins ).
I think it basically comes down to how many do actually develop "complex" scripts, and how many of those actually take part in this forum, against those that only know how to make a simple trigger and don't even want to learn more complex scripting, which of many might want to see this kind of features as long as they just downloaded them in a readily made script. What a sentence ;) But what I mean is... the more complex and specific features we request, the smaller is the audience. :)
Well Nick, I am more enthusiastic about the side one, If for no other reason than that its might be useful for displaying static stuff, not chat, or other things that need to be the same "width" as the mud text. The only real limitation I can see with the resulting mini window in the corner is... There isn't much you could do with it, and some of the things one might use it for (like spell icons, etc.) won't work, since there is no support for icons/images in said windows at this point. But, even the top split is interesting. Now the obvious solution to allowing "either", without the mini box would be to change the nesting level of the windows. I.e., make the split a subwindow of the existing world window, so your not splitting the input window, just the MDI that is hosted above it.
That however would mean more code changes, since notes, etc. would be now directed to something like 'main->world->output_frame->output', 'main->world->input' and 'main->world->output_frame->split', instead of 'main->world->output' and 'main->world->input'. If you get what I mean. Still, any way you plan to do with it, it would provide an interesting feature. It might even help the idea of a tutorial, since the script could do something like:
Top = 1
SetSplit 50, Top 'Obviously, if you allow a choice as to where the split happens,
'it might also be nice to specify if it is above or "below" the
' 'world, or on the right/left. And even if it only splits one way,
'this would still be useful.
SendToSplit "Hi! And welcome to the tutorial!"
...
and so on, then open/close it as needed when the "helper" wants to say something, without messing with the simulated game much.
Quote: Well Nick, I am more enthusiastic about the side one, If for no other reason than that its might be useful for displaying static stuff, not chat, or other things that need to be the same "width" as the mud text.
I do this already with a dummy world on the side. The only annoyance with that is that if I have everything sized correctly, then the infobar pop up, the main window gets scroll bars because the world windows no longer fit. This isn't so bad, but they don't go away once the infobar is removed, and the scrollbars do wind up covering the command line, among other things.
Either way this is implemented, having a dummy world can dupe the other solution just fine.
"Well I was waiting to see how much enthusiasm there was for it. Ten days elapsed without any comment, after I said it was possible. This sort of thing takes quite a bit of work - there is the code needed to actually put the text in the third window, resizing it, having an option to see it or not, handling clicking in it, and so on."
Heck I've been wishing for this for years, and posted requests every couple of years just to see if it was possible at the time :) I've tried the suggested world window method but occasionally it spat the dummy, not to mention the command line pain, so for now am using notepad windows again.
As far as placement, for sure I'd far prefer the sidebar as opposed to inline.. the upper window would be good for capturing tells etc otherwise missed in spam, but for me the main attraction was using a sidebar for color-coded status checks of effects and spells that I have up, and similar things like timer warnings when certain effects are about to drop, targets, grouping status and so on, which all require more of a list format, thus long but narrow as a sidebar would provide..
I think I mentioned once before that one of our mud's coders wrote a client called wintin which has dockable colored windows (example at http://wintin.org/Portals/0/screen1.JPG ), which is just the sort of effect I've tried to emulate with MC. The source code is also available at wintin.org in the downloads section if that is of any interest.
Lets put it this way... To use an example of why I don't think dummies are as useful, lets use the behavior of two Usenet clients as examples. One, Gravity, has splits. Top split is the "groups" on the server, the second is the list of messages in the currently viewed group and the last one is the message being looked at. The other XNews **looks** like the same basic client, but it uses standard MDI. You have two options, tiled, or stacked. But, tiled only repositions *open* windows, it doesn't resize them automatically if you change to a new message, it leave the first message tiled, then slap the next on over top of the other windows you **wanted** to also be visible.
In other words, the more things you do, the less usable the client becomes, because of all the fracking extra groups, message lists *and* messages piled on top of each other. I see the way Mushclient currently has for doing some things like this. You can't get rid of the input bar, so you lose some screen space there, then to add more fun, the more windows you need, the more complicated things get. If even "some" of those windows where splits, and thus tied to the main world, then it becomes far easier to adjust the few dummies you need (if you even need any at all), while making sure that the information that is **supposed** to appear along with the mud text *is* visible when its world is visible. Its not terribly practical to do that with a mess of dummy worlds.
The only thing that would be better would be what I have talked about for years, but which is **far** less accessible, given how absurdly complicated doing it has proved to be. And even in that case, the only benefit would be letting some script handle repositioning the windows as needed, since you could react to when things happened to them easier. Its still less complicated to have the client deal with most of it, even if it was implementable at this point.
If frames were needing to be voted on I would be voting YES all the way, but would prefer the side panel method, or if possible the option to choose which method. As stated by someone else having it to the side as a status window of sorts is the most likely reason for wanting the split, so that it functions like several other clients out there, zMud can do something similar, as well as one I previously mentioned, but for the life of me cannot remember the name of at the moment.
I, myself on Aardwolf have 3 windows open, the main, which takes up left 3/4 of screen, the map which takes up top 1/3 of remaining area, and the channel split which takes up the remaining area. This setup works quite well for me, as if I miss something in battle spam I can catch it in the side window. The map is split and omitted from the main window to cut down on spam, and allow me to update it on the fly as well, as I have a keypad button set for this.
If the frames were to be implemented I would use it for spells and the like, or status, or a report section of some kind. Would still need the dummy worlds, unless multiple splits were able to be implemented, and the only foreseeable method that that would work is a class inheritance type of situation, but then we run into the problem that has plagued people for some time, and that is how to toggle "Design Mode at Runtime" to allow placement of any movable controls.
Ok I know I went on and on here, but to sum it all up frames in general would rock, in either top or side positioning.
Also as Demonsurfer stated about wintin, the source has references to a "Magic Library" that is C# (C-Sharp) which is a .NET thing, which should be avoided like the plague.
Actually, looking into it as I have, the "design mode at runtime" issue isn't resolvable, not by simply "setting" a design mode flag. Why? MS' own design mode controls are made so that they **cannot** be created in that state, unless you have one of their compilers installed. Basically, it would work on the test platform the application was created on, if you could get it to work at all, but not anyplace else. Also, regular windows may not *have* a "mode" setting, since its not something standard, unless its also a MS control, created in the same environment that the design time controls from MS work in.
The only real solution is to implement something in the container (frame, etc.) that acts like the original "mode" feature. You then set up something that will either hide, or disable user input, for the control to be moved. Once its dead to user input you stick some boxes around it, for the size box and drag handles, let the user move "those" around, then, when done, move and resize the control to "fit" the new location of those boxes, before making it active/visible again. The trick is, if you want to see what it looks like as you move it, that instead of making a single bit of generic code to draw a fake box and handles, then moving that, you have to implement the code for them in *every* control, then use something like the UIDead function and a redirection of the draw code in the control, to make it work. There is an example some place I saw of making this "faked" system in VB, but I ignored it at the time, since it wasn't what I was trying to get working.
Personally I always thought this was a kludge, since there was already code implemented to handle this with most installed activex controls. But, due to the stupid, "You must have a license for Visual Studio installed on your machine to create design time controls in your application.", BS, its pretty much the only way it can be done. And, I suspect now that its basically exactly what the code in all those activeX controls does, with one extra bloody check to see if the license is installed, if you try to "create" one of them while *in* design mode. Actually setting the mode, as long as its not "also" an activeX, would probably be as simple as replicating the mode flag and what ever event gets fired to announce to hosted controls that it changed. But, I am not sure it simply temporarily switching the container to "runtime" creating the control, then switching the container to "design" gets around the bloody license or not. And, you **definitely** don't want to use activeX or other prebuilt MS controls that already have the flag. Its buried in some idiotic hidden attribute mess, which takes a crowbar and a voodoo ritual to change modes. lol
So far we seem to have some votes for the side panel, which would be more useful (it seems to me) for stuff like status information (eg. a list of fairly short flags, and whether they are on or off), and some votes for the wide panel, which would be more useful for stuff like keeping chats in (where you want the same width as the original window).
The only thing that turns me off of the sidebar is not being able to resize that little box on the bottom separate from the command line. I could toss the map down there like Onoitsu does. Perhaps some potion info. Actually, it still sounds more and more usable as I think about it. Side bar for me now :p
I would hope they would have hyperlink functionality just like the main window. It would be nice to have a clickable list of levelling or quest areas. I'm pretty sure that some type of colour system would be in place. Even the Infobar has that.
Just saying I'd prefer it to be the same kind of system. I personally despise the InfoBar aliases, because although they may be flexible, they don't rub me right. To make a somewhat simple InfoBar, you need a -ton- of commands, which makes it relatively slow each time you need to update it. But well... I shouldn't get carried away with things that are so far away still.
You would at least have some sort of colour system. I can't see how it could be written to without scripting, as it is probably something that is hard to automate with a "send to sidebar" in a trigger.
You would probably need something like this:
SendToFrame (1, "foreground", "background", "text") -- write in colour
ClearFrame (1) -- empty it
DeleteFrameLines (1, 20, 40) -- delete some lines
Would you want scrollbars? Horizontal? Vertical? And before you say "give me the lot", remember that scroll bars themselves take up room, and can look ugly.
I'd call style 3 my first choice, providing frame 1 above was resizable in vertical dimension. Style 4 would be second choice.
In both the above cases, vertical scroll bars definitely for frame 1 and the output window of course, but not horizontal.
Frame 2 (sidebar) could be ok without any scroll bars imho, providing we could set the width dimension ourselves. Maybe vertical scroll bars, but could they only appear if required if possible, meaning that they don't take up realestate when they aren't being used?
Perhaps existing color send/tell code would seem the logical choice since we already use that format, providing a change in color doesn't force a new line. SendToFrame1 also sounds good - something similar to the existing Send/AppendtoNotepad function, again for familiarity.
I like #3 out of those choices as well. I agree with pretty much everything Demonsurfer said, except that I think the two frames should have scrollbars on the short side.
#3, with a vertical scrollbar as necessary on Frame 1 as it should wrap on long lines like the Output. Frame 2, I think would be ideal if it could be set up with options so it has no scrollbars, horizontal/vertical only, or both as necessary. (Wrapping on that frame might be optional too.) :D
As for formatting output, I don't have any great ideas :( Frame 1 should probably be handled similar to the output (because that's how I'd use it). Frame 2 ... I'm tempted to just say, 'make it a HTML pane' except that the easy ways to do that would be bad (IE ActiveX control FTL), it would make scripting it non-trivial and being able to embed javascript and images into it is probably overkill.
OTOH wxPython comes with a primitive HTML renderer, does wxLua do the same?
xwPython and wxLua are both wrappers around the xwWidgets GUI library. They both have the same ability to create interface dialogs, display HTML, deal with socket connection, etc.
Having a plugin (in whatever language) to make a panel display as a web page sounds like a great idea. However, forcing it upon the user as the default would severely limit the functionality. Embedding Javascript is partially redundant, since MUSHclient already supports Javascript on it's own.
Having image support in one of the frames might be nice, if there isn't terribly much speed and stability lost with it.
MUSHclient doesn't use wxLua - we have discussed this before in other threads. I think wxLua is a way of providing a GUI interface with Lua scripting. However MUSHclient already has a C++ GUI interface, and I doubt whether it can be integrated with wxLua. The problem will be which part (the C++ part or the wxLua part) has control over the incoming Windows messages.
Well, actually, I am fairly sure that the integration code for wxLua probably provides/explains how to fix that (it would be useless if it didn't), but it doesn't matter, since the real issue is the size of the download needed for the wx libraries, both the Lua ones and the wx API it wrappers. Both are fairly large.
The other issue, which involves a lot less bloat and support for GUI, as has been discussed before, is figuring out how to set up an enumeration system for a few hundred lines of ATL code needed to *support* GUI elements. The example code MS provides comes up short in that it a) only shows how to handle only a single object and b) relies on IE as the host application for the ATL control needed to link your GUI control to the script, which is about as useful as proving that Styrofoam can float by placing it *inside* a boat. Presumably, it does work also in programs that don't have preexisting native support for objects, but there is no way to test that from the way their example is written. At least not without having a far better understanding of what the heck its doing that I do. :(
Here is the rub... What ever needs to be done to make MFC support something like wxLua is **probably** pretty dang close to what is needed to simply add that ATL support for late binding objects, so adding several megs of libraries is probably going to be totally redundant, once you fix the initial issue of making sure everyone's GUI messages get where they are supposed to. Its just getting *that* issue resolved that is the key problem.
Quote: What ever needs to be done to make MFC support something like wxLua is **probably** pretty dang close to what is needed to simply add that ATL support for late binding objects
You're right... both would require a complete rewrite of MUSHclient from the ground up. This has been said repeatedly, and yet the 'suggestion' keeps coming up as a solution to various ideas.
Quote: Here is the rub... What ever needs to be done to make MFC support something like wxLua
These are two completely separate GUI libraries. Although getting the two libraries to cooperate certainly is not impossible, having to pass various pieces of information between the two libraries dependent upon which container is holding the data sounds like a nightmare to code. wxDAO uses both, but with only wxWidgets controlling the GUI. Adding wxWidgets also causes issues with OLE compatibility, at least for OLE-2.
Quote: You're right... both would require a complete rewrite of MUSHclient from the ground up.
Sorry, but bull. The last link on the subject I found shows clearly how you an add fairly minor set of ATL additions to support a late bound object ***without*** completely rewriting the entire application. As I said though, the only example of doing this is a very poor one, which makes it hard to figure out how to actually do it. But its **not** impossible, nor would it require the entire program to be rewritten.
The idea that a rewrite is needed is **solely** based on conjecture, not facts. And as near as I can see, its a poor conjecture. People have fracking done this, and they have done it in applications that where, at the time, written with MFC + ATL. Their solutions though are all bloody tied up in proprietary applications, where the code isn't available to anyone to examine.
Quote: Sorry, but bull. The last link on the subject I found shows clearly how you an add fairly minor set of ATL additions to support a late bound object ***without*** completely rewriting the entire application.
You are right there. It would just require a complete rewrite of the display code, which has been optimized for display speed of text, not anything graphical whatsoever. You can't even change the font size of the text for just one line, since that goes against how MUSHclient deals with how text is displayed. Adding buttons and images is certainly a bit more of a departure from the current code than just changing fonts.
Quote: The idea that a rewrite is needed is **solely** based on conjecture, not facts. And as near as I can see, its a poor conjecture. People have fracking done this, and they have done it in applications that where, at the time, written with MFC + ATL.
Great, get to work... MUSHclient is open source. I'd love to see you get this done. Prove me wrong, and I'll be happy.
Back to the question of the appearance of these new frames, it occurred to me that we have an issue with the fact that you can make multiple windows belonging to one word (see Window menu -> New Window).
If you did that, what would happen to these new frames? At present the new window is a mirror image of the "main" window, albeit possibly resized, paused, and scrolled to a different place. It also has its own command window where you can be typing something different.
Sigh. Sorry Shaun, but I don't see how allowing someone to create a custom window, or even place images in **one** pane, which is designed for only images, does anything at all to effect the efficiency of the text mode window, which shouldn't be effected by adding new windows, which work differently, any more than opening 12 worlds is going to horribly lag the first one (or shouldn't), or opening a dialog does. You are talking about an entirely different issue, which has nothing to do with what the "main" window is going to be doing anyway. Mind you, having such support in the split for top/bottom isn't a good idea, but there is no reason why you can't have other pains, which are not intended to scroll, which do support things the one you **need** to be fast can't do.
And frankly, if I could afford to buy something that supported MFC, which the free stuff doesn't, then I would be working on it. Right now I am looking at $200 a month to student loans, maybe $150 to food, and the rest of the $400 or so a month I make going to incidentals, which will soon include a $200 replacement for the Palm TX that broke over a month ago. A Visual Studios version that has MFC, isn't in the budget at the moment. :(
--- Now, back to the direct subject, instead of side issues.. Well Nick, in any context where you have your windows maximized, this isn't much of an issue anyway. In cases where you have them side by side... I would say the most reasonable result would be to default any new ones to the "non-split" state you start with, rather than making a direct mirror of all states. Its likely that anyone making such a window isn't going to be using it for the same things as the main window, so there isn't any reason why it would have the same panes, unless they explicitly set it to have those for some reason, via scripting, or by dragging the panes to the same positions. But that's just my view of the issue.
Quote: You are talking about an entirely different issue, which has nothing to do with what the "main" window is going to be doing anyway. Mind you, having such support in the split for top/bottom isn't a good idea, but there is no reason why you can't have other pains, which are not intended to scroll, which do support things the one you **need** to be fast can't do.
Once again you missed the point. It's the difference between adding the current, tested, stable panels or adding a new experimental panel with tons of potential bugs in it. Personally, I'd rather see the same panels as the main window added first. Later, after all/most of the bugs with the new panel code have been worked out, then add support for images and buttons and such. I have said before that I would like some way to display graphics such as a map somewhere, and I would like to have additional support for user made buttons. I just don't think that adding them at the same time as a panel would be as good of an idea as dumping everything in at once. In the first post I had about the combination of wxWidgets and MCL, I mentioned not only that it was possible, but I also mentioned one source of instability issues. If OLE is interfered with, who knows what else will have to have workarounds put in?
Quote: If you did that, what would happen to these new frames?
For this, I agree completely with Shadowfyr. The only reason you would really want an exact clone of the current world open is if someone is connecting to a mu* which allows multiple connections at the same time. Not only is this somewhat rare, usually the secondary character(s) are set up as bots, or require such a different setup, that you might as well start from scratch.
Maybe very, maybe not so very relevant... but I'd prefer text-only panels. While I believe Zmud and Cmud to be just completely flawed implementations, I'd rather not risk and find out MUSHclient is getting more unstable due to 'pretty' additions many of us have haven't ever needed to rely on.
I have added buttons, and a progress bar, but have added them via an external executable made in Autoit, and it adds itself to the toolbars section. I attempted to add a new frame to the existing world window, and was unsuccessful. Have not even looked at source, as my compiler is on the fritz currently, and need to dump and reinstall it.
The pane is communicated to via UDP sends, and it sends (via keyboard messages) back to only one world that is chosen upon startup. It works quite well, and have had a few friends use it for attacks or other things that are easily clicked to do.
Have stopped developing it as interest for additions stopped, but might have to take a look at the latest source to see what I might be able to implement using any means needed.
Ok, I don't disagree with you Shaun, in principle. It would be better to make sure you have a *working* frame implementation first, then worry about if you want to do something fancier. The only potential worry is in considering making adjustments to the code so that alternates are "possible" as some future date. I.e., even if all you are doing is adding in some basic code that says, "If Frame_Type_Flag = 0, then use the standard window type." Worry about *if* the new window types of the frames are buggy after you add code to create types 2, 3, 4, etc. and are actually testing them. But, make sure you have a way to do it first, even if you never use it.
Obviously, any additional window types are going to require debugging of their own, so making sure that the entire implementation of them is separated out, so that you can leave them disabled *until* they work right, and as independent as possible.
Mind you, I don't think solutions like Onoitsu2's are *bad* in general, but I don't like the idea of plugins that *require* someone to install other programs, which might turn out not to work right under WINE, for example. I also don't like closed source solutions, where you are pretty much stuck with what ever behavior the program supplies.
Mind you, in the long run it **may** be useful to have an external solution, if for no other reason that there is no way to currently (and no suspending script in a coprocedure doesn't count) to have a plugin/script do things that may take real time, behind the scenes, while the client is busy handling other things. Mappers, if they do path searches, image display, which requires independent download threading, anything that supplied a 3D graphic from primitives supplied by a mud, checking info on a web page (even if just the raw data), etc., all need time that the client can't afford to give. But, that doesn't entirely solve the issue, since the current methods, like UDP, for talking back to the client, are limited, indirect, and way more complicated that how Mushclient's script handle any of its own functions. I would still love, even if we had a versitile external solution, some way to streamline things in the plugins/scripts so they *act* more intergrated, instead of requiring anyone that may want to use them to learn Yoga to twist their code into the right shape to support it. ;) lol
Quote: Mind you, I don't think solutions like Onoitsu2's are *bad* in general, but I don't like the idea of plugins that *require* someone to install other programs, which might turn out not to work right under WINE, for example. I also don't like closed source solutions, where you are pretty much stuck with what ever behavior the program supplies.
Anything made with AutoIt is standalone, and doesn't require anything else to be installed in order for it to work. AutoIt is also freeware, if not OSS, and the source for any utilities can be included in the MC source files. Also, I don't think the Onoitsu's 'solution' is meant as a permanent fix, but it's a good way to start testing out design possiblities before all functionality is added. Ideally, I'd rather not have external solutions like this simply because having a separate program like this makes debugging quite a bit harder.
Quote: Mind you, in the long run it **may** be useful to have an external solution, if for no other reason that there is no way to currently (and no suspending script in a coprocedure doesn't count) to have a plugin/script do things that may take real time, behind the scenes, while the client is busy handling other things. Mappers, if they do path searches, image display, which requires independent download threading, anything that supplied a 3D graphic from primitives supplied by a mud, checking info on a web page (even if just the raw data), etc., all need time that the client can't afford to give.
These are all great uses for things like AutoIt. Having a mapper creating maps outside the MC event loop would make things quite a bit more convenient for customization and recovery issues. It would also help to have the mapper on a separate version control system for bug fixes, since any mapper will start out buggier than an ant farm.
