Check in linux desktop/taskbar icons



16 years ago
10 years ago


(Reporter: Jason Kersey, Assigned: Brian Ryner (not reading))


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



16 years ago
per summary.  broken off of 73712.

Comment 1

16 years ago
->bryner in hopes that he can make us suck a little less for 1.1
Assignee: kerz → bryner
Blocks: 157592

Comment 2

16 years ago
Still hoping to see distinct icons under Linux for Browser & Mail in 1.1.  Any
is this the same as / related to bug 29856?

Comment 4

16 years ago
biesi: IIRC, bug 29856 blocks this one as those icons can't be used once they're
checked in. Marking as dependency.
Depends on: 29856

Comment 5

16 years ago
Not related to 29856.
No longer depends on: 29856

Comment 6

16 years ago
Created attachment 94902 [details] [diff] [review]

Implement per-window icons for gtk

Comment 7

16 years ago
Created attachment 94903 [details] [diff] [review]
the new icons

Comment 8

16 years ago
I went ahead and had mcafee copy the windows .ico files in the repository to
xpfe/bootstrap/icons/windows, for consistency and so we don't have so many icon
files cluttering up xpfe/bootstrap.
Comment on attachment 94902 [details] [diff] [review]

Attachment #94902 - Flags: review+
Comment on attachment 94902 [details] [diff] [review]

>+ifneq (,$(filter windows gtk,$(MOZ_WIDGET_TOOLKIT)))

Oh, can you add gtk2 to that list?  I would appreciate it.

Comment 11

16 years ago
I wasn't adding gtk2 yet since the code to support loading the icons isn't there.

the location might need to be changed, and I've already filed a bug to use a
better resoltion scheme.  gtk2 definitely supports icon loading, though.

Comment 13

16 years ago
My bad.  New patch coming up.

Comment 14

16 years ago
Created attachment 95015 [details] [diff] [review]
patch v2

handle gtk2
Attachment #94902 - Attachment is obsolete: true

Comment 15

16 years ago
rginda's interested in this. 

Comment 16

16 years ago
I'm curious how this is "not related to bug 29856"?  This patch seems like a
copy of the cheezy windows hack, whereas 29856 would be a general purpose (and
much cleaner) solution.  Why check in all this hard-coded path/file extension
stuff when we can just set a wmclass and let the window manager decide what to do?


16 years ago
Blocks: 76211

Comment 17

16 years ago
I'm not saying 29856 isn't a good fix to have, but I think it addresses a
different problem from what this is addressing.  Setting a wmclass does not
automatically get you a particular window icon, and asking users to do custom
window manager configuration to set such an icon (when there's obviously a more
supported mechanism for setting it) is not acceptable.  If you're using the
GNOME panel, it doesn't have any visible support for associating an icon with a
particular window class.

Comment 18

16 years ago
I'm making one minor change, not going to attach a new patch for it.  Instead of
using nsMemory::Free() for freeing the hash entry string, I changed it to use
free() since that matches with strdup()'s usage of malloc().

Comment 19

16 years ago
Re Comment #18, may I suggest reading some comments in Bug #29856 (around #51)
for discussion about nsMemory and strdup. I only mention this, not to say that
29856 is related to this bug, but because the discussion may be relevant to your
last change.

Comment 20

16 years ago
*** Bug 162540 has been marked as a duplicate of this bug. ***

Comment 21

16 years ago
Comment on attachment 95015 [details] [diff] [review]
patch v2

Attachment #95015 - Flags: review+

Comment 22

16 years ago
So now we just need a "sr" and an "a" on this bug and v1.1 will be ready.
this has sr= already, see comment 9

so this can land on trunk anytime

this fixes bug 76211 too, right?

Comment 24

16 years ago
I was just looking at the Status messages for the Attachments, and none of them
have a "sr" or an "a". Comment #9 may say "sr", but blizzard didn't make that
change to the attachment.

However, if I was the owner, I'd probably check it into the trunk anyway.

But it still needs an "a" for the v1.1 release.
Comment on attachment 95015 [details] [diff] [review]
patch v2

dgk, blizzard offered either an r or sr. you can't put that on attachment
tracker. that's no problem.

but if it makes you feel better, I can put the has-super-review there.
Attachment #95015 - Flags: superreview+

Comment 26

16 years ago
Comment on attachment 95015 [details] [diff] [review]
patch v2

a=asa (on behalf of drivers) for checkin to 1.1
Attachment #95015 - Flags: approval+

Comment 27

16 years ago
Checked in on trunk and 1.1 branch.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 28

16 years ago
Stupid question (this might be spam, but I don't come along with this bug): 
With Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020815, BuildID
2002081521 I just see under kde 2.2.1 only the XWindow icon as desktop/taskbar
icons ... This wasn't intended, wasn't it?

Comment 29

16 years ago
Hmm, I don't see this Problem (yesterday's trunk CVS build, RH7.3 Linux) - I
have a different, Mozilla-specific icon for each application.

While I think that the muted (as in dark and weak in color contrast - I'm not so
sure of my English vocabulary here) colors make the icons a bit hard to
distinguish, I really like the design. It's great to have different icons in
Linux at last! :-)

Comment 30

16 years ago
comment #28 is an issue with installer builds, see bug 163067

Comment 31

16 years ago
Icon for the calendar component is missing.
Resolution: FIXED → ---
Daniel, that's bug 163371 and happens on windows too.

marking fixed again.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 33

16 years ago
It is not. bug 163371 is on ChatZilla icon. Reported new bug 166433.
oops :/ I should learn to read. anyway, filing a new bug was the right thing.

Comment 35

16 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/2002100214

I have no Mozilla icons in any windows and not in the KDE taskbar. Always the X
of X window is used. Most windows had correct icons in RPMs of Friday 13 September.

Looks like bug 165318 is the bug which says this is not fixed.

Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.