Re: Hooking things up in GUI application
Ryan Ginstrom [EMAIL PROTECTED] wrote: Behalf Of sturlamolden If you use PyGTK (it also runs on Windows), you can design the GUI with GLADE and then use libglade to import the gui as an xml-resource. Yes, I've tried something similar with wxGlade. Nice, but it doesn't seem to remove the most tedious work -- hooking up handlers (although it does help here, at the cost of some behind-the-scenes magic), and getting data into and out of GUI widgets. Kiwi http://www.async.com.br/projects/kiwi/ looks promising, but it is under heavy development and you have to learn it by examples. Florian -- Emacs hat den weiten Weg von krank, nur krank bis komisch hinter sich. [David Kastrup in [EMAIL PROTECTED]] -- http://mail.python.org/mailman/listinfo/python-list
Re: Hooking things up in GUI application
Ryan Ginstrom wrote:
Apropos recent threads about GUI editors, coming from a Win32/WTL C++
background, I actually like the idea of being able to (easily) create GUIs
programmatically.
But I still see a lot of the same tedium: hooking up events to handlers, and
getting data into and out of dialogs. In C++, this is generally handled
through code generation and/or macros, but IMO these are brittle and ugly.
So my question: Is there a Pythonic way to make these tedious hookups easier?
If you use PyGTK (it also runs on Windows), you can design the GUI with
GLADE and then use libglade to import the gui as an xml-resource. You
have to write all handlers (you do anyway), but the GUI design becomes
entirely visual and the hookup becomes one single like of code. It
doesn't get easier than that. As a bonus you get an hardware
accelerated GUI (Cairo takes care of that, currently through OpenGL but
a DirectX backend is planned). I.e. a hardware accelerated GUI
represented as an XML resource. Isn't that Microsoft's next 'big thing'
codenamed 'Avalon'? I wonder where they got the idea.
This should illustrate the level of tediousness when using PyGTK:
import pygtk
pygtk.require('2.0')
import gtk
import gtk.glade
class MyGUI:
def __init__(self):
win1 = libglade.GladeXML('mygui.glade','window1')
win1.signal_autoconnect(self) # hook event handlers, pass any
class or dictionary
win1.maximize()
def on_win1_destroy(self):
gtk.main_quit()
if __name__ == '__main__'
gui = MyGUI()
gtk.main()
You cannot make it less tedious in C++. Even if you use Visual Studio
and all sorts of 'wizards' to autogenerate code. Actually, if you do
use C, C++ or Ada, GLADE can autogenerate code just like Visual Studio.
But since an XML resource us much easier to modify and maintain, it is
not recommended.
--
http://mail.python.org/mailman/listinfo/python-list
RE: Hooking things up in GUI application
Behalf Of sturlamolden If you use PyGTK (it also runs on Windows), you can design the GUI with GLADE and then use libglade to import the gui as an xml-resource. Yes, I've tried something similar with wxGlade. Nice, but it doesn't seem to remove the most tedious work -- hooking up handlers (although it does help here, at the cost of some behind-the-scenes magic), and getting data into and out of GUI widgets. That's the kind of boilerplate code that makes GUI development a pain in my opinion -- the actual GUI design/layout isn't so bad, especially with the spacer layout concept. -- Regards, Ryan Ginstrom -- http://mail.python.org/mailman/listinfo/python-list
Re: Hooking things up in GUI application
Ryan Ginstrom wrote: Behalf Of sturlamolden If you use PyGTK (it also runs on Windows), you can design the GUI with GLADE and then use libglade to import the gui as an xml-resource. Yes, I've tried something similar with wxGlade. Nice, but it doesn't seem to remove the most tedious work -- hooking up handlers (although it does help here, at the cost of some behind-the-scenes magic), It does, there is just *one* line of code for hooking up all the handlers: win.signal_autoconnect(something) That is one line of code for the entire window, not one line of code for every widget in the window. Even if your window contains 100 widgets (buttons, sliders, menus, etc), this hooks up the handlers for every one of them. You just call .signal_autoconnect once. This single line of code does the job of all the message map macros you would write in MFC, Fox and wxWidgets. signal_autoconnect does what it says, it autoconnects the signal handlers. How can that be tedious? Here is an advice: just be lazy. In particular: * Don't create write a dictionary mannually and feed it to signal_autoconnect. Many tutorials do that. It is silly: it is tedious, it is superfluous bloat, and the job has in fact aldready been done. Write a class instead. Guido has made sure every class has a dictionary. Just make sure you have class methods with names corresponding to the signals. Pass a class reference to signal_autoconnect. * Don't grab references for every widget out of the xml. I've seen done that in many tutorials too. It is silly. Just ask the xml for a reference when you need one. The xml resources will store the widget references for you, you don't need to save them anywhere else. Storing a hundred widget references as class variables is tedious and superfluous work, and does not do anything except bloating and slowing your code. and getting data into and out of GUI widgets. It does not save you the job of writing the GUI handlers! It saves you the job of coding the GUI (delegate that job to a graphical designer!) and hooking up the handlers. But you still need to *write* the handlers. That's the kind of boilerplate code that makes GUI development a pain in my opinion -- the actual GUI design/layout isn't so bad, especially with the spacer layout concept. At least you get the GUI design out of the rest of your code. The application logic still need to be there. -- http://mail.python.org/mailman/listinfo/python-list
Re: Hooking things up in GUI application
Ryan Ginstrom wrote: Yes, I've tried something similar with wxGlade. But GLADE is not wxGlade :-) wxGlade is a GUI designer for wxWidgets and wxPython. It looks a bit like GLADE on the surface, but does not share any code with GLADE. GLADE is a GUI designer for GTK, gtkmm, Mono, GNOME and PyGTK. http://glade.gnome.org/ http://www.pygtk.org/ http://www.mapr.ucl.ac.be/~gustin/win32_ports/ -- http://mail.python.org/mailman/listinfo/python-list
RE: Hooking things up in GUI application
Behalf Of sturlamolden Ryan Ginstrom wrote: Yes, I've tried something similar with wxGlade. But GLADE is not wxGlade :-) Yes, I'm just saying that I've done something similar to your example. In fact, wxCard also does this auto-generation of handlers. That's a start, but it's still auto-generated code -- XML doesn't save you from that -- and it doesn't do the meaty stuff. (I chose wxWidgets over GTK because, despite GTK-Wimp, I think wxWidgets' support on Windows is better.) There are many philosophies to GUI design, and mine problably isn't the best, but I actually like having my design in the code. I think it saves a layer of abstraction, it's easier to test/modularize, and still doesn't prevent you from separating the GUI layer from the business logic, especially in a language like Python. But I don't want to argue this point, just state that this isn't the problem I want to solve. I really liked the idea of KVO/KVC in Cocoa that James Stroud mentioned. That is what I am after, or something like that. If there isn't anything like that, I think that it might be worthwhile to port it to Python in some form. It seems at first glance that it would be fairly easy to do. -- Regards, Ryan Ginstrom -- http://mail.python.org/mailman/listinfo/python-list
Re: Hooking things up in GUI application
Ryan Ginstrom wrote: But I don't want to argue this point, just state that this isn't the problem I want to solve. I really liked the idea of KVO/KVC in Cocoa that James Stroud mentioned. That is what I am after, or something like that. If there isn't anything like that, I think that it might be worthwhile to port it to Python in some form. It seems at first glance that it would be fairly easy to do. I must admit I don't know the KVO/KVC in Cocoa so I had to look it up. It seems they are accessing widget property values through text strings called 'key values'. In Python we have dictionaries, and dictionaries have 'keys' and 'values'. So it should be trvial to make a system where widget attribute values gets stored in a dictionary. One would just have to subclass the Python dictionary in order to send an update signal whenever an item is written to. In PyGTK we can create and access a label (static text) like this: label = gtk.Label(str) label.set_text(str) str = label.get_text() With 'KVC' (key value controller) design it could perhaps be changed to: label = gtk.Label(str) label['text'] = str str = label['text'] It does not save any lines of code. But it adds the possibility of checking if a widget has an attribute through the 'in' operator. E.g. to make everything red, for widget in wigets: if 'color' in widget: widget['color'] = 0xFF I am not sure how useful this would be. Then there are 'properties', as one can find in Hejlsberg's creations Delphi and C#. This is possible too, using Python properties, which is merely a copy of Delphi properties. Then would have something like label.text = str str = labe.text Still the amount of code remains the same. But perhaps the property solution is the more readable. I don't know. I guess it is a matter of taste. http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/index.html#//apple_ref/doc/uid/1107i http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html I don't use Wimp. These days, GTK looks good on Windows without Wimp. But yes, GTK apps do get their own 'personality' (aka look and feel). But so does many Windows applications. Microsoft Office has it's own widget set, so does Mozilla, SPSS, LabView, Matlab, Internet Explorer, etc. There is really not a consistent widget set, not even on Windows. MFC/ATL/WTL use Windows GDI controls, C# use .NET/GDI+ controls, .NET 2.0 has controls slightly different from those in .NET 1.1 (e.g. menus and toolbars), Visual Basic 6 had ActiveX controls that were similar but not identical to GDI controls, Delphi (VCL) has its own controls, so does Qt and FOX. The GUI consistency on Windows is an illusion. I am not worried about the minor differences between GTK and GDI as long as my program looks good. -- http://mail.python.org/mailman/listinfo/python-list
Hooking things up in GUI application
Apropos recent threads about GUI editors, coming from a Win32/WTL C++ background, I actually like the idea of being able to (easily) create GUIs programmatically. But I still see a lot of the same tedium: hooking up events to handlers, and getting data into and out of dialogs. In C++, this is generally handled through code generation and/or macros, but IMO these are brittle and ugly. So my question: Is there a Pythonic way to make these tedious hookups easier? --- Regards, Ryan Ginstrom -- http://mail.python.org/mailman/listinfo/python-list
Re: Hooking things up in GUI application
Ryan Ginstrom wrote: Apropos recent threads about GUI editors, coming from a Win32/WTL C++ background, I actually like the idea of being able to (easily) create GUIs programmatically. But I still see a lot of the same tedium: hooking up events to handlers, and getting data into and out of dialogs. In C++, this is generally handled through code generation and/or macros, but IMO these are brittle and ugly. So my question: Is there a Pythonic way to make these tedious hookups easier? --- Regards, Ryan Ginstrom I'm not sure any python gui has anything similar, but I hear cocoa users raving about something called KVO. James -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com/ -- http://mail.python.org/mailman/listinfo/python-list
