Spawning windows... Sort of

Posted by Shadowfyr on Fri 30 May 2003 09:25 PM — 10 posts, 27,086 views.

Shadowfyr USA Fri 30 May 2003 09:25 PM #0

From the pages of "Don't Try This at Home" I bring you this:

<alias
 name="test"
 script="runTest"
 match="test"
 enabled="y"
 sequence="100"
>
</alias>

from wxPython.wx import *

#---------------------------------------------------------------------------

class MyFrame(wxFrame):
    def __init__(self, parent, ID, title, pos=wxDefaultPosition,
                 size=wxDefaultSize, style=wxDEFAULT_FRAME_STYLE):
        wxFrame.__init__(self, parent, ID, title, pos, size, style)
        panel = wxPanel(self, -1)

        button = wxButton(panel, 1003, "Close Me")
        button.SetPosition(wxPoint(15, 15))
        EVT_BUTTON(self, 1003, self.OnCloseMe)
        EVT_CLOSE(self, self.OnCloseWindow)


    def OnCloseMe(self, event):
        self.Close(True)

    def OnCloseWindow(self, event):
        self.Destroy()

#---------------------------------------------------------------------------

def runTest(name, output, wilds):
    win = MyFrame(None, -1, "This is a wxFrame", size=(350, 200),
                  style = wxDEFAULT_FRAME_STYLE)# |  wxFRAME_TOOL_WINDOW )
    win.Show(True)

