--Boundary-02=_BttJ+2y3cVBX8Zv
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

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

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=20
as an application framework layer  between the toolkits=20
is not out of the question.

=46or completeness of this thoughs someone might mentioned the HTML
gui interfaces. Many application are crudely ported to run in standard webb=
rowsers.
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.=20

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

=46rom the users point of view the most important things are task orientate=
d components=20
which just integrate and run anywhere thus reducing learning time.=20
Usually the division in task orientated components is not the same as the d=
ivision in=20
libraries or components useful for the technical development.
Loosely coupled means that you can just take a mailer, an editor and a desk=
top system
and they will just work even when they don't know anything specific about=20
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,=20
with its approach to use the native widgets on each platform still have a g=
ood potential.
This thought also limits the use of component systems where you depend on c=
omponents
to be present thus not being tightly coupled. Again good interfaces are a r=
emedy
against too much dependency.

So yes, I believe the thoughts Havoc wrote up grow beyond KDE and Gnome.
	Bernhard
--Boundary-02=_BttJ+2y3cVBX8Zv
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+JttBh9ag3dpKERYRAt7TAJsFCIlVfHi1Nd/fpCKRm+umYZjQnACffmKA
rcwTvAeswdjbEVOwrhzVDDg=
=jG1r
-----END PGP SIGNATURE-----

--Boundary-02=_BttJ+2y3cVBX8Zv--