[PyKDE] Stuck newbie
dave at davefancella.com
Wed Oct 11 09:03:04 BST 2006
On Wednesday 11 October 2006 1:33 am, johannes_graumann at web.de wrote:
> Thanks once again for your help. I failed to comprehend the difference
> between action and button ...
ah. If you're still having trouble with this, here goes. :) (If you know
much about gui programming, you can probably ignore me, I haven't been
following closely enough to know if this will help you)
Action is just a widget that contains connector code. Typically, in an ideal
application, you want to separate the GUI from code that does real work. So
you create a QAction to connect to real working code, like saving a file or
computing a grade or whatever. Then you connect that action to various
widgets. QAction in particular has built in support for being added to
toolbars, menus, and so forth, so you can collect the actions all into one
Back in the days before we had good widget sets like Qt, we had to override
event handlers in an inheritance setup. This had the bad effect of promoting
coding tactics that put real work code into the event handlers themselves.
This makes it so that several bad things happen. One is obvious. You have a
toolbar and a menu, and both have "save" items, but both call different code
to do the saving. You didn't have to do this, but it required real work and
something resembling good work ethic to avoid it. The other really bad thing
besides teh code duplication was maintaining it.
Qt does just about everything imaginable to promote the ideal model where you
have your work code separated from your GUI code. QAction is just part of
it. The new model/view setup is really sweet. :) Anyway, you still
typically don't want to put work code inside QAction. At least, I don't. I
go ahead and put it somewhere else and have all my QActions call it, so
QAction winds up being a class that just holds icons, titles, keyboard
accelerators, and lets me plug them in wherever I want to plug them in. Some
guys are really hardcore about always connecting every single signal to a
QAction slot, but I'm not. If you do that, though, then it makes sense to
put real working code in your QActions in many applications. And as an added
benefit, if you construct QActionGroups, you can very easily and quickly
create menus and toolbars with them, and even share that code between
applications very easily.
I guess you probably already know that stuff, but I found it helpful to put
QAction in context by imagining what Qt would look like without it.
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> PyKDE mailing list PyKDE at mats.imk.fraunhofer.de
More information about the PyQt