dccms again

[Mark Ellis]

Hi All

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.

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.

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.

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.

Comments and suggestions ? Mostly is this the right way to go, at least
for the time being ?

Mark

[Guido Diepen]

Hi,

Post by Mark Ellis
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/ ).

Post by Mark Ellis
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.

Post by Mark Ellis
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 :) )

Post by Mark Ellis
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

[Mark Ellis]

Post by Guido Diepen
Hi,

Post by Mark Ellis
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.

Post by Guido Diepen
Raki does not work with odccm, but currently I am working on a program
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.

Post by Guido Diepen
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/ ).

Post by Mark Ellis
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.

Post by Guido Diepen

Post by Mark Ellis
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.

Post by Guido Diepen

Post by Mark Ellis
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

[Guido Diepen]

Post by Mark Ellis
Yes, they all operate through a rapi connection which can do either
dccm.

Post by Guido Diepen
Raki does not work with odccm, but currently I am working on a program
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.

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 :)

Post by Mark Ellis

Post by Guido Diepen
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/ ).

Post by Mark Ellis
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.

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.

Post by Mark Ellis

Post by Guido Diepen

Post by Mark Ellis
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.

I have to say that the qt4 documentation is quite nice, the examples for pyqt4
are not that ample, but qt4 c++ examples can be transformed quite easly into
python code (at least the majority of the cases for me so far). Furthermore,
got myself a nice book about python and qt4 :)

Post by Mark Ellis

Post by Guido Diepen

Post by Mark Ellis
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......

Hmm... I will put this as a small todo then for later, first I want to work on
potentially less harmfull stuff :) Before I work on the password thing I want
to work on the possibility of installing cab files through synce-kdm. For
this I have to implement some functions in pyrapi though and I want to add
the possibility of copying the cab files through rapi first to a possible
different location ( useful for large programs, like spoken dictionaries). I
will need the CeGetDiskFreeSpaceEx function to be implemented in rapi. I
already gave it a try to implement it, but I am not sure if it is working,
since the last-error is equal to 1, which is not a good thing I think. More
investigation into this is needed. One of the people on IRC already offered
to help me out by providing me some traces of an installer program under
windows that uses rapi. As soon as I have those logs I will work on
implementing that functionality.

If people have suggestions for features, please let me know :)

Guido Diepen


Guido Diepen

[Jonny Lamb]

Hi.

Post by Guido Diepen

Post by Mark Ellis
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.

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
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.

Post by Guido Diepen

Post by Mark Ellis
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.

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

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?)

Registry editor (option, of course):
GNOME: registry-tool
KDE: --

kcemirror-esque application:
GNOME: -- (Mark, you said you'd created a clone?)
KDE: kcemirror (obviously)

Partnership management:
GNOME: --
KDE: --

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).

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.)

I hope some of this makes sense. I kind-of diverged from the subject of
dccms onto desktop applications.

Thoughts?

[Guido Diepen]

Post by Jonny Lamb
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
GNOME: gnomevfs
KDE: rapip (needs separating from synce-kde perhaps)

Again, I really think we should package this separately, because it will be
benefecial for everybody, since I don't want to encourage people using wm5+
devices to install the whole current synce-kde stuff, just to get rapip
working.

Post by Jonny Lamb
GNOME: --
KDE: synce-kdm

Working on it :)

Post by Jonny Lamb
GNOME: trayicon
KDE: -- (perhaps synce-kdm in the future?)

That is basically already done within synce-kdm. The moment you plugin your
phone, it detects this and acts upon this. Same holds for unplug. I have to
look into some examples of QSystemTrayIcon, but then I could get synce-kdm to
minimize to system tray also.

Post by Jonny Lamb
GNOME: synce-gnome && traycon IIRC
KDE: -- (but perhaps synce-kdm soon?)

I might copy the code of synce-gnome regarding the password stuff, but can't
test at the moment. What exactly happens when you lock yourself out, and how
bad is that? Does it need a hard reset?

Post by Jonny Lamb
GNOME: registry-tool
KDE: --

Since I updated the synce-registry tool I found that accessing the reg is
quite slow if you want to download it as a whole. If you would like to only
list the 'active open keys' it might be possible to do quite fast. Would be
nice idea to implement this as a future version in synce-kdm (imho is part of
device management ;) )

Post by Jonny Lamb
GNOME: -- (Mark, you said you'd created a clone?)
KDE: kcemirror (obviously)

If kcemirror has some easy way of starting, I could start it from within
synce-kdm.

Post by Jonny Lamb
GNOME: --
KDE: --

I could look at the partnership code within the sync-engine, might be possible
to use that as a base to do the partnership stuff from within synce-kdm also.
Should be not too hard I guess.

But for all of the above, where gnome is missing, I would like to try and set
up the code nicely, meaning that i would like to separate the data layer from
the GUI layer. This means that somebody later on could write just a PyGTK GUI
around this easily meaning we only have one codebase to maintain, plus two
gui layers.

It would mean that we would create a synce-DM (SynCE Device Manager) with a
KDE and GNOME frontend to it.

Post by Jonny Lamb
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).
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.)

In that way it would be an option to set it up: thus I use the GUI to start
calling the needed other stuff for syncing.

Post by Jonny Lamb
I hope some of this makes sense. I kind-of diverged from the subject of
dccms onto desktop applications.
Thoughts?

