Hi Stelian, First of all, thanks for the interest in this. Our future plans include a separated sync engine and GUI, so this does fit in. See http://multisync.sourceforge.net/developer/wiki/index.php?Version0.90Features for more details.
Our current roadmap is to release 0.82 at the end of March and then turn CVS HEAD over to developing 0.90, which would include these features. We'd love to get your patches - they wouldn't be applied right away, but they could for a starting point for 0.90. Tom On Wed, 2004-03-10 at 09:41, Stelian Pop wrote: > Hi, > > We (an open-source consulting company) are interested in > running Multisync in a text-only mode and could devote some > ressources to work on this. > > We plan on using it as a synchronisation platform between PDAs > and OpenGroupware (http://www.opengroupware.org/). In this > configuration, multisync would be a library or a text-only > client driven by OpenGroupware directly (and not by a Gnome/GTK > interface like today). > > Moreover, it would be nice if multisync worked on non Linux > platforms (mainly Win$$). Partially removing the Gnome/GTK > dependency (for the core libraries and the plugins) would > certainly ease the porting job. > > Here is the multisync architecture as of today (0.81 / CVS): > - the syncronisation core is a GTK application composed > of a sync core (the sync engine) and the GUI. > > - the plugins are loaded dynamically (.so libs), and > do most of their job graphically, except for the > configuration dialog which is popped out using GTK. > > What I would like to see is something like: > 1. - a library implementing the sync engine > 2. - a GUI/TUI linked with this library for configuration > and launch purposes > 3. - separating the plugin API in two parts: the main > part without any graphical dependencies, a second > part with graphics (used by the multisync GUI) > for configuration purposes(*). > > (*) > I'm not sure if the plugins are supposed to do graphics at all, > maybe we could do this like in SANE, where the GUI/TUI asks > the plugin for the list of the configurable items, and build > the interface for them... > > Are there any people interesting on working on this ? Is > something like this compatible with the future plans for > Multisync (post 1.0 probably) ? > > In case there is some interest for this, I patched multisync > and: > * moved syncengine.[ch] and sync_vtype.[ch] into > a 'syncengine' library, which depends only on glib > (no more gtk) > * the remaining sources in src/ gave gmultisync, the GUI > * implemented a simple TUI > * using a crude #ifdef method, compiled a few plugins > (opie, backup, syncml) without the graphical GTK > dependency. > The result is ugly (binary code is duplicated between the > graphical and the text plugins, etc), but it's a sort of > proof-of-concept thing and it's working. > > I'll post this patch somewhere if someone is interested. > > Comments welcome. > > Stelian. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Multisync-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/multisync-users
