genesis-devs team mailing list archive

[David Castellanos <davidcaste@xxxxxxxxx>]

Hi!

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

Very good idea. You could write about our intention to develop a SE
frontend more desktop friendly than sync-ui.

I'll make a brief review of the proposed activities:

1. Account management support.

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

I take care of this. I don't know if I can this weekend or next, but
it won't take much work. What would you prefer, libglade or the new
GtkBuilder? Have you tried MS? There are a DEB package available in
[1], and except few little things the application is completely
translated into English.. If you like the Account Management UI, I can
reuse it inmediatly! :-)


2. Support for Gnome keyring passwords.

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

Indeed.

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

At least in old CLI based backend, password which are stored are
identified because they contain the character '-'. When this is
encountered, the '--migration' command line parameter could be added.
I could work on it after account management support.


3. Investigate the new D-Bus based configuration API in SyncEvolution.

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

We should ask what they think about that, and if the API is still in
development. But I have a question, the new DBUS API means that SE
will be a client-server application, or a daemon? It would be
necessary to completely change the role of Genesis, from a caller role
to a SE watcher/listener one. But I may be wrong, because I couldn't
look for any of this by myself yet.


4. Support for synchronize more than an account at once.

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

We could leave it aside for now. This could change in the future if SE
becomes a daemon, but for now it would be straightforward.


5. Refine the UI, make it Gnome HIG compliant (low priority).


6. Improve disabled origins handling (very low priority).


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.

I strongly agree with you. We could provide our current notification
icons for 'hicolor' theme, because it would fall back on them when the
corresponding icons aren't found in the current icon theme. And for
the new ¿flat, simple? style, we could add them in 'Humanity' icon
set.


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.

I really hate the new notify-osd... it does weird things in some
cases, for example while playing video :-S. I agree with you that the
fallback dialog is horrible.

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

Have you tried UbuntuOne client? I think both notification icons
correspond to the same metaphor.

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

We could discuss this, but I think they are different metaphors, Mark
Shuttleworth wrote something about it [2]. I think the key is that
Genesis' notifications aren't persistent, unlike those of an IM
program like Pidgin for example.

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

What about creating a bug for each one instead? In either form we may
announce it in SE mailing list, in case anyone is interested.

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

Okay, I'll try to port Account Management support, and synchronization
support for more than an account at once. I don't know how long it
would take, because my PhD tutors are crazy and they want me to write
some conference papers (in English!!) , and it will keep me pretty
busy. But on weekends, especially on Sundays, I'll try to work on
Genesis.

Cheers!! :-)


[1] https://forja.molinux.info/frs/?group_id=20
[2] http://www.markshuttleworth.com/archives/253