GNOME Bugzilla – Bug 86040
Add a line weight parameter that is proportional to the font size or total titlebar height
Last modified: 2020-11-07 12:36:19 UTC
the metacity themes appear to use hard-coded sizes and lineweights for drawing all their graphical objects, despite the fact that they observe system settings for font, and color (in some cases at least) - thanks Havoc :-) For a user who needs large print or bold graphics however, the default button sizes and lineweights are likely to be too small. Also it makes some of the themes look bad if you scale the font way up and the graphics don't scale up with them. It would be nice to have specifications for button sizes, etc. in percent, ems, or something similar. there is a related bug regarding the fact that the pixmaps are sometimes too narrow to fill the painted region when the text gets big also. .
see also bug 86039.
I believe the theme format is adequate to write a theme that handles large fonts properly. So the problem here is just to fix each individual theme. I have a bug open already for that in here somewhere. I'm not going to fix themes other than the default one, the others are just "contributed bonus themes" as far as I'm concerned. Suggest mailbombing the theme authors. ;-) If them being broken is a showstopper I'll just take these themes out.
I found a couple of problems in the Atlanta theme 1. The maximize, minimize, close and menu button doesn't scale up to the font size. 2. The pixel size used to draw these buttons remains the same (i.e. it is fixed for all the font sizes) problem 1 above is fixed by providing the aspect ratio in the xml file and now the graphical elements scale up according to the font size. Coming to the second problem, I found that the close and minimize buttons are drawn using line function. Also, the parameter *width* to the line function is an integer, so we can't give expressions in the xml file (I believe it is possible only with strings). So, I changed meta_draw_op_draw_with_env() in theme.c to increase the pixel size according to the font size. May be we should come up with a more generic calculation that is suitable for all the themes. Am attaching a patch for this (I hope this would atleast fix the scaling issue).
Created attachment 9772 [details] [review] proposed patch
The patch to draw the window icons larger seems fine, but increasing line width will break other themes. The basic line-drawing primitive shouldn't be scaled. Instead we should introduce some way to scale line widths perhaps. I'm pretty sure that's going to look ugly though. Owen had a suggestion that we allow themes to ship with a small truetype font file, and render glyphs from that. Then you could use a font glyph for little icons like this. That'd be pretty nice I think. The syntax might be something like <glyphs name="foo" source="foo.ttf"/> and then in draw_ops <glyph name="foo" x="10" y="12" alpha="0.5"/>
Adding PATCH; not really sure if this is 'high' or not- final call is up to you, Havoc, but I'm marking up because of bill's concern.
Well the patch isn't right, we can't change what the drawing primitives do to work around themes. Another idea here is to allow SVG icons using librsvg. With appropriate caching that might be fast enough.
havoc, what is wrong with specifying line weight as a fraction of the icon height rather than a hard-coded thickness? This would make for an acceptable patch I think, so that the XML file could specify an attribute such as lineweight=0.05 within a graphical element (at the moment some graphical elements have lineweights specified in pixels, for instance the heavy lines used for the 'iconify' graphic).
Changing the XML format so that themes _can_ specify a line weight as some kind of fraction would be fine. But just modifying the current line primitive to do that by default is completely broken.
Note that this is now fixed for Crux (crux now rescales its pixmaps). The fix is a bit ugly to look at but meets the urgent need.
hey, Crux scaled is meant to be as close to the original theme as possible ! Do you have any specific requests of things that need fixing ? I'll gladly help.
can we consider this particluar bug fixed (in light of havocs comments about non-default themes) - the graphics appear to scale up when font size is increased now... ? :)
No, there still isn't a way to draw lines with width relative to font size.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Havoc, please suggest the XML line-weight tag format and somebody can prepare a patch that uses it. How about allowing, for "width" in the <line> element, an expression such as "height * 0.1" or "height / 8" (and clipping to the nearest integer if you like, to avoid antialiasing problems).
The bad news on this bug is bug #102547 If we change the theme format, we need to increment the metacity theme version, and also change metacity to be able to load the new version falling back to old version, and to throw errors if a theme with the old version contains features only supported by the new version. So there's some work involved to make any theme format change, other than the theme format change itself. That caveat covered, your proposal here sounds OK to me (just make the width attribute on <line> take an expression instead of a constant). The other option I see would be to add width_ems="N" or width_exes="N" i.e. add a width attribute that accepts a font-dependent unit of measurement.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
The following patch allows use of expressions for line width. I didn't modify Atlanta on purpose as I think we would get much better results with SVG buttons. But that's <a href="http://bugzilla.gnome.org/show_bug.cgi?id=107012">another story (#107012)</a>.
Created attachment 22911 [details] [review] proposed patch for line width expressions
Thanks, some comments on the patch - Please avoid C++/C99 comments for another year or two: + // should "width" stay optional ? Should have a space before parens: if(width) How is parse_weight_expression different from parse_size_expression? If it isn't just using parse_size_expression seems fine to me. Finally, remember we can't commit this patch until we do the stuff to support multiple theme format versions. I'll add a comment to bug 102547 about how to implement that.
Thank you, I'll update that patch once the one for 102547 will be done. The difference between size and weight is that weight can be 0. I don't really know why and it is a problem: A line with width = 0 is not the same length with width = 1. It's shorter. So if you use width = "height / 16", when height < 16 the line is suddenly too long. I could avoid width = "0" altogether but it used to be the default when you don't specify a width argument. One solution would be to break this contract as well in the theme v2. We would then default to width = 1 and would never ever use width = 0. Finally, maybe I don't understand the bugzilla stuff quite right but shouldn't it be 102547 that blocks 86040 and not the other way round ?
Ignore the rambling about line width. When you properly set the cap_style, everything is fine.
A couple of problems: now that I'm doint it, I realize that to fix this bug properly I should also implement line weight for arcs and rectangles. These already have a "width" parameters so how do I call it, "weight" ? Then it's not consistent with line weight(width) but I don't see how to avoid that anyway. On a related note, once the arcs, lines and rectangles have a weight, it makes sense to implement cap_style for lines and arcs as well as join_style for rectangles (if it works for rectangle, the doc says "polygons"). And finally once you have all that, you want to render AA rather than 2 bits pixmaps right ? Although I don't know how hard that would be... Please comment
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Remove old target milestones on old bugs; sorry for the spam.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
I'm not sure why this didn't make it into metacity-theme-2, perhaps because it wasn't assigned to the tracking bug. I suppose it's a case for metacity-theme-3. Still, I'm marking the patches as obsolete because they're five years old.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.