On Wednesday 11 October 2006 1:33 am, [EMAIL PROTECTED] 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 [email protected] > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
