Gammon Forum : MUSHclient : Suggestions : Frames to world window

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, 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.

Entire forum

MUSHclient

Suggestions

Frames to world window

Frames to world window

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

Pages: 1 2 3

Posted by

Isthiriel (113 posts)

Date

Reply #30 on Mon 20 Aug 2007 01:57 AM (UTC)

Message

#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?

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #31 on Mon 20 Aug 2007 03:16 AM (UTC)

Message

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.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #32 on Mon 20 Aug 2007 08:44 AM (UTC)

Message

Quote:

... does wxLua do the same?

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.

- Nick Gammon

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

Posted by

Shadowfyr USA (1,787 posts)

Date

Reply #33 on Mon 20 Aug 2007 03:47 PM (UTC)

Message

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.

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #34 on Mon 20 Aug 2007 04:27 PM (UTC)

Message

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.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Shadowfyr USA (1,787 posts)

Date

Reply #35 on Tue 21 Aug 2007 06:00 PM (UTC)

Amended on Tue 21 Aug 2007 06:02 PM (UTC) by Shadowfyr

Message

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.

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #36 on Tue 21 Aug 2007 07:09 PM (UTC)

Message

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.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #37 on Tue 21 Aug 2007 10:54 PM (UTC)

Message

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.

- Nick Gammon

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

Posted by

Shadowfyr USA (1,787 posts)

Date

Reply #38 on Wed 22 Aug 2007 04:02 AM (UTC)

Message

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.

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #39 on Wed 22 Aug 2007 04:59 AM (UTC)

Message

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.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Worstje Netherlands (899 posts)

Date

Reply #40 on Wed 22 Aug 2007 08:04 AM (UTC)

Message

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.

Posted by

Onoitsu2 USA (248 posts)

Date

Reply #41 on Wed 22 Aug 2007 09:32 AM (UTC)

Message

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.

Laterzzz,
Onoitsu2

Posted by

Shadowfyr USA (1,787 posts)

Date

Reply #42 on Wed 22 Aug 2007 06:53 PM (UTC)

Message

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

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #43 on Wed 22 Aug 2007 10:24 PM (UTC)

Message

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.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #44 on Wed 22 Aug 2007 11:06 PM (UTC)

Message

Please see: http://www.gammon.com.au/forum/?id=8132

- Nick Gammon

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

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.

108,480 views.

This is page 3, subject is 3 pages long: 1 2 3

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

Go to topic: Search the forum

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.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )