Restart to complete updates entry should be red

Bug #634003 reported by Mark Shuttleworth on 2010-09-09
46
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Ayatana Design
High
John Lea
DBus Menu
Fix Released
Medium
Ted Gould
One Hundred Papercuts
Medium
Bilal Akhtar
Session Menu
Fix Released
High
Conor Curran

Bug Description

The text of the menu entry for restarting, when a restart is required, should be in red.

Changed in indicator-session:
status: New → Confirmed
importance: Undecided → High
Bilal Akhtar (bilalakhtar) wrote :

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

Changed in dbusmenu:
status: New → Confirmed
Bilal Akhtar (bilalakhtar) wrote :

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

frizzle21 (frederik-nnaji) wrote :

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

Bilal Akhtar (bilalakhtar) 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.

Bilal.

Mark Shuttleworth (sabdfl) 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!

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

Bilal Akhtar (bilalakhtar) wrote :

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.

Ted Gould (ted) wrote :

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

Mark Shuttleworth (sabdfl) wrote :

 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

frizzle21 (frederik-nnaji) wrote :

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

frizzle21 (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?

Bilal Akhtar (bilalakhtar) wrote :

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

Mark Shuttleworth (sabdfl) wrote :

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

Vish (vish) wrote :

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>

Mark Shuttleworth (sabdfl) wrote :

 Hi Vish

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

Ted Gould (ted) wrote :

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

Changed in ayatana-design:
status: New → Confirmed
Mark Shuttleworth (sabdfl) wrote :

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.

Changed in ayatana-design:
status: Confirmed → Fix Released
importance: Undecided → High
Ted Gould (ted) on 2010-09-30
Changed in dbusmenu:
importance: Undecided → Medium
Ted Gould (ted) on 2010-11-02
Changed in dbusmenu:
assignee: nobody → Ted Gould (ted)
Changed in indicator-session:
assignee: nobody → Ted Gould (ted)
frizzle21 (frederik-nnaji) wrote :

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

Gurmeet (gurmeet1109) wrote :

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

Mark Shuttleworth (sabdfl) wrote :

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

frizzle21 (frederik-nnaji) wrote :

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.

Karl Lattimer (karl-qdh) wrote :

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.

Karl Lattimer (karl-qdh) wrote :

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.

Changed in dbusmenu:
status: Confirmed → Fix Committed
Changed in indicator-session:
status: Confirmed → Fix Committed
Bilal Akhtar (bilalakhtar) wrote :

Karl,

Thanks for reviewing :)

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

Mark Shuttleworth (sabdfl) wrote :

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

Mark

Changed in indicator-session:
assignee: Ted Gould (ted) → Bilal Akhtar (bilalakhtar)
frizzle21 (frederik-nnaji) wrote :

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
>

Changed in hundredpapercuts:
assignee: nobody → Bilal Akhtar (bilalakhtar)
importance: Undecided → Medium
milestone: none → nt3-ayatana
status: New → Fix Committed
Mark Shuttleworth (sabdfl) wrote :

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

Ted Gould (ted) on 2011-03-10
Changed in dbusmenu:
milestone: none → 0.3.101
status: Fix Committed → Fix Released
status: Fix Released → Confirmed
milestone: 0.3.101 → none
frizzle21 (frederik-nnaji) wrote :

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

John Lea (johnlea) wrote :

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.

frizzle21 (frederik-nnaji) wrote :

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.

John Lea (johnlea) on 2011-06-21
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
tags: added: udo
Conor Curran (cjcurran) wrote :

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.

Changed in dbusmenu:
status: Confirmed → Fix Released
Changed in indicator-session:
status: Fix Committed → Fix Released
assignee: Bilal Akhtar (bilalakhtar) → Conor Curran (cjcurran)
milestone: none → 0.3.3
Changed in hundredpapercuts:
status: Fix Committed → Fix Released
frizzle21 (frederik-nnaji) wrote :

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.

Paul Sladen (sladen) wrote :

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")

John Lea (johnlea) on 2011-10-18
tags: added: udp
Changed in ayatana-design:
status: Fix Released → Fix Committed
John Lea (johnlea) on 2011-10-19
Changed in ayatana-design:
status: Fix Committed → Fix Released
tags: added: reviewedbydesigno
removed: udo udp
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints