Introduction and toolkit abstraction

[Jono Bacon]

Hi all,

> 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.

I agree that a completely compliant KDE application is difficult if 
impossible to achieve via some kind of automated API translation. The 
point I am wanting to bring up with this thread is that this is a 
problem that is plaguing the Linux desktop and we need to discuss some 
possible ideas to resolve it. We want these ideas to preferably be 
realistic and not just tell people to rewrite the GIMP in wxwindows or 
port Quanta to GTK or something. That is not going to happen - it seems 
that we will *need* some form of middlewhere so that we can hackers can 
hack on what they want and not have to commit to technology they are not 
behind.

> 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 idea of a middleware library was to fill in the major chunks such as 
dialog boxes. It is not ideal and not complete, but would prefer a 
semblence of a solution. Although, with some of the comments from Mike 
it does seem that there are some technical problems that could prevent 
it from working.

> 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.

How do they do this - do they literally have a UI layer for each 
interface? The problem with this is that it (a) feels like a fudge and 
(b) would need more development effort. This is not viable for smaller 
projects.

What I would be interested in exploring is seeing how many user 
interface elemants can be packaged into consistant chunks of 
functionality. As an example, if you take the OK / Cancel buttons - they 
  can be grouped as a common combination. Toolbars can be grouped as a 
common user interface item. The challenge is in determining how an 
application for KDE and an application for GNOME are designed 
differently according to the environments HIG. My impression is that 
different HIG are not hugely different. OpenOffice.org has been used as 
an example, but it does not seem to differ that much from Microsoft, 
AbiWord and KWord. Maybe we need to determine the differences first 
before we can propose a solution?

	Jono

-- 
Jono Bacon - http://www.jonobacon.org/
Writer / Journalist / Consultant / Developer