Designing a gui library for Python

[scru]

Several things have led me to writing this post

However, late last week I did some poking around in the Windows C API from ctypes (not using pywin32) for a project I was finishing up, and I loved it!

Since then I've been playing around with ctypes and Windows function calls (mostly the GUI related ones).

Now I want to take it a step further and make myself a small GUI library for python 3. What I'm interested in is how I could go about designing the object hierarchy among other things.

As a community of python users, this would be an ideal place to start asking questions. I welcome you to sound your ideas and suggestions!

On a slightly related note. I think I may have figured out why wxPython is unstable on python 2.6 (on Windows Vista), but perhaps I should start a new thread for that?

[jrcagle]

Now I want to take it a step further and make myself a small GUI library for python 3. What I'm interested in is how I could go about designing the object hierarchy among other things.

As a community of python users, this would be an ideal place to start asking questions. I welcome you to sound your ideas and suggestions!

First of all, cool project!

Second: are you nuts?!! :) Seriously, though ... it will take a team and a lot of effort.

Third: You might start by contacting Fred Lundh and Robin Dunn and asking them what did and did not work well with Tkinter and wxPython, respectively. And you could include also glade and gtk, though I haven't used those. And pygame.

My own thoughts:

(1) The learning curve for wxPython was rather steep. I feel comfortable now putting together apps, but it was not natural. (Ditto for the C API -- too many magic methods). The top priorities for a graphic toolkit, I would say, are stability, performance, and codability -- meaning clarity of overall structure, so that a coder can quickly and accurately write what (s)he wants.

(2) Tkinter had a shorter learning curve, but it suffers from a fatal flaw: it's not (to my knowledge) customizable. If possible, the clear overall structure I mentioned in (1) should float on top of a fully customizable layer so that users can get down to the metal if they so desire.

That, and the .validate methods in Tkinter can't actually catch everything they need to ...

Just implementing those two wish-list items ought to keep you off the streets and out of trouble for a good year or so ;)

(3) Document as you go and provide a stable, updated documentation system for your API. Slogging through the online docs for Tkinter and especially wxPython has been a painful experience, caused apparently because the code got out ahead of the documentation.

(4) It would make sense to include a "Boa Constructor"-like widget constructor as a part of the package.

These are non-expert opinions, so salt well before imbibing!

Jeff

P.S.

On a slightly related note. I think I may have figured out why wxPython is unstable on python 2.6 (on Windows Vista), but perhaps I should start a new thread for that?

New thread.

[scru]

Yeah I'm a little bit nuts, actually :). Thanks for the suggestions. I happen to agree with some of them.

[scru]

One of the first things I'm doing is to make some generic dialog classes based on the Windows Vista TaskDialog (but gracefully fallback to normal dialogs on older versions of Windows).

I've already created a fairly high level TaskDialog class, a Save/Don't Save dialog and a task dialog function that replaces message box. The great thing about them is that they can be used in just about any windows based python app (whether it uses tk, or wx, or whatever) and if you can a window handle with your toolkit (wx supports this), you can make them modal too.

I might be interested in handing over my TaskDialog class to the wxPython code tree, if they want it.

[Stefano Mtangoo]

Hello Scru,
I can say it is good project but prepare for tough-time-taking task.
Here are my three suggestions:
1. Make New toolkit -- Create Python classes that interfaces Win32 API with python. i.e. wrap functions from win32 api with pythonic type

2. Join wxpython Dev team and extend it where it lacks, create new widgets...etc
3. Create another win 32 module for python that will be more eay and well documented.

Don't be afraid to start, because once you start and progress one step, people will join you!

Not expert in Big project though :)

[scru]

Free time is one thing I have to spare. :)

Does anyone who uses wx want to help me test the dialogs?

[Stefano Mtangoo]

Just put the code or exe and we will
Personally I can do only in spare time

[lllllIllIlllI]

Yeah i can help a bit as well... maybe a bit slow.. i have a broken computer and i am left with using an old decrepit computer from years and years ago

[scru]

I made a preview release on sourceforge: http://curtains.sourceforge.net/

Just download the installer for your version of python and use the curtains.TaskDialog class. If you have wx, you can use the curtains.save_or_not_dialog_wx function.

[Stefano Mtangoo]

I'll test

[lllllIllIlllI]

Okay, i dont know if this is a bit of a dump question but how do i install it? I keep getting a system exit when i try.

Oh and by the way, i read it was not based on anything, so wow. Does it work using ctypes or something like that?

Well done, it looks really nice so far though. The website and the API.

[scru]

Yep I used ctypes to make the raw win api calls.

More importantly what you mean System Exit? What version of Windows and Python are you running, and did you get the source or the installer?

I have a sneaky feeling that after all that time struggling with distutils yesterday I still screwed something up

[lllllIllIlllI]

Woops silly me, i didnt download the .exe installer. Okay well its installed now.. But im at a loose end.. Can you tell us how we would be able to test the taskdialog. Because my current code:

#testing Curtains

import curtains

def tester(event):
    print "hello"

f = curtains.TaskDialog("Hello",'World',"Please do smething", "retry")
f.bind(curtains.BUTTON_CLICKED,tester)
f.show()

This raises an error:
NameError:global name 'indirect' is not defined
Line 8 in module: f.show()
Line 307 in show: indirect(byref(conf), byref(button), byref(radio), byref(checkbox)

So if there is something i am doing majorly wrong just post it. It would be lovely to just post a simple example of a working taskdialog.

[scru]

That code should work if your system has the task dialog.

That should only happen if the task dialog isn't available on your system, which should only happen if you're using an OS older than Windows Vista.

If you have Vista or later, check in [pythondir]\Lib\site-packages\curtains for a file called comctl32.manifest. If it's there, and you're using Vista or later, then this is a bug.

What is the value of your curtains.TASK_DIALOG_AVAILABLE variable?

[lllllIllIlllI]

Ah the value is False. Does that mean that curtains will not work unless you are using something like Vista? Or is there some way that i can make it work on XP?

[lllllIllIlllI]

Oh and the comctrl32.manifest is there. Is that a problem? Should i delete it or something?

[scru]

No, curtains will work on XP. The TaskDialog won't because MS didn't port it back. What I plan to do is implement all the Windows controls (regardless of availability) and let the users of the toolkit choose whether or not to use them. Features that whose availability is volatile would have an *_AVAILABLE variable to help provide fallback behavior. Notice that the save_or_not_dialog works, but displays as a standard Message Box since you don't have a TaskDialog.

The comctl32.manifest is part of a hack I cooked up in order to get the controls to look nice (and get the TaskDialog to work, even on systems where it's available). But no, you shouldn't delete it.

I'm sorry that the TaskDialog cannot work for you, since this entire preview release is built around it, and going through all that was essentially a waste of time for you. I'm torn on what to tackle next (so much to choose from), but if you haven't been totally turned off, I would try to make it something that you can use.

Also, adding a fallback TaskDialog class based on normal dialogs (but acts like a task dialog) is something I'm considering adding to the list of things to implement once the basics are covered.

[lllllIllIlllI]

Yep, save or not works well. Well done so far scu