[PP]GFX-rendered widgets are ugly!

VERIFIED FIXED in M11

Status

()

P3
major
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: dr, Assigned: dcone)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

19 years ago
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...

Updated

19 years ago
Assignee: troy → kmcclusk

Comment 1

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

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M11
(Reporter)

Comment 2

19 years ago
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...
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/).
(Reporter)

Comment 4

19 years ago
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.
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.
(Reporter)

Comment 6

19 years ago
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.
(Reporter)

Comment 7

19 years ago
Created attachment 1175 [details]
screenshot for demoform.css
(Reporter)

Comment 8

19 years ago
Created attachment 1176 [details]
screenshot for mozform.css
(Reporter)

Comment 9

19 years ago
Created attachment 1177 [details]
screenshot for aform.css (not bad looking)
(Reporter)

Comment 10

19 years ago
Created attachment 1178 [details]
screenshot for bform.css
(Reporter)

Comment 11

19 years ago
Created attachment 1179 [details]
screenshot for cform.css
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?
(Reporter)

Comment 13

19 years ago
> 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.

Updated

19 years ago
Assignee: kmcclusk → dcone
Severity: minor → major
Status: ASSIGNED → NEW
Summary: GFX-rendered widgets are ugly! → [PP]GFX-rendered widgets are ugly!
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].
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 15

19 years ago
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 ;-)
dr@cs.brown.edu: If you are still interested, the widgets are styled by the
code in ua.css, which is found in the resources directory.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 18

19 years ago
With the 0ct 25 Linux build, the buttons have a smoother appearance.
You need to log in before you can comment on or make changes to this bug.