Re: Bonobo bug: can't set status to empty string

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael helixcode com> writes:

> Hi,
> 
> On 12 Oct 2000, Maciej Stachowiak wrote:
> > Miguel de Icaza <miguel helixcode com> writes:
> > > I am not sure we even want to support the broken push/pop concept for
> > > status bars, btw.
> >
> > I agree. Push/pop adds complexity and not a lot of benefit.
>   
>         Me too. Which is why we don't support push pop as such. What we do
> support is a per component push / pop type effect so that if we have this
> sequence:
>   
> Component       Action                  Status
> A               set to Foo              Foo
> B               set to Baa              Baa
> B               set to "" or NULL       Foo

The other alternative is if this step made the status empty. Does it
really make more sense to set it back to "Foo"? Is there reason to
believe that component A's status message will still be relevant or
timely after component B's goes away, even if component B's message
has been up for a long time?

I asked Arlo Rose, Eazel's head UI designer, about this (I did my best
to present both models in a clear and unbiased way) and he thought it
would hardly ever be the right thing to go back to the old message,
and fairly often would result in going back to a message the was just
plain wrong, or out of context, from a usability standpoint.

He also showed me some cases in the Nautilus UI where the stack model
results in an out of context or no longer accurate message showing up
after a message goes away.

Ordinarily I'd suggest user testing to determine the right way to go
on an issue like this. However, this case seems pretty clear cut.

> A               remove                  ""
>   
>         This seems to me to be the most logical and consistant way of
> sharing the status bar between multiple components. The way it is
> implemented uses one statusbar id per component ( and 1 for tooltips
> ). There is no 'push / pop' action visible in the API.

Yes, the fact that the stack is completely hidden makes it more
complex. It's even harder to get the effect you want, if you never
want to revert to old messages. Tooltips are the one case where it
might make sense to go back to the older message, since they are by
nature always very transient. How about if we have just one statusbar
string for tooltips, and one for everything else? 

Perhaps there could be a special way to specify a transient statusbar
message for something other than tooltips/menu tips too, in case
that's appropriate in other cases.

 - Maciej