[Desktop_architects] [Announce] "Common Desktop Infrastructure" 0.1.0 is released

[Paul Davis]

On Tue, 2008-02-19 at 20:18 -0300, Tiago Vignatti wrote:

> I agree with you that we must reuse some components in the various 
> technologies (UNO, QtDBUS, etc..) to deliver interoperability among 
> applications but I'm afraid that we must "move down the stack" a
> little.

This is a hand-waving assertion. You've provided no evidence to support
your claim.

> For instance, how a developer of KDE, GNOME, Mozilla or other would not 
> change some component technology if a low level application changes (say 
> some API inside X server)? In my conception only if we have a steady 
> graphical architecture interface in Linux we can start something like 
> the Common Desktop Infrastructure development platform to connect the 
> existing components/protocols. And this is the big point today: we 
> *don't* have a stable graphical architecture. 

The X Library API, let alone the X11 protocol itself are more stable
than any other comparable "graphics architecture" you can name. The Xlib
API has been stable for nearly 2 decades now, unless you want to include
extensions, which are almost never, ever the domain of a typical
application (over the years, they have primarily affected window
managers).

The functionality you are referring to, I believe, has very little do
with the code of a graphics architecture (it may intersect a little with
issues related to openGL, compositing and WM support). Instead, it has
everything to do with GUI toolkits. The only reason there is no "stable
graphical architecture" for Linux is that there are at least two. And
there will continue to be at least two no matter what you, or I or
anybody else on this or any other mailing list says about it.

Suggestions for ways to improve the ISV experience on Linux that involve
pretending that GTK and Qt do not simultaneously exist, simultaneously
offer different solutions to the same problems (mostly), and likewise
for Gnome and KDE, are essentially dead on arrival.

What is exciting about Portland (to the extent that anything is) is that
it doesn't repeat the same tired story of how we need to get down inside
X and do stuff there. Portland operates at or above the GUI toolkit
level which is just about where it should stay.

--p