Polish the style (and add Camino-like "up" icon) of trunk dirListings

RESOLVED FIXED

Status

Camino Graveyard
General
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Assigned: philippe (part-time))

Tracking

({polish})

Trunk
PowerPC
Mac OS X
polish

Details

Attachments

(8 attachments, 1 obsolete attachment)

In bug 392755, we landed the pinstripe "up.png" icon, which looks slightly out-of-place compared to the regular (Camino) folder icons.

We also might want to polish (or remove) the :hover rules and think about making the table rows striped like NSTableViews; see bug 392755 comment 13.

If any other style comments come in about these listings, we can put them here, too.
--- Bug 427840 Comment #3 Smokey Ardisson 2008-04-08 21:04:02 PDT ---

(In reply to comment #2)

>up we'd like to get re-made.

Jeff or philippe, have either of you given any thought to making a Camino
version of up.png?

http://mxr.mozilla.org/mozilla/source/camino/embed-replacements/skin/classic/global/dirListing/up.png

--- Bug 427840 Comment #4 philippe  2008-04-08 23:30:27 PDT ---

(In reply to comment #3)

I was planning to have a look at it, but I'm currently saddled with doing the
same kind of things for a client (and it doesn't move on).

(related: is there a psd source file for the folder.png somewhere ?)
(In reply to comment #0)
> In bug 392755, we landed the pinstripe "up.png" icon, which looks slightly
> out-of-place compared to the regular (Camino) folder icons.
> 
> We also might want to polish (or remove) the :hover rules and think about
> making the table rows striped like NSTableViews; see bug 392755 comment 13.

Did we get :nth() ?  Stefanh added some moz-css for the table rows not too long ago in bug 429188.

(In reply to comment #1)
> --- Bug 427840 Comment #4 philippe  2008-04-08 23:30:27 PDT ---
> 
> (related: is there a psd source file for the folder.png somewhere ?)

It's based on folder.tiff, but I don't think we have a .psd for that; Sam, correct me if I'm wrong.
(Assignee)

Comment 3

10 years ago
(In reply to comment #2)
> (In reply to comment #0)
> > In bug 392755, we landed the pinstripe "up.png" icon, which looks slightly
> > out-of-place compared to the regular (Camino) folder icons.
> > 
> > We also might want to polish (or remove) the :hover rules and think about
> > making the table rows striped like NSTableViews; see bug 392755 comment 13.
> 
> Did we get :nth() ?  Stefanh added some moz-css for the table rows not too long
> ago in bug 429188.

No :nth-child() support in Gecko 1.9. Maybe 1.9.x.
What was added in bug 429188 are colours (-moz-oddtreerow) only. What is needed is a hook in the xhtml file to select the rows as appropriate.

like this: the selector uses the [alternate="true"]
http://mxr.mozilla.org/mozilla/source/toolkit/themes/pinstripe/mozapps/downloads/downloads.css#15

> 
> (In reply to comment #1)
> > --- Bug 427840 Comment #4 philippe  2008-04-08 23:30:27 PDT ---
> > 
> > (related: is there a psd source file for the folder.png somewhere ?)
> 
> It's based on folder.tiff, but I don't think we have a .psd for that; Sam,
> correct me if I'm wrong.

I was looking at the icon the other day. 
The folder.tiff file is a little better than the .png one, but still only 16px by 16px. Very small to work with, even if the final result is 16px by 16px.
I'll give it a try soonish, though.

(Assignee)

Comment 4

10 years ago
Created attachment 320363 [details]
WIP 1
(Assignee)

Comment 5

10 years ago
Created attachment 320365 [details]
WIP 2

The folder.tiff as base turns out OK.

This second WIP is a bit taller; as a result, the whole line is pushed down slightly.

I tried first with green (similar to the arrow for downloads, and 'open' in the downloads window), but that does not sit well on the blue of the folder.
I like WIP 2, though I'm not sure about the red.  Does the green really look that bad?  (It looks OK on tab group folders, I think.)
(Assignee)

Comment 7

10 years ago
Created attachment 320404 [details]
WIP2 in green

with some more polish.

(In reply to comment #6)
> I like WIP 2, though I'm not sure about the red.  Does the green really look
> that bad?  (It looks OK on tab group folders, I think.)
> 

With the arrow on top, it works out better and the yellowish green. I was originally playing with a more blueish green, and with the WIP type1.
(Assignee)

Comment 8

10 years ago
Created attachment 320650 [details]
up.png with red arrow
(Assignee)

Comment 9

10 years ago
Created attachment 320651 [details]
up.png with green arrow

Smokey would you mind having a look at this one (and take it for a ride eventually) ?

The green arrow gets a bit lost on all white background.
I've also attached the same folder with a red arrow.
Attachment #320651 - Flags: review?(alqahira)
I think the green one looks fine.  

Apparently my conversion of folder.png "failed," since somehow it's the only one of the set with a profile :P but folder.png and up.png being slightly out-of-sync in color was the only thing I really noticed.  (I actually think that folder.png matches the Bookmark Bar folder.tiff color better than up.png does, which doesn't make any sense; optical illusion?)
(Assignee)

Comment 11

10 years ago
(In reply to comment #10)
> I think the green one looks fine. 

Hmm, maybe folder.png is a bit lighter indeed. 

Here is a static file generated from ftp some days ago, using the 'green' up.png and a regenerated folder.png (with all the same settings I used for up.png) - quick job, I'll go over them more carefully over the WE.

http://dev.l-c-n.com/camino/dirListing/ftp-listing.html

Both folder still look a little bit lighter than folder.tiff on the BM bar (with Colour management OFF), but that could be an optical illusion as well - due to the difference in background-colours.

both have gone trough
pngcrush -rem alla original-image.png final-image.png
(Assignee)

Comment 12

10 years ago
Created attachment 321350 [details]
up.png updated

updated up.png image.
This returns the exact same colour values for the blue(s) as folder.tiff and a resaved folder.png, which I'll attach next, as measured with digital colourmeter.

I've updated the demo html file link above.
Attachment #320651 - Attachment is obsolete: true
Attachment #321350 - Flags: review?(alqahira)
Attachment #320651 - Flags: review?(alqahira)
(Assignee)

Comment 13

10 years ago
Created attachment 321351 [details]
folder.png

updated folder.png based on folder.tiff
Attachment #321351 - Flags: review?(alqahira)
Is there a way to make these display in the right (matching folder.tiff) color with both color management off and on?  As you say, they match fine with it off but not with it on (and if we can't match them both ways, we'll take matching with it off as long as we're shipping with it off).
(Assignee)

Comment 15

10 years ago
(In reply to comment #14)

That may not be possible, I think. Camino's UI is _not_ affected by Gecko's colour management. Thus folder.tiff, on the toolbar will always display the same whereas the images in the ftp listings (content, Gecko), will be affected by the display profile.

The images in the UI are colour managed by the OS, and currently, OS X assumes that images without a profile are always in the currently used colour space (display). Gecko assumes sRGB for images without a profile. For web content, that is probably the sanest option. See also the discussions about the colour of the title bar in Minefield, bug 403169.

The 2 options are, as far as I can see:
* ship the images without a colour profile
* ship all images with a matching (!) colour profile (much larger files, folder.tiff goes from 1242 to 4418, folder.png from 569 to 3567, in quick test with a sRGB profile).

OTOH, the currently attached images looks quite close with colour management ON here, both on both the iMacs (default display profile) and the Apple 20inch with custom display profile.

Does it look that much different on your side ?
Created attachment 321459 [details]
What Smokey sees with CM on

(In reply to comment #15)
> The images in the UI are colour managed by the OS, and currently, OS X assumes
> that images without a profile are always in the currently used colour space
> (display). Gecko assumes sRGB for images without a profile.

I was afraid of something like that.

> The 2 options are, as far as I can see:
> * ship the images without a colour profile

AFAIK, we're doing this right now, which gets us into this predicament with CM on.

> * ship all images with a matching (!) colour profile (much larger files,
> folder.tiff goes from 1242 to 4418, folder.png from 569 to 3567, in quick test
> with a sRGB profile).

I think we're reluctant to do that to all of our image files unless we absolutely have to, though in terms of making things match here, we'd really only have to do folder.tiff, folder.png, and up.png, right?

> OTOH, the currently attached images looks quite close with colour management ON
> here, both on both the iMacs (default display profile) and the Apple 20inch
> with custom display profile.
> 
> Does it look that much different on your side ?

It's not what I'd call "wildly" different, but it's different enough that I notice.
(Assignee)

Comment 17

10 years ago
Created attachment 321462 [details]
What Philippe sees on an alu iMac

> > * ship all images with a matching (!) colour profile (much larger files,
> > folder.tiff goes from 1242 to 4418, folder.png from 569 to 3567, in quick test
> > with a sRGB profile).
> 
> I think we're reluctant to do that to all of our image files unless we
> absolutely have to, though in terms of making things match here, we'd really
> only have to do folder.tiff, folder.png, and up.png, right?
> 

And groupbookmark.tiff, it would otherwise look odd.
I could tag them with a generic RGB profile, which is smaller folder.tiff would be something like 1550bytes, roughly. The bm bar images will look a bit darker, saturated than what you see now.

Of course, those people who turn CM off would see a colour mismatch. The folder.png and up.png would look lighter.


> It's not what I'd call "wildly" different, but it's different enough that I
> notice.
>

That folder.tiff is much lighter than what I see here. Still within the expected range, though.
That is a MBP17 with those 'old' displays, correct ? (that is, unlike the MBP15 that start shipping in summer 2007 or thereabouts, those have much wider gamut).
Comment on attachment 321350 [details]
up.png updated

I think let's cross the color management bridge when we come to it; this clearly looks close enough with CM on in some cases, and it's fine with CM off.
Attachment #321350 - Flags: superreview?(stuart.morgan)
Attachment #321350 - Flags: review?(alqahira)
Attachment #321350 - Flags: review+
Attachment #321351 - Flags: superreview?(stuart.morgan)
Attachment #321351 - Flags: review?(alqahira)
Attachment #321351 - Flags: review+
(In reply to comment #17)
> That folder.tiff is much lighter than what I see here. Still within the
> expected range, though.
> That is a MBP17 with those 'old' displays, correct ? (that is, unlike the MBP15
> that start shipping in summer 2007 or thereabouts, those have much wider
> gamut).

No, that's from a MBP15 from last fall (Aug/Sep); I've thought since the beginning that some colors were off on it, though.
Assignee: nobody → phiw

Updated

10 years ago
Attachment #321351 - Flags: superreview?(stuart.morgan) → superreview+

Comment 20

10 years ago
Comment on attachment 321350 [details]
up.png updated

sr=smorgan, although I'm not sure I would necessarily associate this (or the original) icon with its action absent the text that goes with it.
Attachment #321350 - Flags: superreview?(stuart.morgan) → superreview+
Landed on the trunk!
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 22

10 years ago
(In reply to comment #21)
> Landed on the trunk!

Yay !

(You put a typo in my name in Bonsai message: an 'h' missing at the end 
s/Wittenberg/Wittenbergh 
But that is not important)

(In reply to comment #22)
> (You put a typo in my name in Bonsai message: an 'h' missing at the end 
> s/Wittenberg/Wittenbergh 
> But that is not important)

Gah, sorry about that :(  I knew it belonged there...and I knew I was going to mess something up on my first checkin in ages :(
You need to log in before you can comment on or make changes to this bug.