[Evolution-hackers] Status bar stuff
- From: Ettore Perazzoli <ettore ximian com>
- To: evolution-hackers ximian com
- Subject: [Evolution-hackers] Status bar stuff
- Date: Wed, 19 Nov 2003 05:08:34 -0500
I have restored some of the final missing pieces in the new shell,
namely the offline/online button (not fully functional yet) and the
Now, for the status bar, I am not sure what to do wrt the notifications
from the components.
In the old way, the shell had an "Activity" interface, which was wrapped
in EvolutionShellClient and allowed the component to tell the shell what
was going on.
We could restore that (I have actually resurrected that piece of code
now), but no-one was really happy with the way it was working before, so
I am wondering if I should just use a different approach this time.
(Without having to rewrite heaps of code, of course.)
In particular, restoring the old way also implies adding the
::setOwner() method (through which the shell tells the components of its
existance), which is kinda nasty and I was hoping we could do without in
Options I have thought of:
* Just let the component own the status bar. Instead of just
exporting the sidebar and the view as controls, we make it also
export a status bar control. The shell would switch to the
proper control when changing components. This sounds like the
simplest solution, but:
* It requires some new code in the components (for
example, the mailer likes to notify of different things
at the same time, and the shell handled showing them all
on the status bar -- now the mailer would have to do it
all on its own).
* When you are in, say, the calendar, you don't see what's
going on in the mailer. (So e.g. if it's downloading
mail you are not going to know about that until you
switch to the mail component.)
* We keep a similar approach (i.e. the shell centralizes
everything), but we use listeners instead. I.e. an
Evolution::Component can emit events for when the activity
changes, and the shell just hooks up a listener for that.
* This requires some more hacking in the components to
make it use that.
* The listener behavior might get a bit complicated. (You
have to give an ID to a task, and then have separate
events for "task 'foo' has started" and "task 'foo' has
* Listeners are kind of bad since they do not appear in
the IDL, since you have to use properties and there is
no way to document those in the IDL.
* We keep things as they were before and think about it later.
Some minimal hacking is required in the components for that, but
it should be pretty trivial; I can handle it.
What are your thoughts? (I'd especially like to know what Michael
thinks, since he pointed out before that the old interface sucked. :-))
] [Thread Prev