Hi, > Let me explain where I think I'm coming from with this first. Sorry if I > ramble. > > Ignore hal-dccm for now, because hal uses dbus it'll be close enough to > odccm to make migration efforts easy. And it's next on my list.... > > We still have multiple dccms obviously. I'm not going to comment on the > functionality differences between v and o because, as far as I can tell, > they do exactly the same thing. They do it in different ways, but it > amounts to the same. > > The only significant difference is client communication, clients being > pls, raki, trayicon etc. Of these the only ones that are affected by the > differences are raki, trayicon, anything that actually gets notified of > devices connecting etc, everything else is oblivious to this because > they go through rapi. I'm sure most of you know this.
The clients within rapi tools all work with odccm (and probably also with vdccm) Raki does not work with odccm, but currently I am working on a program that will do most of the functions that raki did, except for one thing: the syncing, since that was done in rra. It is already in trunk, under synce-kdm (SynCE KDE Device Manager) and is written in Python with the PyQT bindings. The current program is wm5+ only, since I make use of provisioning for example to uninstall programs, while in pre wm5 devices you need to make use of the program unload.exe. The version of the device could be determined run time and appropriate actions could be taken for that part. A very initial version is already available and the screenshots can be found on my homepage ( http://www.guidodiepen.nl/ ). > > odccm uses dbus, vdccm uses a control socket in ~/.synce called csock. > Personally I think dbus is the way to go (and later hal). The crunch is > then that raki in synce-kde doesn't work. The only thing that my synce-kdm does not provide, in contrast to raki is the syncing. IIRC jagow was busy with trying to get support for legacy device syncing in the sync-engine also (correct me if am wrong). That way the syncing part could be completely decoupled from raki and we can work on a version based on dbus and qt4 (i.e. work further on SynCE-KDM :) ) One part of synce-kde does work btw, which is the rapip kio slave: it is very useful for copying files back-and-forth. > > I did try and jam dbus into raki, but I don't know much C++, I'm not a > kde/qt developer, synce-kde uses the previous release of qt (I think) > and, while dbus support for that version exists, it appears to be > completely undocumented. Sigh. I am working with PyQT4, which is quite clear I have to say (considering the fact that I started this week with python and GUI programming :) ) > > Plan 2, a fake vdccm that translates from odccm to raki (or anything > else dependent on vdccm style) and vice-versa. > > I've checked it into trunk as o-vdccm, it'll build a single binary > called vdccm. Seems to work ok, even passwords work. I have not implemented the password thingy, though I can copy the relevant part out of the synce-gnome/test.py program for that. So it should not be very difficult to implement that in my current program. Guido Diepen -- Aviation is proof that given the will, we have the capacity to achieve the impossible. --Eddie Rickenbacker ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
