[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gEDA-dev: DBUS in external hid?



[snip]

> >The problem with a dbus hid is that it needs to be able to respond to
> >events even when the GUI isn't expecting them.  That usually means the
> >GUI needs to somehow poll for those events as part of its event loop.
> >Thus, the gui needs to know at least *something* about the way the
> >protocol works.

If using the glib bindings (as I have done in my implementation), it
simply adds the required handlers to the mainloop.

> >Although, we could add something like Xt's api for listening on
> >sockets - you register a file descriptor and a callback with Xt, and
> >when there's data to be read on the file descriptor, the callback is
> >called.  We could probably hook that into all the guis somehow.

Indeed.. like this idea, although haven't thought through all the
implementation details. It could be useful in other areas with FD based
IO aswell, and since we can't assume a given toolkit in PCB, having a
generic interface to this core functionality (as the timers already
are), is quite important.

> >Of course, whether that's useful or not now depends on dbus being able
> >to work with that kind of callback.

I don't think the glib biding will (as it assumes glib presence
throughout), but an interface written using the raw "C" API to DBUS
could be persuaded more easily.
> 
> What about adding more general callbacks, not keeping dbus in mind, but
> keeping PCB in mind, then use the external dbus hid as the converter
> layer between PCB and DBUS? This way DBUS is only one of the solutions,
> someone else can write and/or use another lib or home grown code for
> similar things. After all this is what makes a software modular :)

Modular is good, and I'd even thought about the possibility of adding
DBUS via you're GPMI system. Unfortunately, the current implementation
would need to be initialised after a glib mainloop is in existence, and
would only work if that is the case. (A raw DBUS based interface could
work in a pluggable manner so long as PCB provides the right hooks and
callbacks).

Peter C.




_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev