278159 - Should allow label on top of progressmeter

Status: NEW

(Core :: XUL, enhancement)

Description

[Ben Bucksch (:BenB)]

Progressmeters often have labels which are displayed in the middle of the
progress bar (with different colors, if necessary), at least displaying the
percentage.

The progressmeter property label does nothing currently (Neil said it used to in
at least Moz1.4).

You can fake it in your app using a stack, but a generic feature would be nicer.
So, I added an additional XBL binding which can do that. You'd need to set the
label attribute (to some value) in the XUL (so that the right binding gets invoked).

I am not sure, if my implementation is so great, so I am stopping that and just
doing it in the app (Mailnews in my case). Nevertheless attaching it, if it's
helpful for somebody.

Comment 1

[Ben Bucksch (:BenB)]

Attachment: Possible fix, v1

This is totally untested, just dry-coded.

The general idea with the stack does work very nicely, though (tested in
Mailnews).

The label has a shadow to work around the background color problem (don't know,
if it's atop of the bar, the remainder or both), because there doesn't seem to
be an "inverse" color value in CSS.

Comment 2

[Ben Bucksch (:BenB)]

Attachment: Screenshot

Comment 3

[[e-mail]]

Actually I said M14, not Mozilla 1.4

Comment 4

[[e-mail]]

Comment on attachment 171086 [details] [diff] [review]
Possible fix, v1

>+    <resources>
>+      <stylesheet src="chrome://global/skin/progressmeter.css"/>
>+    </resources>
This should already be automatically inherited.

>+      <field name="_meter" />
>+      <field name="_label" />
>+      <field name="_labelShadow" />
These appear unused.

>+      <property name="label" onset="if (this.label != val) this._label.setAttribute('label',val); return val;"
>+                            onget="return this.getAttribute('label');"/>
>+      <property name="mode" onset="if (this.mode != val) this.setAttribute('mode', val); return val;"
>+                            onget="return this.getAttribute('mode');"/>
Again, inherited.

>+      <property name="percentlabel" onset="val = val ? true : false; if (this.percentlabel != val) this.setAttribute('percentlabel', val); return val;"
>+                            onget="return this.getAttribute('percentlabel') ? true : false;"/>
This doesn't work. For an example of mapping an attribute to a boolean property
check out the "disabled" property in general.xml#basetext

>+              this.label =  this._bundle.formatStringFromName("percent",
>+                                                              [this.value], 1);
Using val will be cheaper than calling the getter. You might want to round it
too.

Comment 5

[Ben Bucksch (:BenB)]

(In reply to comment #4)
> This should already be automatically inherited.

Oh, right.

> >+      <field name="_meter" />
> >+      <field name="_label" />
> >+      <field name="_labelShadow" />
> These appear unused.

I could do it with attribute inheritance, so I won't need them, I think.

> This doesn't work. For an example of mapping an attribute to a boolean
> property check out the "disabled" property in general.xml#basetext

OK.

> Using val will be cheaper than calling the getter. You might want to round it
> too.

Sure, I wanted the shown value to match what's used, but I guess it's actually
better to show the set value (but rounded, as you said). They differ up to 2%.


Generally, Neil, do you think a patch like this is a good idea? I wasn't sure,
it sounded like a lot of crappy code for something that can be faked in the app.
OTOH, it's a base functionality that should be provided. I don't know.

Comment 6

[[e-mail]]

IIRC the counter argument was that native progress bars don't display
percentages (any more? I seem to remember that they used to...)

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614