Handle not rendered properly if border-width = 0

Bug #920832 reported by Peter Hurley on 2012-01-24
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Unico
Undecided
Unassigned
gtk3-engines-unico (Ubuntu)
Undecided
Unassigned
ubuntu-themes (Ubuntu)
Undecided
Unassigned

Bug Description

When rendering handles (unico-draw.c: unico-draw-handle), if the current style context has border-width = 0, the handle is not rendered properly. This happens because the line-width is style-matched to "border-width" in unico_get_line_width(), which in turn, means that some of the lines are not stroked and the geometry calculations are off.

When rendering handles, often the border-width will be set to 0 so that the entire background will be wiped to the correct pattern (without leaving a border artifact - this happens on oneiric with gnome-panel and the Radiance theme). The same problem exists when rendering separators as well.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gtk3-engines-unico 1.0.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-15.25-generic 3.0.13
Uname: Linux 3.0.0-15-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Tue Jan 24 00:03:26 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gtk3-engines-unico
UpgradeStatus: No upgrade log present (probably fresh install)

Peter Hurley (phurley) wrote :
Peter Hurley (phurley) wrote :

I added a simple patch for selecting the max of either the existing line-width or 1.

Another approach would be register a new style property ('-unico-line-width'?) and use that value instead of 'border-width'.

The attachment "02_fix_handle_rendering_for_border_width_0" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gtk3-engines-unico (Ubuntu):
status: New → Confirmed
Vadim Rutkovsky (roignac) wrote :

This also affects gnome-sushi - see discussion at https://bugzilla.gnome.org/show_bug.cgi?id=670500

Andrea Cimitan (cimi) wrote :

It's a bug in light-themes.

Changed in gtk3-engines-unico (Ubuntu):
status: Confirmed → Invalid
Changed in unico:
status: New → Invalid
no longer affects: gnome-sushi (Ubuntu)
Peter Hurley (phurley) wrote :

@Andrea,

Would you please include a link to the relevant Launchpad light-themes bug and include an explanation of *why* you think this is a light-themes bug?

As I explained in the OP, if the border-width is 0, the handle is not drawn correctly. Are you saying that, by-design, a handle cannot be rendered correctly within a style context where the border-width = 0?

Andrea Cimitan (cimi) wrote :

It's a light-themes bug because you need to add a special case for sushi and add the lines to not draw outer stroke and inner stroke.
There are cases where border-width is 0 but you still want a shadow or an inner stroke, example is the combobox with an entry. So it's done in this way in unico but just needs tweaks on the theme side.

Peter Hurley (phurley) wrote :

I think if you re-read the OP bug description, you'll realize this bug (and report) has nothing to do with the bug in sushi.

The problem described here is a bug in the unico engine when rendering handles and separators.

Peter Hurley (phurley) on 2012-02-29
Changed in unico:
status: Invalid → New
Changed in gtk3-engines-unico (Ubuntu):
status: Invalid → New
Andrea Cimitan (cimi) wrote :

It's not a bug in unico, but in light-themes. Please don't change the status

Changed in gtk3-engines-unico (Ubuntu):
status: New → Invalid
Changed in unico:
status: New → Invalid
Changed in light-themes:
status: New → Confirmed
Andrea Cimitan (cimi) wrote :

Anyway, I will have a look in unico to see if I can add an user case for similar issues.

Peter Hurley (phurley) wrote :

I have a attached a screenshot of *bug #920832* which shows *the handle* being rendered incorrectly in the gnome-panel.

Peter Hurley (phurley) wrote :

I have attached a screenshot of the correctly rendered *handle* after the unico engine patch I already supplied in comment #2.

As you can see, this bug has *NOTHING* to do with *bug 937141*.

Please un-duplicate bug 937141, and reset the correct status for this bug to 'New' for the unico engine and remove the light-themes status.

Dmitry Shachnev (mitya57) wrote :

I have to agree with Peter, it's actually a Unico bug and the patch fixes it. Also, this needs to be applied before you release light-themes with my branch merged :)

Changed in unico:
status: Invalid → New
Changed in gtk3-engines-unico (Ubuntu):
status: Invalid → New
Changed in light-themes:
status: Confirmed → Invalid
Changed in unico:
status: New → Confirmed
Andrea Cimitan (cimi) wrote :

Well, the patch is wrong cause border-width can be bigger than 1. Also, I still think this is not a bug in unico cause you can simply can add a special style class if needed.
In any case, test against unico trunk.
I won't fix this in unico at the moment, as I don't consider it a bug

Peter Hurley (phurley) wrote :

Ok, I agree -- the patch is wrong. The real bug here is that unico should not be using the border-width style to style interior render elements. In the comment that included the patch, I noted that a more appropriate fix might be to register a new style property instead.

This is *not* fixable from outside unico.

Peter Hurley (phurley) wrote :

@Andrea,

I don't understand what you meant by "you can simply can add a special style class if needed."

I have attached a standalone testcase which demonstrates the bug. The testcase is a toplevel window which contains a single widget -- a subclassed EventBox that renders a handle centered within the window. Please note that the only drawing in this testcase -- including the background -- is done by GtkRenderHandle *which is rendered by the unico engine*.

The testcase styles the widget with a css fragment defined in main() as faux_theme.

Feel free to "add a special style class" to the faux_theme definition so that the testcase output matches the reference image which I will also attach.

Peter Hurley (phurley) wrote :
Andrea Cimitan (cimi) wrote :

if you set a border-width of 0, why you should have a handle? :\

Peter Hurley (phurley) wrote :

That question is totally irrelevant. The purpose of a themeing engine is customize the look of standard elements, not to oversee the UI design of applications.

This is becoming absurd and farcical -- the title of this bug is "Handle not rendered properly if border-width = 0" and your 5th comment on this bug is "if you set a border-width of 0, why you should have a handle?" after twice insisting this is a light-themes bug and telling me not to change the bug status ?????

Andrea Cimitan (cimi) wrote :

I don't render anything if border-width is 0. If you want a 1px handle, set border-width to 1.

Changed in light-themes:
status: Invalid → Confirmed
Changed in gtk3-engines-unico (Ubuntu):
status: New → Opinion
Changed in unico:
status: Confirmed → Opinion
Andrea Cimitan (cimi) wrote :

And yes, no artifacts will be rendered with unico trunk if border-width is 1, as I intentionally adjust the background. Check trunk

affects: light-themes → ubuntu-themes (Ubuntu)
Daniel van Vugt (vanvugt) wrote :

I don't think Ubuntu has "handles" any more. Does it?

Changed in ubuntu-themes (Ubuntu):
status: Confirmed → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.