Looking for feedback on Gnome/KDE article

[Bernhard Reiter]

On Saturday 14 December 2002 21:13, Havoc Pennington wrote:

> The existence of WINE, VCL (OpenOffice), XUL (Mozilla), GTK, Qt,
> kdelibs/libgnomeui (which fork from GTK/Qt a good bit, though
> libgnomeui is actively being folded back into GTK and thus shrinking,
> maybe kdelibs is too), and more, just points to the importance of
> well-defined library-independent specifications for interoperability. 

The importance of well-defined library-independent specifications
cannot be repeated enough.

> Reimplementing everything with the One Grand Unified
> Toolkit is a pipe dream. And if you ever achieved it, someone would
> come along with a better toolkit anyhow. Microsoft keeps replacing
> theirs, plus you have everything from OWL to Qt on Win32.

I think the wxWindows approach 
as an application framework layer  between the toolkits 
is not out of the question.

For completeness of this thoughs someone might mentioned the HTML
gui interfaces. Many application are crudely ported to run in standard webbrowsers.
As a gui toolkit the web is not very good at several areas, still there
seems to be a huge demand for web applications, stressing the demand
the platform independence.

> i.e. "the grand unified font system" is a much better thing to have
> than "the grand unified library that does everything" - modularity
> good. If we ever get the platform mostly unified, it will be by
> creating a series of well-defined common specs or implementations
> along the lines of fontconfig, such that the top layers such as GTK
> and Qt become smaller and delegate lots of their functionality. This
> gives us a gradual migration to platform consistency and de-bloat as
> the right answers become clear, instead of dreaming of wholesale
> conversion of huge codebases.

I agree with the paragraph above.

> My opinion is that the whole free desktop community should be actively
> working on two things in this area for the future:
>
>  a) a simple IPC/messaging system, DCOP-like in scope, over the next
>     year or so - I would like to see us have this by Dec 2003.
>
>  b) longer term, say 2-3 years out, a toolkit-independent solution in
>     the component system or CLR space. i.e. dynamically loadable,
>     fully encapsulated (no private ABI), dynamically introspectable
>     cross-language objects. This is not primarily a GUI system,
>     components are not primarily embedded widgets and in fact one of
>     the main driving forces here is likely to be web applications.
>
> This gives us an IPC system and a component system, which are
> separate, not the same. 

> The faster we can drive well-understood "commoditized" problems down
> into common well-documented modules, the faster Linux (and UNIX) will
> move forward on the desktop.

This summarizes up what many developers think and it makes sense
from the development point of view.

From the users point of view the most important things are task orientated components 
which just integrate and run anywhere thus reducing learning time. 
Usually the division in task orientated components is not the same as the division in 
libraries or components useful for the technical development.
Loosely coupled means that you can just take a mailer, an editor and a desktop system
and they will just work even when they don't know anything specific about 
each other. This requires good interfaces for the possible interactions.

Editing seems to be a task that is clearly identified to be separable,
thus the example I usally give when talking about task orientated components
is "vim".  It runs almost anywere (terminal, MacOS, W32, GTK) making me
independend from the desktop and operating system.

If you agree that task orientated components are interesting for users
then you can understand why application framework layers like wxWindows, 
with its approach to use the native widgets on each platform still have a good potential.
This thought also limits the use of component systems where you depend on components
to be present thus not being tightly coupled. Again good interfaces are a remedy
against too much dependency.

So yes, I believe the thoughts Havoc wrote up grow beyond KDE and Gnome.
	Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030116/3eb53895/attachment.sig>