[PyKDE] Stuck newbie

Dave Fancella 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 
place.

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.

Dave

> Joh
>
> _____________________________________________________________________
> Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
>
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde




More information about the PyQt mailing list