Elektrified X.org released (was: X configuration paradigm, and a proposal)

[Sean Middleditch]

Is the cross posting to four lists *really* necessary for this
discussion?

On Wed, 2004-12-01 at 13:45 -0300, Avi Alkalay wrote:
> On Tue, 30 Nov 2004 13:56:54 -0500, Alan Cox <alan at redhat.com> wrote:
> > On Tue, Nov 30, 2004 at 12:43:16PM -0500, David Zeuthen wrote:
> > > exported through D-BUS), I should be able to write a daemon, let's call
> > > it gnome-input-manager, that runs in the desktop session as user davidz.
> > > This would also allow said daemon to disable the touchpad when I connect
> > > an external mouse or, for more fun, to disable it around intervals where
> > > I'm punching the keys. The reason you want this in the desktop session
> > 
> > You pretty much have to. I've got a hotplug video card here for example.
> > That really ruins the current configuration system. OTOH you have to start
> > somewhere and if the goal is to unify configuration then you want to let
> > someone else rewrite X. However as you and Havoc both point out it has
> > to handle notifiers
> > 
> 
> Good. Elektra has call to get notification. Check the kdbMonitorKey()
> and kdbMonitorKeys() methods in the Doxygen:
> http://elektra.sourceforge.net/elektra-api/html/

>From the docs: "This method will block your program until one of the
folowing happens:"

I'm imaging it works by just re-reading the DB on each iteration.
kdbMonitorKeys has to be a performance monster... Especially if you want
to get notified about a key change in a reasonable period of time.
Let's not even get into the disk seek implications we have here.

This API needs to be efficient and reasonably easy to integrate with
existing applications main loops.

Seriously - suck it up and write a kdbd daemon for this kind of stuff.
There's no good reason not to have one.  For times when the daemon isn't
around (and there's no reason why this should ever be the case, even
during early early bootup, but I have the feeling you'll make that
argument anyhow) you can have the client library access the kdb in read-
only mode and disable features like key notification.

Take a look at how the GConf client interface is structured.  You get a
socket to the configuration server.  If you have a custom main loop, you
can poll/select/epoll/whatever the socket to wait for updates (while in
the meantime blocking on other important file descriptors or running
various timeouts).  When the descriptor has data available, you tell the
library to read as much as it can - if the library gets a complete
notification message, it invokes your callback(s).  This is the absolute
best you can get.  It makes the API *easy* to integrate with Qt, glib,
or any other custom mainloop.



> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.