All in the above lines ;)

Guido Diepen

[Mark Ellis]

Post by Guido Diepen

Post by Jonny Lamb
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
GNOME: gnomevfs
KDE: rapip (needs separating from synce-kde perhaps)

Again, I really think we should package this separately, because it will be
benefecial for everybody, since I don't want to encourage people using wm5+
devices to install the whole current synce-kde stuff, just to get rapip
working.

Yes, covered in my other reply.

Post by Guido Diepen

Post by Jonny Lamb
GNOME: --
KDE: synce-kdm

Working on it :)

Cool !

Post by Guido Diepen

Post by Jonny Lamb
GNOME: trayicon
KDE: -- (perhaps synce-kdm in the future?)

That is basically already done within synce-kdm. The moment you plugin your
phone, it detects this and acts upon this. Same holds for unplug. I have to
look into some examples of QSystemTrayIcon, but then I could get synce-kdm to
minimize to system tray also.

Post by Jonny Lamb
GNOME: synce-gnome && traycon IIRC
KDE: -- (but perhaps synce-kdm soon?)

I might copy the code of synce-gnome regarding the password stuff, but can't
test at the moment. What exactly happens when you lock yourself out, and how
bad is that? Does it need a hard reset?

With my WM2003 device, when I was developing the trayicon password code
I managed to get it to send the wrong password 3 times without checking
what the response was, ooops. Took me a while to realise why it wouldn't
do anything at all, then it was hard reset time. I always back up before
testing password code now. I presume it's the same for WM5+

Post by Guido Diepen

Post by Jonny Lamb
GNOME: registry-tool
KDE: --

Since I updated the synce-registry tool I found that accessing the reg is
quite slow if you want to download it as a whole. If you would like to only
list the 'active open keys' it might be possible to do quite fast. Would be
nice idea to implement this as a future version in synce-kdm (imho is part of
device management ;) )

Downloading the whole registry for casual use is indeed impractical, so
I wrote registry-tool to only read the level above (below ?) the key
level you're on.

I would think registry access is such an infrequently used part, at
least from a normal user perspective, that this is best kept in a
separate app, and just called if required.

Post by Guido Diepen

Post by Jonny Lamb
GNOME: -- (Mark, you said you'd created a clone?)
KDE: kcemirror (obviously)

If kcemirror has some easy way of starting, I could start it from within
synce-kdm.

Post by Jonny Lamb
GNOME: --
KDE: --

I could look at the partnership code within the sync-engine, might be possible
to use that as a base to do the partnership stuff from within synce-kdm also.
Should be not too hard I guess.
But for all of the above, where gnome is missing, I would like to try and set
up the code nicely, meaning that i would like to separate the data layer from
the GUI layer. This means that somebody later on could write just a PyGTK GUI
around this easily meaning we only have one codebase to maintain, plus two
gui layers.
It would mean that we would create a synce-DM (SynCE Device Manager) with a
KDE and GNOME frontend to it.

Post by Jonny Lamb
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).
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.)

In that way it would be an option to set it up: thus I use the GUI to start
calling the needed other stuff for syncing.

Post by Jonny Lamb
I hope some of this makes sense. I kind-of diverged from the subject of
dccms onto desktop applications.
Thoughts?

All in the above lines ;)
Guido Diepen

[Mark Ellis]

Post by Jonny Lamb

Post by Guido Diepen
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.

Post by Jonny Lamb
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 ?

Post by Jonny Lamb

Post by Guido Diepen

Post by Mark Ellis
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 :)

Post by Jonny Lamb
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
GNOME: gnomevfs
KDE: rapip (needs separating from synce-kde perhaps)
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.

Post by Jonny Lamb
GNOME: trayicon
KDE: -- (perhaps synce-kdm in the future?)
GNOME: synce-gnome && traycon IIRC
KDE: -- (but perhaps synce-kdm soon?)

Guido I'm guessing you intend kdm to do this ?

Post by Jonny Lamb
GNOME: registry-tool
KDE: --
GNOME: -- (Mark, you said you'd created a clone?)
KDE: kcemirror (obviously)

Half done the gnome clone, not even testable yet.

Post by Jonny Lamb
GNOME: --
KDE: --

See above notes about syncing, I won't comment any more until I
understand sync-engine better.

Post by Jonny Lamb
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.

Post by Jonny Lamb
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.

Post by Jonny Lamb
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

[Guido Diepen]

Post by Mark Ellis

Post by Jonny Lamb

Post by Guido Diepen

Post by Mark Ellis
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 :)

If I just look at the what actually is in the rapip subdir of synce-kde, it
should be really easy, since it doesn't depend on anything else of synce-kde
as far as I can see. The problem is that I don't know how to make the nice
autotools stuff...

Post by Mark Ellis

Post by Jonny Lamb
GNOME: synce-gnome && traycon IIRC
KDE: -- (but perhaps synce-kdm soon?)

Guido I'm guessing you intend kdm to do this ?

Yes, i intend to, but very cautious about it

Post by Mark Ellis
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.

I have seen that, the only problem is that currently I am writing everything
in python, so I will need python wrappers for everything later on i guess....

Post by Mark Ellis
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.

gnome support was neglected? What about KDE support currently? I started out
with implementing RAPI stuff and then found out that KDE supported could be
better ;)

Guido Diepen