This '**almost**' works. :( The problem appears to be that programs are allowed only one main window. The above uses 'None' to specify the parent window and is basically telling the engine to create a 'main ' window to which others will be attached. Only one problem, Mushclient already has a main and the result is a nasty and spectacular crash. :p

So any ideas how to solve this problem Nick? Like giving us a GetWorldFrameHandle command? lol Probably not, but the above was an iteresting try.

NOTE: The above requires installation of the wxPython and wxWindows libraries. But since it doesn't work yet, don't try it anyway. lol

Poromenos Greece Sat 31 May 2003 09:44 PM #1

I don't know about you, but when someone says "don't try it", i do :p And yes, it doesn't work :p
Could it be done some other way? Hmm, since you can't make another main window, and you can't create a secondary window if you don't know the name, it's hard... It'd be cool though, you'd be able to do anything you with mushclient...

Shadowfyr USA Sat 31 May 2003 10:11 PM #2

Well. The only other way I could think of would be to use the python script to run the dos version of python. The windows engine will die the same way do to the same main vs. child window issue I found out, but only after you close the window. However you would have to use it like an external COM app, registering it, then linking to it after it was running and including the callbacks to mushclient to let it talk back. This is not a good solution imho, since you lose the ability to add buttons or other controls to the resulting window.

If you where going to do it that way, it would be better to make an executable in VB or C++ and add in support for some sort of XML based resource format like can already use with wxPython to load window layouts. However, the existing system would need to be expanded or scrapped, since you can't define behaviours and what the new design should do to inteface with mushclient, so you are stuck designing your own XML implimentation to handle that anyway. I had hoped that the flexibility of this language would provide a versitile and simple way around the issue, but the answer is obviously a resounding no.

Nick Gammon Australia Forum Administrator Sun 01 Jun 2003 04:39 AM #3

What are you trying to do? Create another GUI window? And have Windows messages go through it?

Shadowfyr USA Sun 01 Jun 2003 05:41 AM #4

Basically yes.

The idea was, in theory, to have a window whos callbacks for buttons and the like interfaced directly with the script that called it. Then you could change parts of a plugins script to add a button, or a textbox or anything else supported to the resulting window.

The only currently alternative is to create a COM program in VB, C++ or the like that talks to mushclient and then you have to register it, then make sure it is running and it will be limited to the existing windows and controls that it was designed with. Or if you build one that can be modified, you have to bult your own loadable layout files, use a complex mess of control arrays and junk and any script subs you do call have to use the callplugin interface, which only allows you to pass it a single variable.

If it was possible to use wxPython's existing methods then you can bypass the whole insane mess of having to build a COM program to do this stuff and all the special code that would be needed to get all the controls to talk to mushclient in a reasonably graceful fashion. This is especially true for something where say you have 3 buttons. Cancel, Reset and Ok. With 'Ok' you may want to return the contents of all the textboxes, etc., but 'Cancel' maybe just returns without doing anything and 'reset' only clears the contents of the rest of the page without talking to Mushclient at all. It is a lot easier to add something like OnButton1_Click() to a plugin than to have to design a COM program that knows the difference between that and doubleclick, not to mention what exactly each button effects in my example.

Put simply.. I have been looking for a way to do this for some time to enhance what Mushclient can do, but I am a bit reluctant to dive into the complex issue of desiging a seperate COM program to do this is I can find a ready made solution. Unfortunately it doesn't look like this is it nor am I clear if having such a GUI window, even if running as a child process to Mushclient, would talk back to its own script correctly. But since I can't currently make it one.. Sigh....

Flannel USA Sun 01 Jun 2003 08:31 AM #5

As for the VB thing, it wouldnt be TOO complicated, if all you wanted was the ability to do buttons, text, etc.

Just have a VB program (connected via COM, etc), and have a commandline type thing. Write a small command parser (VB side, to get around the one variable limit for plugins) and have a fairly simple syntax sort of thing, and then have the VB program do it for you, add a button, set its attributes, etc (could even have a 'default' button that you could just copy to simplify property setting).

If you Really wanted to get into it, Could make it an MDI sort of thing, running invisibly in the background, and then spawn children, with an always on top attribute.

It COULD get ugly, but only if you let it (tyring to support LOTS of things, natively, which can be gotten around using add-ins... to an extent)

I think a lot of us have been playing with ideas like this, for a while, I know I have.

One thing I have stumbled upon (and then ran out of free time to explore it) is Bt-suite, its on sourceforge (btsuite.sourceforge.net), its for a battle tech Mud, or mux, or whatever they call it, but it uses Mushclient, and an external program, and is a HUD sort of thing, it uses.... ActiveX, and WSE, you can read a little about it on the page, Like I said, I havent looked into it much yet, so Im not sure if its actually relevant, but definately worth taking a look at.

Nick Gammon Australia Forum Administrator Sun 01 Jun 2003 08:46 AM #6

I think you are trying to do something that is basically impossible, or very difficult.

A Windows program gets messages into its main message loop and deals with them. It can't really spawn a separate window that gets its own set of messages, or not easily.

Also "calling back into" a script is a rather fraught concept. The scripts are only really alive when MUSHclient activates them when necessary. I can't really conceive of how your window would, asynchronously, call a script that really belongs to the MUSHclient address space.

Shadowfyr USA Sun 01 Jun 2003 06:33 PM #7

Well. First off to Flannel. I have seen that. Nice, but too limited. I am looking for something that could be added as a plugin (or to one) and anyone could build any window type they want. Obviously there are limits to what you could do, but there are advantages to Python, beginning with native PNG support which the standard controls with VB and C++ don't have. A lot of people still seem to prefer lossy JPG or paying the owners of GIF royalties for something who only advantage is animation, which standard controls also don't support anyway. The idea is not to support everything, but to provide:

Basic controls:
Buttons
Textbox
Richtextbox
CheckBox
Gauge
Grid (for databases)
... and so on.

Features:
Linking controls - Which ones are effected by what button/option
Send methods - as command, as note, as variable, to script, to script with value(s)
Loadable XML layouts

The problem with the above in C++ is that you spend more time coding the stuff to get controls to work than you do designing the program logic. However the issue with VB is that things like textboxes are fixed to singleline modes and you are not allowed to use the built in drag-and-drop or resize controls that standard ActiveX controls have. I.e. there is no design mode for them in VB. There are ways around those issues, but they require extra code to do. However the problems with both are lack of native PNG, the inability to modify the function of the 'program' as easy and neither one provides its own XML parsing methods. The second is only a minor issue, but it requires all the code to verify values or handle logic to be in the plugin, not the program. The last item means that I have to not only code my own parser, but include all the extended stuff to define how the buttons and fields react in connection to Mushclient and the script that calls to the window. Obviously this is much easier to handle if these basic things are done in the program code than done with the program acting as a sort of chalk board for the client.

Now to Nick. If it was being passed the window handle from the world itself, then technically both the script and the new GUI window would be in the same execution space. It would be effectively attaching the new window to Mushclient as a child of the world's windows. Internet Explorer uses a similar trick with imbedded ActiveX controls, though they never allowed a 'Frame' type. Apparently it made more sense to them to load another bulky and bloated copy of IE instead. However, you may be right about the script itself not waking up to handle the responses, since I don't know exactly how you wake it and obviously if simply having something attached to Mushclient try to talk to it isn't enough, you would need internal support for capturing messages from the resulting window and its controls and passed that along to the script. This may, now that I think about it, be something like what IE does.

Still. It was definitely worth the try. I really wasn't looking forward to trying to figure out how to hammer PNG support into something I would have very much preferred not to write in the first place. Had this proved possible I could have avoided the entire mess and just let the other nuts design their own based off my initial discoveries. ;) lol

Poromenos Greece Mon 02 Jun 2003 12:34 PM #8

Uhh, why PNG? :P It's about 10 times larger than jpg with no visible improvement of quality (or, to put it better, jpg has no visible loss).

Shadowfyr USA Mon 02 Jun 2003 07:47 PM #9

Well.

1. JPG was developed for photos (images of 5000x4000 pixels or bigger). So unless you are storing thousands of such images... Why should 1M bigger of a file for a 'normal' image be a big deal and I think 10 times is a serious over-estimate. Where not talking about building a web page here, where every byte counts.

2. The algorythm used is so outdated that if someone wanted to remake it today, the result will probably compress even better and actually have fewer artifacts if any in most of the images compressed with such a method.

3. The other 'lossless' GIFs only support a 256 color pallete, not full 24-bit images.

4. JPG introduces additional destructive artifacts into 3D rendered images.

5. Badly tweaked version of JPG will either produce files that are no smaller than a PNG, but still have artifacts, or highly compressed ones that look like those from a cheap digital camera (which ironically is due to them using at best 640x480 images with heavilly tweaked versions of JPG to get better compression).

6. Even more normal people rarely use JPG unless it is for a photo and then they often do so because of people that insist that it is the best method, regarless of the actually image resolution, which is patently incorrect.

For some of what I intend to do with my program makes JPG counter productive. However a much better question is why if I specifically want to use a lossless type, I should be stuck using GIF, which compresses even worse than PNG, is a proprietary format and lacks support for some things like transparency settings in an alpha channel. JPG has survived only due to the fact that you can get by with using it on really high resolution images and no one will really notice what it ate in the process and because it has been around since practically the beginning of time from the stand point of computer graphics. There are better methods, most are however either owned by companies that don't make desktop computer software or have only been implimented in experimental tests by people that take one look at all the amazing support that PNG hasn't gotten, in spite of its advantages, and figure they will never make any money off it.

Put simply, if I want to cut something I will use a modern tool, even if it might be a bit bulkier to store, not a cavemans bone hammer and chisel. The result may look more or less the same when building stonehenge, but not if I am laser etching a 6" glass mug. Same is true with compter graphics. You pay a price using JPG, for the stuff I want to be able to do, the price is imo too high.

A test I just did:

Original BMP - 1.37M 800x600x16 million colors
GIF          - 297,772 Smaller only because it 'ate' color information.
  Actually compression was 800x600x256 color = 481,078 >> 297,772.
PNG          - 794,132
  This was 255,492 if you start with 256 colors like GIF did. More than a few sites misrepresent this
  by implying that PNG is 10-30% better than GIF, but fail to point out that GIF won't actually store a
  real photo quality image, since it can't handle the colors. This causes some of the confusion
  about how 'good' they both are.
JPG          - 153,093 but of course this ate pixel data.

I guess it is a case of what is more important. If you preserve the image by dropping the color depth to 256 colors and compressing with PNG, then it is about twice the size. If you want both image quality and color, then obviously it ends up being 5 times bigger. But again, unless you are storing millions of 800x600 24-bit color images on your system, why is saving a few hundred k that big a deal?