genesis-devs team mailing list archive

[Frederik Elwert <frederik.elwert@xxxxxx>]

Hi,

Am Mittwoch, den 04.11.2009, 00:15 +0100 schrieb David Castellanos: 
> I'm sorry, I've been somewhat busy these last weeks with another
> project, studies and personal life. The purpose of this email is to
> discuss about what features could be implemented in Genesis Sync (GS),
> and how it could be done.

Great to hear from you. As I said before, no apologies for any lack of
involvement. :-) (I didn’t spend too much time on Genesis lately,
either.)

> Most of the suggestions have been discussed privately with Frederick,
> but it was said it would be good expose them publicly. For now the
> only subscribed to the mailing list are Frederick and myself, but it
> could be more people in the future and the archive may be helpful to
> them.

Agree. Maybe I should announce this list on the SE mailing list, so if
anyone is interested in Genesis, he or she could join this list.

> Briefly, I think the following features could be interesting:
> 
> 1. Account management support.
> 
> Risk is low because there is another program called Molinux Sync[1]
> (MS) which has it already implemented. MS is based on GS, and it would
> be very easy to backport this functionality to MS. Both programs are
> GPL3.

Yep, urgendly needed, planned for a long time, never actually
implemented by me. So it would be great to implement this based on you
experience with MS.

> 2. Support for Gnome keyring passwords.
> 
> Risk is medium because the new SE 0.9.1, released tonight, already add
> support for this feature. We must be able to create, read and modify
> Gnome keyring passwords in order to implement this. There is a python
> module named 'gnomekeyring', packaged in Ubuntu in
> 'python-gnomekeyring'. Some information on the subject [2] [3] [4].

We should definitely look into this, avoiding passwords stored in plain
text files would be a huge plus for security.

I have to confess that at some point I lost track of the discussion. I
know that the first version of sync-ui stored the password in the
keyring, and syncevo-dbus-server (?) read it from there. But I think it
was discussed that syncevo-dbus-server should completely take care of
it, so the client would only pass the password to SE and it would store
it wherever appropriate (see [1]). But I don’t know if they actually
implemented it this way.

> 3. Investigate the new D-Bus based configuration API in SyncEvolution.
> 
> Risk is very high because I think it's currently in development
> upstream in SE, probably badly documented and subject to change in the
> near future. Anyway, it would be nice to think about it,  and pay
> attention in upstream development.

I have a private branch that partially implements the old DBUS API. Now
with SE 0.9.1 being released, I guess the revised API should be more or
less stable, so it should be possible to implement it. I always asked
for documentation, so I hope they took care of the API doc. ;-)

I’ll take a look at this and publish a branch once I have something more
or less usable.

> 4. Support for synchronize more than an account at once.
> 
> Risk is low, already implemented in MS. Do you think it would be useful?

Yes, this had already been requested by users. Up to now, I didn’t need
it for myself, but I think it would be useful to implement it. 

> 5. Refine the UI, make it Gnome HIG compliant.
> 
> Risk is medium. Some work is done in MS, but is a rather subjective
> matter. At least some prototypes could be suggested.

Yes, why not? Would not be my top priority, but suggestions welcome. :-)

> 6. Improve disabled origins handling.
> 
> Risk is medium. I tried a first approximation, but I was wrong. In SE
> 0.9.1, sync-ui program has support for that; we can investigate how
> sync-ui has implemented that feature, and implement it back to SE.

Yes, this would be a good addition, but not strictly necessary.

> What do you think about that? Feel free to comment it please. If you
> think it may be useful, we could create blueprints for them in
> Launchpad, and then associate bzr branches to them. Probably I'll be
> busy too the following weeks, but I could work in them from time to
> time.

I think this is a good list of desirable improvements. I have two
additions, which are a bit Ubuntu specific:

7. Improved notification area icons.
<https://bugs.launchpad.net/genesis-sync/+bug/461425>

This seems pretty straight forward, but I would like not just to change
the icons, but rather make Genesis ship different icons for different
icon themes. Still should not be too much work.

8. Create a new action system.

Ubuntu removed actions from their notification system. While I think
this generally is a good thing, this led to a regression: Genesis used
to add a “show error log” button to the notification in case of error.
This is now no longer possible.

As a solution, I thought about a custom notification system: The status
icon could change in case of an error, and clicking the icon would then
not start a sync, but show the error log. This should be made generic,
so the icon could handle different situations.

A different solution would make use of Ubuntus indicator applet, but I
don’t know if this is the right place for Genesis error messages.


So I’d suggest who ever wants to take on one issue could create a
blueprint. If there are details to be discussed, this should take place
in separate threads on this mailing list. Then the blueprint would be
finalised and a branch created.

Do you think this a viable way? Any comments appreciated.

So I could probably take on the DBus API and, if necessary, the keyring
thing. But first of all, I’d like to finish that icon thing. The action
system should probably discussed in more detail, but it’s not that
urgent.

If you could port the extra features from MS, this would be great. But
just say what you’re interested in starting with, any contributions are
welcome. :-)

Cheers,
Frederik


[1]
http://lists.syncevolution.org/pipermail/syncevolution/2009-September/000350.html