Introduction and toolkit abstraction

[Sean Middleditch]

On Wed, 2004-09-01 at 11:52 +0200, Meghazi Fabien wrote:
> > I don't know why either. I really like wxWidgets, as it now has to be
> > called thanks to the glories of Microsoft trademarks. Specifically, I
> > like wxPython. It's seamless across UNIX, Windows, and (almost?) Mac.
> > It'll handle a bunch of native toolkits, or be a toolkit in its own
> > right.
> > I think it's fantastic. I'm a big fan. It's GPL compatible, but a
> > permissive license for the commercial apps (of which there are many,
> > such as the AOL software). Sure it's not perfect, and the C++ is
> > weird enough that I use the wxPython binding instead, but it works.
> 
> I like wxWidget too. I wonder if it would be possible to promote wxWidget by 
> releasing a version of wxWidget for each window manager. Eg: the gnome 
> version would bind with gtk+ AND gnome  widgets, the KDE version of wxWindow 
> would use qt AND KDE widget, and so, each Window manager community could 
> release its own version of wxWidget with their look'n feel and widgets so the 
> wx lib would be used in correlation with the currently used desktop.

"Desktop Environment", not "Window Manager".  Big difference between the
two: KDE and GNOME include WMs, but they themselves are a whole heck of
a lot more than just a WM.  ;-)

wxWidgets isn't going to be easily promoted for several reasons.  First,
the language problem.  The GNOME devs like C and want to keep things
that way.  The Qt devs love the Qt API and want to keep things that way.
Also, wxWidgets, and any other common toolkit, would be forced to use
the least common denominator among the desktops - unique widgets and
features in one desktop toolkit could not be used at all, since no other
desktop would have it.

And it still doesn't fix the real problem.  The look of the widgets is
*100% meaningless* when it comes to integration.  We can already make
GTK+ and Qt apps look identical using theming. The real problem is
application design.  An app designed for KDE, independent of theme or
even the toolkit used, will act and feel completely alien in GNOME; the
layout will be all wrong, the style of design will be all wrong, the
main operational design will be all wrong.

My OpenOffice.org installation already *looks* identical to the rest of
my GNOME desktop.  It even uses many native GNOME dialogs, and will be
using more soon.  But it still feels completely alien and acts just like
a Windows app.  Why?  The design is based on MS Office, which in turn is
a style of widget selection, layout, menu organization, prefernce
handling, and so on which is completely wrong for the GNOME desktop.
They don't even need to use GTK+ to fix OpenOffice.org from a user
perspective.  They do need to gut and redesign the entire UI and
behaviour, however.

You *cannot* get real integration by using some library.  You *must*
alter the design of an app for each desktop to make it integrate
appropriately.  You'll need, at the bare minimum, different UI
specification files (assuming Glade or a similar technology is used) for
each desktop.  For desktops where major modes of operation differ (such
as GNOME vs Windows preferences handling, KDE vs ROX file saving
handling, etc) you'll have to recode those whole sections of the app to
behave the way you want.  Etc.

The only major app I've seen that does cross platform and does it right
is Abiword.  Why?  Because they UI is recoded for each target, so that
it not only *looks* native, but feels and acts appropriately for each
target platform.  You want AbiWord to integrate cleanly with KDE?  Give
them a KDE front-end.

Until you find a way to abstract the actual design and behaviour of all
parts of an application behind a toolkit API, you can't solve this
problem at the toolkit level.  You have to solve it at the application
level.

> 
> Hum... I don't know if I'm explaining my idea the good way. It looks silly 
> when I read it back.
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.