View Single Post
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#112
Originally Posted by lpotter View Post
Having two differing widgets/application based on the same codebase is only a minor inconvenience, easily handled with #ifdefs and differing ui forms, if even needed. Heck, you can even load the ui forms at runtime, offering the ability to change the gui without recompiling. Not to mention Qt Kinetic.
My problem with that was that more complex Qt projects tended to have 'smart' dialogs and forms, many of the actual signals, actions, etc defined in the forms. Which is cool and makes it easier to see what's going on, except if you want to swap in another UI (say, because you were porting an UI to WinCE), it turns into a hellish tar pit. So you had a choice of throwing out the sophistication of QDesigner and do coding UIs head-to-code, like Real Men, 1999 style, or battle the bugs of never-quite-in-sync .UI-s. And peppering code with #ifdefs by design in a multiplatform framework is also a bit of a drag in 2010. For me, thus, the question is not how difficult it is, but rather if it is really necessary or not (we could just as well have a QMacApplication and a QWinApplication, but we don't and that's not because it's hard to put an #ifdef around it). Just my 2 cents
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 

The Following 5 Users Say Thank You to attila77 For This Useful Post: