Re: [SyncEvolution] gtk ui status update
Patrick Ohly wrote:
> Comments on the api after actually implementing a client: So far
it's
> been quite a bit more work than the old one.
This is not entirely surprising. After all, in the previous API you had
the backend completely for yourself and everything was designed for use
in the sync-UI. Now you have to potentially share the server with other
users, both frontends and other activities going on in the background.
Yes, not surprising at all. I also intended to say that the api does
feel like it gives me everything I need now and in the future (unlike
the old one).
> Some open questions:
> * Can I find out if a source is supported on local machine without a
> Session? This would be useful so I could show the UI even if another
> Session is running.
Not at the moment, but I think it could be added.
Maybe it's not that important... I'll just not show the sources until I
have a session.
The other side of the coin is that I will have to start a session when
sync-ui starts (and not just when I need to do a Sync). I'm not sure if
this is good or bad -- I an always Detach() if I want to.
> * Server.GetSessions() is not implemented: was this on
purpose?
No. Please file an issue, blocking 7210 and assign it to Yongsheng.
Yongsheng, I hope you have time for this right now, otherwise I'll do it
later this week.
Bug 8061.
> * If it gets implemented, can I trust that the first one is
currently
> active?
We haven't defined an order in the API spec. We could add this:
"sessions are returned in the order in which they will run, running ones
first".
Yes, this is fine for me.
> * syncing seems to make the session inactive (after the sync
finishes),
> is this as designed?
Yes. The intention was that other, queued sessions can run immediately
after the syncing one is done, without having to wait for a client to
react. Is this a problem?
Not really, but it was unexpected. I'm fine either way.
From a GUI point of view it's not nice that other clients (say a
automatic sync) can "steal" my turn controlling syncevolution but I'm
not sure if this is a real world problem... Because on the other hand,
if I forget sync-ui running for two hours, I definitely want automatic
syncs to do their thing while the UI is open.
> * I can't seem to get StatusChanged from Session B in this
case:
> - session A starts syncing
> - session B starts
> - session A stops syncing, detaches
> I expected to get StatusChanged "idle" for B but I don't
I need to check this. The problem is that my test case for this depends
on glib mainloop bindings in a python-gobject release that is so recent
that Debian Stable (on my laptop) doesn't have it.
Thank you.
- Jussi