Comment 8 for bug 634003

On Fri, 2010-09-10 at 06:32 +0100, Mark Shuttleworth wrote:
> On 10/09/10 05:50, Bilal Akhtar wrote:
> > On Thu, 2010-09-09 at 19:51 +0000, Mark Shuttleworth wrote:
> >> We definitely don't want arbitrary colour requests in dbusmenu! For the
> >> moment, I'd rather special-case this in indicator-session. I assume
> >> there's some flag being set which tells the indicator to use the red
> >> icon, it could use the same thing to make that menu entry red.
> > >From what I am seeing in the indicator-session code, there are two
> > different icons, one based on the theme and the other hard-coded red,
> > and there is no such flag that changes the colour, so I am taking this
> > approach.
>
> That's really ugly, the "restart required" piece should be semantic or
> logically expressed, so it can be tested by other pieces, rather than
> depending on a hardcoded icon. Ted!

Aurelien and I were discussing this some on IRC yesterday after the
merge was proposed. We're thinking perhaps we could reuse the names
that the GTK symbolic icons are currently using. If we did the same in
the dbusmenu implementation, then they'd all match.

What happens in indicator-session today is that it sets the alert state
that then uses and icon name, and the icon is defined by the theme. It
doesn't request a specific color.

> What's the situation with messaging menu? Is the "alert" state semantic,
> or hardcoded to a green icon too?

Again the messaging menu does the same, it gets the alert state, then
switches the icon name that it is looking for. The visual appearance of
the icon is dependent on the icon theme being used.

  --Ted