Qt/GObject: who cares? (was: Re: Conclusions and a compact list of requirements for deconf-spec)

[Philip Van Hoof]

On Sat, 2005-12-10 at 16:06 +0100, Christian Neumair wrote:

> I don't think this is important at all. After all, we've never been
> enemies and everybody feels nice with a working solution. We'll see
> GStreamer adoption of KDE, and I feel perfectly fine with using Qt
> software as a daemon, taken that beginning with Qt4, there is also
> available a non-GUI library QtCore [1].
> Whatever technology is picked to write the first usable daemon should be
> used.
> 
> If people still feel like using two daemons, we could at least merge the
> parsing-related code.


Very correct. My intention for deconf-desk is was or will be to build
everything as extremely reusable shared libraries. And build a very
small daemon application that makes those shared libraries talk to each
other in such a way that they'll operate as a service in a client-
service paradigm.

Another such paradigm would be a mobile desktop-application library that
operates without a service (does it's writing and reading directly).
This to eliminate the need for a service process (which is a request).
But using the exact same "extremely reusable" libraries.

I've already finished this possibility. Whether or not you're going to
use a service depends on how you link the libraries. There's no
compilation switches (ifdefs). Only linking it makes the difference.

Some (important) people have been therefore calling the project
overkill. Most of them have simply misunderstood the very reasons for
some decisions.

There's indeed two component to inject "D-BUS". Namely a frontend for
the service and a bridge for the library (frontend/dbus and
ddbridge/dbus). But compiling with a ddbridge/direct that'll link
directly with the "backend" will give you a library that doesn't use a
service. Yet building a service (with the same backend component and the
dbus component as frontend) and a library (with a dbus bridge component)
will let your desktop applications use a client-service paradigm.

That is my futuristic idea for deconf-desk. And yes, there's code and
prove of concepts. The code already proves the concept. It does .. work.

-- 
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be