[Evolution-hackers] Status bar stuff



Hey hackers,

I have restored some of the final missing pieces in the new shell,
namely the offline/online button (not fully functional yet) and the
status bar.

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

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

-- Ettore



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]