On Fri, 2007-12-21 at 23:12 +0000, Jonny Lamb wrote: > On Fri, 2007-12-21 at 18:21 +0100, Guido Diepen wrote: > > I am really trying to get this working, since I use KDE. Fortunately I do a > > lot of things console based, but still it is nice to have some things done > > in > > the GUI also :) And since everybody else was using gnome, I decided to work > > on a successor of raki :) > > I think o-vdccm is possibly moving in the wrong direction. I have a
I agree completely, o-vdccm is an ugly hack that shouldn't have ever existed, I hope it can be consigned to history very soon. > feeling that syncing should be done by something desktop-independent. > So, the current system of using opensync works fine with this idea > (albeit not being the most user-friendly). The other parts of SynCE that > would be great on the desktop are quite small -- partnership handling > perhaps, application removal, etc. This latter bit is basically what > Guido has written as synce-kdm. I like it. > I haven't looked at this too much lately, and I really need to find out how opensync / sync-engine works, but if I've got the idea right then the GUI side only has to make calls to sync-engine ? None of the work has to be done in the gui, is this right ? > > > I would suggest at some point then that we decouple rapip and raki. > > > > This is definitely what I would like to suggest. Because rapip really works > > regardless of RAKI and imho it is a very very useful program. Since more > > and > > more people will get wm5+ devices, I think it would be nice for them to > > have > > the abilitiy to install this separately. > > Agreed. > Cool, add to list, I'll try and work out synce-kde build structure to do this, that admin directory baffles me :) > There are many different parts of SynCE, as we all know. All of these > parts seem catered for on the command line (select_partnership.py, pls, > pcp, msynctool --sync..) Availability on your desktop is a different > story though. For example: > > File browsing: > GNOME: gnomevfs > KDE: rapip (needs separating from synce-kde perhaps) > > Application management: > GNOME: -- > KDE: synce-kdm > Also on my list to fix software-manager for later devices. Guido, if you need some ideas on cab file extraction there is code for it in software-manager using liborange. > Connection state (bit of a loose example here!): > GNOME: trayicon > KDE: -- (perhaps synce-kdm in the future?) > > Password entry if required: > GNOME: synce-gnome && traycon IIRC > KDE: -- (but perhaps synce-kdm soon?) > Guido I'm guessing you intend kdm to do this ? > Registry editor (option, of course): > GNOME: registry-tool > KDE: -- > > kcemirror-esque application: > GNOME: -- (Mark, you said you'd created a clone?) > KDE: kcemirror (obviously) > Half done the gnome clone, not even testable yet. > Partnership management: > GNOME: -- > KDE: -- > See above notes about syncing, I won't comment any more until I understand sync-engine better. > Anyway, those are the basic tools for desktops (excluding syncing). This > list points out two things: some desktops have missing applications; and > there are an awful number of different applications for the same > desktop. > For example, with GNOME, it would be great if trayicon lived in your > tray (obviously) and it: managed partnerships, notified the user upon > device connection/disconnection, displayed a password entry if needed, > managed application installation/removal, and contained up a > Gtk-kcemirror-esque app. (Perhaps even contain the registry editor?) > SynCE is already in so many parts that having yet more desktop > applications would be bad.. > > I'd love for people to install everything needed for great usage of > SynCE with: libsynce, librapi2, librra, odccm, sync-engine, synce-gnome > (replace gnome with kde where appropriate). > My long term plan for trayicon and the other gnome apps is to properly implement a plugin system for trayicon, the basics of which I've done for the gnomevfs device-in-computer-folder effect. This way you could have as much or as little installed as you wanted. I also want each app to still be usable if you don't want to use trayicon at all. > The desktop syncing question is a whole different thing. I personally > would stick with a third-party syncing app like we're doing at the > moment with opensync. Perhaps my ideal trayicon application (detailed > above) could skip through setting up a SynCE group for OpenSync and call > "sync"..? OpenSync has actually got a D-BUS interface. > (Another option could be to use Conduit. This, however, is whole > different I will not discuss here. I would hate a raki-esque tool for > only syncing SynCE to be created. A waste of time in my opinion.) > Yes, i agree. > I hope some of this makes sense. I kind-of diverged from the subject of > dccms onto desktop applications. > Happens to me all the time :) I think it's odd that I started on synce just because I thought gnome support was neglected, and now spend all my time on dccm. 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
