Restart to complete updates entry should be red

Does dbusmenu have the ability to change the FG colour of GtkWidgets ? If so, then I can fix this bug.

Linked branches should fix this bug, though I cannot confirm it, so I am requesting review but not assigning myself.

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.

Mark

This approach will help make color a visual implementation of special state in the Ayatana Indicators, i like ;)

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.

Bilal.

 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!

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

We really need to express these capabilities has higher-order logic not
low-level painting.

Mark

On Fri, 2010-09-10 at 05:32 +0000, Mark Shuttleworth wrote:

> What's the situation with messaging menu? Is the "alert" state semantic,
> or hardcoded to a green icon too?
>
Its hardcoded, from what I am seeing in the code.

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

 On 10/09/10 14:05, Ted Gould wrote:
> 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.
>

Yes, it might be appropriate to be able to specify or request colors in
dbusmenu based on the symbolic schema, which the implementation then
maps to #rgb.

Mark

I'd love to learn what part of the code gets the state in indicator-session.. i didn't find any comments on that in the code yet, and i wasn't skilled enough to find it by myself..
Perhaps someone can help me just this one time ? :D

what exactly is stalling the progress on this matter?
Can we perhaps help with this, by discussing the symbolic usage of color, and how color palettes can be composed in order to express the semantics of the respective expressions?

On Sat, 2010-09-25 at 12:45 +0000, frederik.nnaji wrote:
> what exactly is stalling the progress on this matter?
> Can we perhaps help with this, by discussing the symbolic usage of color, and how color palettes can be composed in order to express the semantics of the respective expressions?

Frederik,
We are currently working on bugs rather than feature requests like this,
and this won't come into Maverick because we have crossed Feature Freeze
long ago,.

This is not a late-breaking feature request, it was part of the original
design discussion at UDS in Dallas, nearly a year ago.

Mark

Mark , you can actually add symbolic icons to the list of things Ubuntu has contributed to gnome. :-)
This is now actually part of gnome3 , not sure how hard it would be to get this backported, but symbolic icons/text should be available in gnome3.

<offtopic>
For people unfamiliar with symbolic icons history..!

The "symbolic icons" started with an idea from the Canonical design team requesting "monochrome" icons from Humanity, since it was being considered for Karmic default! We did the panel icons for Humanity in one color and tried to make it work.
However, Desktop used Human theme and UNR used Dust theme, the panels were different color
 and One color dint fit all!
We nearly dropped using the monochrome icons from Karmic > Bug #430277 , out of desperation i had a idea and had to sit down for the whole weekend REdoing the icons in two themes! which is a huge PITA.

At the same time mpt was having troubles of his own with Karmic Software Center design and the way it displayed arrows in list view.

These problems lead to the subsequent discussion at UDS-L where upstream also joined and picked up the idea and implemented it!
https://wiki.ubuntu.com/SymbolicIcons
http://www.freedesktop.org/wiki/SymbolicIcons
</offtopic>

 Hi Vish

Aha, that's very useful background, thank you!

Adding Ayatana Design to get it into the specification: https://wiki.ubuntu.com/SessionMenu

Thanks Ted. I've amended the spec, the relevant portion now reads:

   1. “Restart…”, which opens the confirmation alert for restarting the computer. If software updates that require a restart have been partially installed, this item should instead say “Restart to complete update…”, and be in the themed symbolic "warning" (in Ubuntu's case, red) color.

good lookin', guys! You're the best ;)

[Quote]
If software updates that require a restart have been partially installed, this item should instead say “Restart to complete update…”, and be in the themed symbolic "warning" (in Ubuntu's case, red) color.
[/Quote]

Restarting is required but after a 'partial update' may not be a good idea as the user can mistakenly restart the computer in the middle of a upgrade. Pls. refer to bug 548981, which explains the context in more detail.

I am assuming that 'restart required' is after a critical upgrade/patch is required or a system level change is made that warrants a restart. If the understanding is not correct, sorry, then proceed as required, but it if is, please read 548981 before proceeding, and get to know why turning red should be only after the complete change is done and not as soon as it is initiated and may be under process at a given instant.

Sounds reasonable - the restart indication should only be set once the
update is complete. I don't think this bug belongs on the indicator,
though, it should be on whatever sets the reboot-required flag.

Mark

On Tue, Nov 23, 2010 at 12:45, Mark Shuttleworth
<email address hidden>wrote:

>
> I don't think this bug belongs on the indicator, though, it should be on
> whatever sets the reboot-required flag.
>

On a sidenote: it would be nice to see the relationship between where a
problem was discovered and where the causes to its symptom(s) are located
visually in the table above every bug description. A tree visualization
under "Affected projects" would be awesome!

About color-highlighting "Restart to complete updates" when approapriate:
The session menu remains affected, until the cause of this bug is resolved.
Marking the bug as "invalid" for the project "Session Menu" doesn't make
sense to me in that understanding..
This is a general problem i have with (unspoken) policy here on launchpad.

I've spent a bit of time on this bug report, and other related ones. For instance the "Change colour after update completes" has many duplicates, but the actual colour changing itself in the dbus menu, the mechanism is fairly good, and in the future all that would need changing is the specification of the colour.

Yes it's hard coded right now, but can we even use symbolic colours right now? So, for now we should let these patches get applied, and later on we use the symbolic colours.

Please set the status of this bug to "incomplete" when finished with it, as it needs further work to be done regarding the symbolic icons. However the branches provided are acceptable for the present natty development.

Karl,

Thanks for reviewing :)

So the symbolic icon change is currently not targeted at natty?

We can hardcode it now, and move to a symbolic system in Natty+1

Mark

what about the icon approach?
at some point in natty alpha or pre-alpha, someone put a "restart" symbol
before the entry..
is that still an option?

On Thu, Dec 23, 2010 at 15:59, Mark Shuttleworth
<email address hidden>wrote:

>
> We can hardcode it now, and move to a symbolic system in Natty+1
>
> Mark
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/634003
>
> Title:
> Restart to complete updates entry should be red
>
> Status in Ayatana Design:
> Fix Released
> Status in DBus Menu:
> Fix Committed
> Status in The Session Menu:
> Fix Committed
>
> Bug description:
> The text of the menu entry for restarting, when a restart is required,
> should be in red.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ayatana-design/+bug/634003/+subscribe
>

No, we want to minimise the number of icons in the interface, so
colour-only please.

it's not fixed on my installations of natty..
is this fixed for anyone?

frederik.nnaji; Fix Released in 'ayatana-design' means that the change request as been approved and handed over to a developer for implementation. Implementation progress is tracked in the 'unity' launchpad project, so look here to see when it will land in Oneiric.

thanks a lot, John.

I'm very excited about the semantic usage of colors in Ayatana, now that we're all monochrome.
There's already a lot to say about that, but i'll try out this one first.

This *should* be fixed with the releases this week although I have not had to opportunity to test it.
The dbusmenu released this week supports the 'disposition' state which the current session service uses to flag a restart.

looking at it now, i'd love to see a less bloody color.
originally, green was suggested, also nice, yellow or orange would be a bit more likely to fit here, i suppose..
orange would definitely be close enough to what red FF0000 is trying to convey, only that it doesn't have the connotation of "danger" as much as red carries it.

Hello frederik: the semantic colours have a particular meaning:

  bug #740900 ("Coherency/Semantic use: change pure-information messaging-menu highlight colour from green to blue")