This mail may be a duplicate, as I tried to send a similar one yesterday, but then the web connection to GMX broke down. Sorry, but mailing from an internet cafe isn't fun.
What I wrote was that before my holiday I started as similar project to the one you are doing. Actually I started at the beginning of the year, but left it lying around until two weeks ago. What I wanted to build was an Objective-C binding for DBus. That is full integration to send and recieve DBus messages as Objective-C method calls. I have part of this working, which should be enough for the simple calls Etoile and you are currently doing, but the more complex parameter types are still missing. My aim is to have the final product as a library in GNUstep (in dev-libs to be exact). If you are interessted and willing to share your code, we could work together. You would have to accept to put your code under LGPL and assign the copyright to the FSF. Please connact me directly (in German?) if you are still interested, given this conditons. Cheers, Fred -------- Original-Nachricht -------- > Datum: Thu, 27 Sep 2007 22:59:20 +0200 > Von: "Andreas Schik" <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: [Etoile-discuss] HAL and DBus in Etoile > Hello Quentin, > thanks for the answer. > See below. > > Am 27.09.2007, 15:43 Uhr, schrieb Quentin Mathé <[EMAIL PROTECTED]>: > > > Hi Andreas, > > > > Le 26 sept. 07 à 09:28, Andreas Schik a écrit : > > > >> Hi all, > >> I wonder whether the Etoile project would be interested in integrating > >> support > >> for HAL and DBus. > > > > I think so. At least it offers the possibility to immediately leverage > > existing Freedesktop work rather than rewriting every pieces of this > > abstraction layer in SystemConfig framework. > > > > As a side note, /Etoile/Services/Private/System implements reboot, shut > > down and sleep with DBus requests passed to HAL. It's currently the > > only way to do it cleanly because System is run as the user session and > > as such cannot directly ask the host system to reboot, shut down etc. > > HAL daemon by being run as root is precisely able to handle these > > operations. > > However this should change in the future, System will be reworked into a > > > framework providing session nesting (like system/init, user, project > > sessions). At this point, running system/init session with root > > permission should become possible. > > > >> I am currently not quite up-to-date to the latest > >> developemnts in Etoile. Maybe there already exists something which I > >> have > >> missed. > > > > No, in System I just use glib DBus wrapper to message HAL. It isn't > > truly nice and involves glib dependency, but writing an ObjC DBus > > wrapper would be a lot of work so I'm not really convinced it's worth > > the investment for us. If someone decides to write one, we are surely > > going to be interested by bundling it with Étoilé though. > > > I just had a look at the suff in /Etoile/Services/Private/System. Well, > yes, it is quite rudimentary, but I do not see any dependency to glib. It > only dbus and hal. Or did I miss something? > Concerning the ObjC wrapper, I think it is definitely worth to try it. If > you want to at least partly to comply to the fredesktop specs (which you > should do, imho) you will actually need it. And it saves you a lot of > coding concerning hardware related stuff, particularly hiding the nasty OS > > details. Dbus and HAL exist on more or less all *nix like OS. > It is a lot of work, that is right, but I think you can do it step-by-step > > as particular services are needed. The most complex part will probably the > > message handling (what you use for your services at the moment). To > encapsulate this in a manner that hides the ugly details is probably the > biggest challenge. Receiving notifications about HW and its properties is > quite easy. The most work here is to implement this rather big API, but as > > already said, this can be done on demand. > > >> I have made up something simple for my battery menulet, which could > >> serve at > >> least as a basis for further development I think. Currently, it fulfils > > >> the > >> basic needs for my menulet and is not in the shape to be put into a > >> separate > >> framework, but this may not be too difficult to achieve. I want to do > it > >> anyway for another project and if you are interested I would 'donate' > >> it to > >> the Etoile project. > > > > We are always interested by new code, so thanks for offering to donate > > it to the project. If you submit it we'll take a loot at it and see > > whether it is interesting for us and meet our needs. > My current impementation lacks a couple of functions I need in my projects > > as well as some decent error handling :-). As soon as I have that done I > will put this into a framework project. Once this is done I think I will > have a decent basis for dbus/hal handling in GNUstep/Etoile(?) and we may > discuss whether to introduce it into Etoile. As I will not have too much > time in October it will take a while, however. > > Cheers, > Andreas > > > -- > Erstellt mit Operas revolutionärem E-Mail-Modul: > http://www.opera.com/mail/ > > _______________________________________________ > Etoile-discuss mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-discuss -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
