Hi all,
I've been pondering this for a while, but there has been an increasing amount of blurriness in desktop UI elements that haven't been (most likely) designed by or even consulted with the gnome-art team (or fedora design team). Some examples include (the top part of each picture is screenshot, the bottom part is analogue done in inkscape to look crisp; ignore the coloring, it's not important in these images): * sound preferences [1] * volume control with compositing [2] * new tooltips [3]
It does not seem that the blurriness is intentional, so I though I'd point it out. The problem is that if you're drawing fills you need to start at integer x,y values for position; when drawing borders, they need to be shifted by exactly half of their width (i.e. 0.5 px for 1px wide borders) to look crisp. We are not working with very high DPI display devices so this is important.
I think fixing these would nicely fit with your "polishes for F12" project.
Martin
References: [1] http://mso.fedorapeople.org/gnome-blurry/sound-preferences.png [2] http://mso.fedorapeople.org/gnome-blurry/sound-volume.png [3] http://mso.fedorapeople.org/gnome-blurry/tooltips.png
On Mon, 2009-10-26 at 13:47 +0100, Martin Sourada wrote:
Hi all,
I've been pondering this for a while, but there has been an increasing amount of blurriness in desktop UI elements that haven't been (most likely) designed by or even consulted with the gnome-art team (or fedora design team). Some examples include (the top part of each picture is screenshot, the bottom part is analogue done in inkscape to look crisp; ignore the coloring, it's not important in these images): * sound preferences [1] * volume control with compositing [2] * new tooltips [3]
It does not seem that the blurriness is intentional, so I though I'd point it out. The problem is that if you're drawing fills you need to start at integer x,y values for position; when drawing borders, they need to be shifted by exactly half of their width (i.e. 0.5 px for 1px wide borders) to look crisp. We are not working with very high DPI display devices so this is important.
I think fixing these would nicely fit with your "polishes for F12" project.
The sound volume one has an upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=567249
Patch would be most welcome
Cheers
References: [1] http://mso.fedorapeople.org/gnome-blurry/sound-preferences.png [2] http://mso.fedorapeople.org/gnome-blurry/sound-volume.png [3] http://mso.fedorapeople.org/gnome-blurry/tooltips.png -- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
On Mon, 2009-10-26 at 13:34 +0000, Bastien Nocera wrote:
The sound volume one has an upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=567249
Nice to see people from gnome-art team noticed it as well.
Patch would be most welcome
If I find the code that's responsible for this, I'll look into how to patch it. But no promises.
Martin
On Mon, 2009-10-26 at 14:50 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 13:34 +0000, Bastien Nocera wrote:
The sound volume one has an upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=567249
Nice to see people from gnome-art team noticed it as well.
Patch would be most welcome
If I find the code that's responsible for this, I'll look into how to patch it. But no promises.
Martin
Hrm, this one was a little bit harder to find where the problem is... You are actually trying to draw it on non-integer position, which of course results in blurry volume bar in most cases. I've workarounded that by hard retyping the values to (int), but use whatever you prefer in your code to get the integer values out of the double ones. Quickly tested patch attached.
I don't have more time to look at the tooltips ATM, maybe when I return.
Martin
On Mon, 2009-10-26 at 16:00 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 14:50 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 13:34 +0000, Bastien Nocera wrote:
The sound volume one has an upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=567249
Nice to see people from gnome-art team noticed it as well.
Patch would be most welcome
If I find the code that's responsible for this, I'll look into how to patch it. But no promises.
Martin
Hrm, this one was a little bit harder to find where the problem is... You are actually trying to draw it on non-integer position, which of course results in blurry volume bar in most cases. I've workarounded that by hard retyping the values to (int), but use whatever you prefer in your code to get the integer values out of the double ones. Quickly tested patch attached.
I've attached a patch (and then an updated patch) to the upstream bug.
Mind testing it? Seems to look as expected for me.
Cheers
I don't have more time to look at the tooltips ATM, maybe when I return.
Martin
Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
On Mon, 2009-10-26 at 15:23 +0000, Bastien Nocera wrote:
On Mon, 2009-10-26 at 16:00 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 14:50 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 13:34 +0000, Bastien Nocera wrote:
The sound volume one has an upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=567249
Nice to see people from gnome-art team noticed it as well.
Patch would be most welcome
If I find the code that's responsible for this, I'll look into how to patch it. But no promises.
Martin
Hrm, this one was a little bit harder to find where the problem is... You are actually trying to draw it on non-integer position, which of course results in blurry volume bar in most cases. I've workarounded that by hard retyping the values to (int), but use whatever you prefer in your code to get the integer values out of the double ones. Quickly tested patch attached.
I've attached a patch (and then an updated patch) to the upstream bug.
Mind testing it? Seems to look as expected for me.
When trying to build the fix into F12, I noticed we have a few of our own changes.
Could you please make sure that: http://koji.fedoraproject.org/koji/buildinfo?buildID=138682 also looks as expected for you?
Cheers
On Tue, 2009-10-27 at 22:42 +0000, Bastien Nocera wrote:
When trying to build the fix into F12, I noticed we have a few of our own changes.
Could you please make sure that: http://koji.fedoraproject.org/koji/buildinfo?buildID=138682 also looks as expected for you?
It looks crisp, but the fill is one pixel smaller then it should be (see the attachment).
Looks like this shouldn't be there: - x1 = round ((width - 1) * percentage); + x1 = round ((width - 2) * percentage);
and this: - cairo_rectangle (cr, x0 + 0.5, y0 + 0.5, x1, height - 1); + rounded_rectangle (cr, 1.0, x0 + 0.5, y0 + 0.5, height / 8, x1, height - 2);
should look like - cairo_rectangle (cr, x0 + 0.5, y0 + 0.5, x1, height - 1); + rounded_rectangle (cr, 1.0, x0 + 0.5, y0 + 0.5, height / 6 - 0.5, x1, height - 1);
in "0003-Improve-the-media-keys-overlay-design.patch". The "height / 6 - 0.5" gives better correlation with the through rectangle's radius than "height / 8" (but isn't a big deal) and the substitutions of 2's instead of 1's with the change from cairo_rectangle to rounded_rectangle and in the x1 setting are obviously incorrect.
Martin
On Wed, 2009-10-28 at 00:19 +0100, Martin Sourada wrote:
On Tue, 2009-10-27 at 22:42 +0000, Bastien Nocera wrote:
When trying to build the fix into F12, I noticed we have a few of our own changes.
Could you please make sure that: http://koji.fedoraproject.org/koji/buildinfo?buildID=138682 also looks as expected for you?
It looks crisp, but the fill is one pixel smaller then it should be (see the attachment).
This should be all fixed in: http://koji.fedoraproject.org/koji/buildinfo?buildID=138704
Let me know and I'll get it tagged for F12, and update gnome-power-manager as well.
Cheers
On Wed, 2009-10-28 at 00:55 +0000, Bastien Nocera wrote:
This should be all fixed in: http://koji.fedoraproject.org/koji/buildinfo?buildID=138704
This one works as expected :)
Let me know and I'll get it tagged for F12, and update gnome-power-manager as well.
Cheers
Martin
On Wed, 2009-10-28 at 10:05 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 00:55 +0000, Bastien Nocera wrote:
This should be all fixed in: http://koji.fedoraproject.org/koji/buildinfo?buildID=138704
This one works as expected :)
Finally, I also updated gnome-power-manager: http://koji.fedoraproject.org/koji/taskinfo?taskID=1774321
Would appreciate if people could test as well before tagging.
Cheers
On Wed, 2009-10-28 at 11:04 +0000, Bastien Nocera wrote:
On Wed, 2009-10-28 at 10:05 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 00:55 +0000, Bastien Nocera wrote:
This should be all fixed in: http://koji.fedoraproject.org/koji/buildinfo?buildID=138704
This one works as expected :)
Finally, I also updated gnome-power-manager: http://koji.fedoraproject.org/koji/taskinfo?taskID=1774321
hrm, that one has now wrong positioning (at the top-left corner of the screen; testing brightness) and the progress bar is blurry. However, looking at the code, I fail to see, why :(
Martin
On Wed, 2009-10-28 at 12:15 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 11:04 +0000, Bastien Nocera wrote:
On Wed, 2009-10-28 at 10:05 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 00:55 +0000, Bastien Nocera wrote:
This should be all fixed in: http://koji.fedoraproject.org/koji/buildinfo?buildID=138704
This one works as expected :)
Finally, I also updated gnome-power-manager: http://koji.fedoraproject.org/koji/taskinfo?taskID=1774321
hrm, that one has now wrong positioning (at the top-left corner of the screen; testing brightness) and the progress bar is blurry. However, looking at the code, I fail to see, why :(
Actually, I've just found the source of blurriness: in draw_action_brightness(): + /* draw volume meter */ + draw_volume_boxes (window, + cr, + (double)window->priv->volume_level / 100.0, + bright_box_x0 + 0.5, + bright_box_y0 + 0.5, + bright_box_width, + bright_box_height); should be + /* draw volume meter */ + draw_volume_boxes (window, + cr, + (double)window->priv->volume_level / 100.0, + bright_box_x0, + bright_box_y0, + bright_box_width, + bright_box_height); as you are adding the 0.5 inside the draw_volume_boxes() already.
Not sure about the positioning issue though.
Martin
On Wed, 2009-10-28 at 12:23 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 12:15 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 11:04 +0000, Bastien Nocera wrote:
On Wed, 2009-10-28 at 10:05 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 00:55 +0000, Bastien Nocera wrote:
This should be all fixed in: http://koji.fedoraproject.org/koji/buildinfo?buildID=138704
This one works as expected :)
Finally, I also updated gnome-power-manager: http://koji.fedoraproject.org/koji/taskinfo?taskID=1774321
hrm, that one has now wrong positioning (at the top-left corner of the screen; testing brightness) and the progress bar is blurry. However, looking at the code, I fail to see, why :(
Actually, I've just found the source of blurriness: in draw_action_brightness():
/* draw volume meter */draw_volume_boxes (window,cr,(double)window->priv->volume_level / 100.0,bright_box_x0 + 0.5,bright_box_y0 + 0.5,bright_box_width,bright_box_height);should be
/* draw volume meter */draw_volume_boxes (window,cr,(double)window->priv->volume_level / 100.0,bright_box_x0,bright_box_y0,bright_box_width,bright_box_height);as you are adding the 0.5 inside the draw_volume_boxes() already.
Good catch. That was some left-over from previous patches.
Not sure about the positioning issue though.
Should be fixed in: http://koji.fedoraproject.org/koji/buildinfo?buildID=138737
On Wed, 2009-10-28 at 14:16 +0000, Bastien Nocera wrote:
On Wed, 2009-10-28 at 12:23 +0100, Martin Sourada wrote:
Actually, I've just found the source of blurriness: in draw_action_brightness():
/* draw volume meter */draw_volume_boxes (window,cr,(double)window->priv->volume_level / 100.0,bright_box_x0 + 0.5,bright_box_y0 + 0.5,bright_box_width,bright_box_height);should be
/* draw volume meter */draw_volume_boxes (window,cr,(double)window->priv->volume_level / 100.0,bright_box_x0,bright_box_y0,bright_box_width,bright_box_height);as you are adding the 0.5 inside the draw_volume_boxes() already.
Good catch. That was some left-over from previous patches.
Not sure about the positioning issue though.
Should be fixed in: http://koji.fedoraproject.org/koji/buildinfo?buildID=138737
Thanks, it's now crisp and positioned correctly :)
Martin
On Mon, 2009-10-26 at 09:48 -0400, Matthias Clasen wrote:
On Mon, 2009-10-26 at 13:47 +0100, Martin Sourada wrote:
I think fixing these would nicely fit with your "polishes for F12" project.
Yes, thanks for pointing these out.
Please send us your patches - or is that not what you meant with 'consulting' ?
By consulting I meant, when you are coding graphical UI elements, it would be nice if you had someone from gnome-art or fedora-design review it visually. But yes, if I'll have enough free time and energy to create the patches before anyone else does, I'll look into it.
Martin
On Mon, 2009-10-26 at 09:48 -0400, Matthias Clasen wrote:
On Mon, 2009-10-26 at 13:47 +0100, Martin Sourada wrote:
I think fixing these would nicely fit with your "polishes for F12" project.
Yes, thanks for pointing these out.
Matthias,
going through the tooltips patch, I found these problems: in fill_background(): + draw_round_rect (cr, + 1.0, 1, 1, radius, + widget->allocation.width - 2, + widget->allocation.height - 2); should be + draw_round_rect (cr, + 1.0, 0.5, 0.5, radius, + widget->allocation.width - 1, + widget->allocation.height - 1); and in update_shape() + draw_round_rect (cr, 1.0, 0, 0, 4, width, height); you are ignoring radius setting.
I'm going to try build and test these fixes (if I find enough HDD space for the gtk2 build) to see if it's enough.
Martin
On Wed, 2009-10-28 at 12:35 +0100, Martin Sourada wrote:
and in update_shape()
draw_round_rect (cr, 1.0, 0, 0, 4, width, height);you are ignoring radius setting.
I forgot to mention, that you should use radius + 0.5 to get the shape correctly.
I just thought about the actual implementation, and as an engine developer, long-term I'd prefer more systematical change. I.e. let an engine handle the drawing and ask the engine for the desired tooltip shape as well (if not composited). That way we could implement it in a clean way in engines, with radius as set in engine options (as opposed to counting the radius from x/ythickness) and with our custom styling.
Martin
On Wed, 2009-10-28 at 12:54 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 12:35 +0100, Martin Sourada wrote:
and in update_shape()
draw_round_rect (cr, 1.0, 0, 0, 4, width, height);you are ignoring radius setting.
I forgot to mention, that you should use radius + 0.5 to get the shape correctly.
I just thought about the actual implementation, and as an engine developer, long-term I'd prefer more systematical change. I.e. let an engine handle the drawing and ask the engine for the desired tooltip shape as well (if not composited). That way we could implement it in a clean way in engines, with radius as set in engine options (as opposed to counting the radius from x/ythickness) and with our custom styling.
Can you add those comments in
https://bugzilla.gnome.org/show_bug.cgi?id=599617
That would be great.
Thanks, Matthias
On Wed, 2009-10-28 at 12:35 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 09:48 -0400, Matthias Clasen wrote:
On Mon, 2009-10-26 at 13:47 +0100, Martin Sourada wrote:
I think fixing these would nicely fit with your "polishes for F12" project.
Yes, thanks for pointing these out.
Matthias,
going through the tooltips patch, I found these problems: in fill_background():
- draw_round_rect (cr,
1.0, 1, 1, radius,widget->allocation.width - 2,widget->allocation.height - 2);should be
- draw_round_rect (cr,
1.0, 0.5, 0.5, radius,widget->allocation.width - 1,widget->allocation.height - 1);
So, just built and tested -> this is enough to make it look crisp.
and in update_shape()
draw_round_rect (cr, 1.0, 0, 0, 4, width, height);you are ignoring radius setting.
Hrm, this one is hard to get looking good... The best setting I've came up with is radius + 1 instead of 4.
Martin
On Wed, 2009-10-28 at 13:45 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 12:35 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 09:48 -0400, Matthias Clasen wrote:
On Mon, 2009-10-26 at 13:47 +0100, Martin Sourada wrote:
I think fixing these would nicely fit with your "polishes for F12" project.
Yes, thanks for pointing these out.
Matthias,
going through the tooltips patch, I found these problems: in fill_background():
- draw_round_rect (cr,
1.0, 1, 1, radius,widget->allocation.width - 2,widget->allocation.height - 2);should be
- draw_round_rect (cr,
1.0, 0.5, 0.5, radius,widget->allocation.width - 1,widget->allocation.height - 1);So, just built and tested -> this is enough to make it look crisp.
and in update_shape()
draw_round_rect (cr, 1.0, 0, 0, 4, width, height);you are ignoring radius setting.
Hrm, this one is hard to get looking good... The best setting I've came up with is radius + 1 instead of 4.
Thanks for looking into this, Martin.
I'm just building gtk2 and metacity packages that should fix this. Care to try them out and tell me if they match your quality standards ?
gtk2-2.18.3-13.fc12 metacity-2.28.0-5.fc12
Then I'll have them tagged.
On Wed, 2009-10-28 at 12:42 -0400, Matthias Clasen wrote:
Thanks for looking into this, Martin.
I'm just building gtk2 and metacity packages that should fix this. Care to try them out and tell me if they match your quality standards ?
gtk2-2.18.3-13.fc12 metacity-2.28.0-5.fc12
Then I'll have them tagged.
Well, apart from the fact that you've disabled the opt-in switch for themes again, as long as the crispness of the design is concerned, these are fine with me :-)
Martin
On Wed, 2009-10-28 at 18:01 +0100, Martin Sourada wrote:
On Wed, 2009-10-28 at 12:42 -0400, Matthias Clasen wrote:
Thanks for looking into this, Martin.
I'm just building gtk2 and metacity packages that should fix this. Care to try them out and tell me if they match your quality standards ?
gtk2-2.18.3-13.fc12 metacity-2.28.0-5.fc12
Then I'll have them tagged.
Well, apart from the fact that you've disabled the opt-in switch for themes again, as long as the crispness of the design is concerned, these are fine with me :-)
Yeah, sorry about that. I've fixed that and a few other issues in another round of builds.
On Wed, 2009-10-28 at 18:50 -0400, Matthias Clasen wrote:
On Wed, 2009-10-28 at 18:01 +0100, Martin Sourada wrote:
Well, apart from the fact that you've disabled the opt-in switch for themes again, as long as the crispness of the design is concerned, these are fine with me :-)
Yeah, sorry about that. I've fixed that and a few other issues in another round of builds.
Thanks :)
Martin
On Mon, 2009-10-26 at 13:47 +0100, Martin Sourada wrote:
Hi all,
I've been pondering this for a while, but there has been an increasing amount of blurriness in desktop UI elements that haven't been (most likely) designed by or even consulted with the gnome-art team (or fedora design team). Some examples include (the top part of each picture is screenshot, the bottom part is analogue done in inkscape to look crisp; ignore the coloring, it's not important in these images): * sound preferences [1]
Does the attached patch work for you for gnome-media?
* volume control with compositing [2] * new tooltips [3]It does not seem that the blurriness is intentional, so I though I'd point it out. The problem is that if you're drawing fills you need to start at integer x,y values for position; when drawing borders, they need to be shifted by exactly half of their width (i.e. 0.5 px for 1px wide borders) to look crisp. We are not working with very high DPI display devices so this is important.
I think fixing these would nicely fit with your "polishes for F12" project.
Martin
References: [1] http://mso.fedorapeople.org/gnome-blurry/sound-preferences.png [2] http://mso.fedorapeople.org/gnome-blurry/sound-volume.png [3] http://mso.fedorapeople.org/gnome-blurry/tooltips.png -- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
On Mon, 2009-10-26 at 13:50 +0000, Bastien Nocera wrote:
On Mon, 2009-10-26 at 13:47 +0100, Martin Sourada wrote:
Hi all,
I've been pondering this for a while, but there has been an increasing amount of blurriness in desktop UI elements that haven't been (most likely) designed by or even consulted with the gnome-art team (or fedora design team). Some examples include (the top part of each picture is screenshot, the bottom part is analogue done in inkscape to look crisp; ignore the coloring, it's not important in these images): * sound preferences [1]
Does the attached patch work for you for gnome-media?
If x0, y0, width and height are integer values (although they're passed as doubles I doubt they are actually non-integers), it should, I'm going to try build and test it. You would probably also want to use (but that depends on what you'd what the width/height values to represent).
x1 = x0 + width - 1;
and similar for y1.
Martin
On Mon, 2009-10-26 at 15:02 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 13:50 +0000, Bastien Nocera wrote:
Does the attached patch work for you for gnome-media?
If x0, y0, width and height are integer values (although they're passed as doubles I doubt they are actually non-integers), it should, I'm going to try build and test it. You would probably also want to use (but that depends on what you'd what the width/height values to represent).
x1 = x0 + width - 1;
and similar for y1.
Actually, looking at in in the perspective of the whole code, this is IMHO not the correct place to fix it as curved_rectangle() can be used both for fills and for borders (even though in the file you use it only in a way that fixing this in curved_rectangle() works too).
Attaching my version of the patch (verified that it works for me as intended).
Martin
On Mon, 2009-10-26 at 15:20 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 15:02 +0100, Martin Sourada wrote:
On Mon, 2009-10-26 at 13:50 +0000, Bastien Nocera wrote:
Does the attached patch work for you for gnome-media?
If x0, y0, width and height are integer values (although they're passed as doubles I doubt they are actually non-integers), it should, I'm going to try build and test it. You would probably also want to use (but that depends on what you'd what the width/height values to represent).
x1 = x0 + width - 1;
and similar for y1.
Actually, looking at in in the perspective of the whole code, this is IMHO not the correct place to fix it as curved_rectangle() can be used both for fills and for borders (even though in the file you use it only in a way that fixing this in curved_rectangle() works too).
Attaching my version of the patch (verified that it works for me as intended).
Committed to master, will be in the next stable release of gnome-media.
Cheers
desktop@lists.fedoraproject.org
-
Bastien Nocera -
Martin Sourada -
Matthias Clasen