2009/11/21 Carlos E. R.
While it would be possible to achieve functionality and usability goals in either toolkit, the Qt UI is far better able to 'pass' as native gtk+ app, because it actually uses gtk+ to paint its UI when using QGtkStyle, whereas a gtk+ app can only mimic Qt's look and feel. It's like Tom Cruise's Mission Impossible synthetic skin disguises vs. the stick-on moustache approach of 60s spy flicks. So no, it wouldn't be worth it. And I know you have a soft spot for C++ ;).
I don't understand why both interfaces have to be so different. To me the ideal would be an engine with different display modules (gtk, qt, ncurses, web) with all a similar display and usage.
Me to, though having a couple variants allows change without disrupting everyone at once, there's an automatic fall back. Making one core engine, which supported all the interfaces above, would make it much harder to change, as you'ld have to update all the client display & interaction modules to at same time. That said, in recent "Who runs GNOME?" thread on forum, programs like K3b were claimed by some GNOME-ites as native applications. We don't only have 256MiB RAM these days so the client library over-head is less critical. One example firefox used to be unacceptably fat and sluggish to me on a KDE system, whereas now it's viable as the default browser. So I think Will has a point, that the Qt based programs are likely to be able to fool many end users. If there's GNOME/KDE/XFCE interoperability issues, isn't that something to refer to freedesktop.org? Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org