On Fri, 2007-12-21 at 17:31 +0100, Guido Diepen wrote: > Hi, > > > 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) >
Yes, they all operate through a rapi connection which can do either dccm. > 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. > I guessed that was what you were up to, though I hadn't got around to looking at it properly, excellent, good luck ! Mine was only a stopgap measure, personally I'm not actually bothered since I'm a gnomer, but it seemed a shame to cut raki loose entirely. > 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 would suggest at some point then that we decouple rapip and raki. > > > > 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 :) ) I started to fiddle with dbus in raki using qt4 before I realised it was qt3, very silly of me. I have to say even the qt4 C++ documentation was poor, just badly written, so I hope the python stuff is more straightforward. > > > > > 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. > The password part is quite easy, just remember to back up your test device, in case you lock yourself out ! Yes I did do this once...... Mark ------------------------------------------------------------------------- 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
