10909 - [PP]GFX-rendered widgets are ugly!

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Dan Rosen]

All of the gfx-rendered widget sets (form elements such as radio buttons & combo
boxes) I have seen have been pretty ugly, and don't visually work well with
pages that don't have white backgrounds. I don't know precisely what's involved
in creating a widget set, but I'd volunteer to create one if I could find the
appropriate tools...

Comment 1

[troy]

Kevin, I don't know if this is you, or Rod, or German

Comment 2

[Dan Rosen]

i noticed this is targeted for m11 -- please let me know if and how i can be of
any assistance before then. i consider myself a somewhat experienced graphic
designer...

Comment 3

[Matthew Tuck [:CodeMachine]]

I think widget sets generally are the result of a program drawing various
shapes.  If you look at widgets, they are tend to be fairly simple shapes, with
things like 3D effects simply being coloured lines.

Since your address has cs in it, you probably can program.  If so, I think the
best thing to do is just look at the tree yourself and work out how it all
works.  Hopefully these guys have made the directory hierachy
semi-understandable.

For more graphical stuff, you could contribute icons for the user interface in
certain places you feel they're lacking.  I personally think a large picture of
Mozilla would be great for the "about:mozilla" screen, although that's not
exactly seen by a lot of people.

If you're interested in messing with the user interface totally ("skins"), start
at the ChromeZone (http://www.mozillazine.org/chrome/).

Comment 4

[Dan Rosen]

Browsing through the code (in /mozilla/layout/html/forms I think), that seems to
be the way things are done. Unfortunately, it seems like the actual gfx work is
delegated to the CSS rendering code somehow, and I doubt I'd be able to fully
grok how all this fits together without hella documentation and free time... I
have seen gfx-rendered widget sets dynamically switched (in one of the demos
somewhere) which leads me to believe that the way widgets are drawn aren't fixed
in the code. I just can't find where, assuming they're in some sort of resource
file, they are living...

As for skins, I looked through some of the existing XUL, and it was very cool,
but the impression I get is that the way skins are handled is still not set in
stone, so I'd rather not invest excessive energy in that yet. When things settle
down, though, hooo boy, I'll be all over those skins baby!

Anyway, in the interim, if somebody can point me to where form element gfx are
defined, I'll work on it enthusiastically, but for now I can't find it myself.

Comment 5

[Matthew Tuck [:CodeMachine]]

Well you probably know more about the code than me now, but I can say this:

The reason gfx widgets were introduced was so widgets could be styled fully
using CSS, which you can't do with native widgets.  I'm not exactly sure
everything this entails, but you can expect it's things like colour, thickness,
etc.  Hence the widget sets need to delegate themselves to the CSS code somehow.
 Any widget set will need to do this.  Definitely not just a couple of bitmaps.

BTW, I seem to remember a "gfx" directory on my cvs tree.  Look for that
somewhere.

Comment 6

[Dan Rosen]

That makes a lot of sense. It never even occurred to me that widgets themselves
would be styleable, but that's how it seems to work. I played around with viewer
demo #16 some, checked out the css definitions for each of the swappable styles.
Very cool, even if they're rendered ugly. Nevertheless, I thought I ought to
attach the resulting screenshots just in case things are mysteriously uglier on
my platform (linux + xfree, nothing too special)... I'm attaching five images,
one for each style.

Comment 7

[Dan Rosen]

Attachment: screenshot for demoform.css

Comment 8

[Dan Rosen]

Attachment: screenshot for mozform.css

Comment 9

[Dan Rosen]

Attachment: screenshot for aform.css (not bad looking)

Comment 10

[Dan Rosen]

Attachment: screenshot for bform.css

Comment 11

[Dan Rosen]

Attachment: screenshot for cform.css

Comment 12

[Matthew Tuck [:CodeMachine]]

I think part of the point is that they should look ugly if the css tells them
too, and look nice if the css tells them too.  =)

Anyway, the buttons and radio buttons on bform.css look like a botch job under
Linux, its not so bad under my windows build (maybe fixed).  I suspect that
those horrible circles might be an image dictated by css somewhere rather than a
widget thing.

I'm using a nightly build, but I gather from the look of the buttons,
checkboxes and radio buttons they are gfx.  However I know not all gfx widgets
are the default yet - and judging by the differences between yours and mine, I'd
say listboxes aren't (the old native widgets had some limited styling I
believe).

I believe gfx widgets won't necessarily show just by choosing this example -
have you set the relevant gfx widgets on preference?

Are there any other problems that can't be attributed to CSS?

Comment 13

[Dan Rosen]

> I think part of the point is that they should look ugly if the css tells them
> too, and look nice if the css tells them too.  =)

Well, let's look at bform.css:

...
input[type="radio"] {
 width:14px;
 height:14px;
 border:1px solid black;
 background-color:rgb(200, 200, 200);
}
...

Obviously the rendering of this widget would be ... errr, "minimalist" at best.
Which is fine, because that's what it says to do. But instead of "minimalist,"
things turn out "ugly" ;)

My best guess is that if things don't look nearly so bad under win32, than some
sort of XWindows platform-specific rendering code needs tweaking. I doubt the
actual nastiness happens in a css definition, if it looks better on some
platforms than others...

This will hopefully be dealt with by the same folks who I assume are to be
landing (or maybe already have landed, and there's an option I haven't found)
the gfx-rendered list/combo box widgets for X.

Comment 14

[Kevin McCluskey (gone)]

Don, I am re-assigning this to you. The -moz-border-radius property has
unexpected results on Linux. My guess is that it is a difference in pixel
coverage on that platform. Marking as [PP].

Comment 15

[Sjoerd Visscher]

I think the code that draws circles(-parts) needs some work.
They're not symmetrical, and the circle-parts (arcs) do not attach well to the
rest of the shape.
Maybe the drawing is done via the OS, which might be a bad idea (for small
circles anyway, they should be anti-aliased) Maybe we should just wait for the
SVG code ;-)

Comment 16

[Hixie (not reading bugmail)]

[e-mail]: If you are still interested, the widgets are styled by the
code in ua.css, which is found in the resources directory.

Comment 17

[dcone (gone)]

I don't know about the ugly thing, but the radio buttons and rounded rects have
a much smoother bend and circles now look like circles.  Beauty is in the eye of
the beholder... so I hope the widgets are not UGLY any longer.  A more accurate
description of the problem in the summary would benifit us all next time.

Comment 18

[Chris Petersen]

With the 0ct 25 Linux build, the buttons have a smoother appearance.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3f2e997e7808
[fenix] For https://github.com/mozilla-mobile/fenix/issues/10909: Fix flaky navigateBookmarksFoldersTest (https://github.com/mozilla-mobile/fenix/pull/11592)