175567 - A way to disable pick-up of native gtk theme at compile time

Status: RESOLVED WONTFIX

(Core Graveyard :: Skinability, enhancement)

Description

[Henrik Edlund]

I would like to be able to disable the pick-up of the native gtk theme at
compile time. That is, with some compile time option, make Mozilla ignore the
native gtk theme and use it standard built-in theme when running in Classic mode.

This could also be a run-time command line option of course. In any case, the
1.2b behaviour of just using the native gtk theme, is really bad for me and our
computing environment.

Comment 1

[Henrik Edlund]

Or a hidden (or displayed in Preferences for that matter) preference option to
control it, would also be okay.

Comment 2

[Joseph Fannin]

AOL!   
   
Aside from not being able to pick up pixmap gtk themes (and it's ugly when it   
fails), not being able to use classic remotely is terrible.  The default   
Mozilla skin should not be crippled this way. 
  
It should also disable the picking-up of gtk colors too like is done in 1.1.  
  
   
   

Comment 3

[Henrik Edlund]

This can't be that hard to implement, is anything being done do this "bug" at
all or are everyone GTK-entranced?

Comment 4

[Henrik Edlund]

Something happening here?

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

Mass reassign of my non-Firefox bugs to [e-mail]

Comment 6

[chris hofmann]

cls,  wonder if you have thoughts on how we could do this, and investigate a
bit.  --thx chofmann

Comment 7

[cls]

IIRC, you just have to disable native theme support by unsetting
NATIVE_THEME_SUPPORT in gfx/src/gtk/Makefile.in .

Comment 8

[Henrik Edlund]

Nope. It still picks up the ugly default "Motif-looking theme. Instead of
keeping the nice looking partly-Modern theme (scrollbars, dropdowns, etc; not
toobar icons) for the Classic theme.

Comment 9

[cls]

WFM.  With a normal gtk1 build, I was able to change the way the scrollbar
looked by using the gnome-control-center.  I changed it to use the Metal theme.
 I backed up that copy of Mozilla.  I then edited gfx/src/gtk/Makefile and
commented out the NATIVE_THEME_SUPPORT=1.  I rebuilt in that directory using
'make -C gfx/src/gtk clean all'.  When I reran Mozilla, it was no longer using
the Metal theme.  I can run the backup copy at the same time to verify that the
theme handling is different.  FWIW, the controls were the only things I noticed
changing.  And I thought the ugly Motif looking theme *was* the Classic theme.  

Comment 10

[Henrik Edlund]

Before Mozilla began trying to pickup some GTK theme, it used the good looking
scrollbars now seen in the modern theme for the classic theme as well. This bug
was created at the time this happened as I and others wanted a way to disable
this new "feature" of using the ugly Motif scrollbar, which must come from the
GTK standard/default theme right?

I have no GNOME environment here so I cannot test any kind of theme selector.

Comment 11

[cls]

I vaguely remember several builds occuring where Modern & Classic themes got
mixed up but I don't follow those sort of UI changes.  The summary is misleading
if all you're really looking for is the modern scrollbars in the classic theme.

Comment 12

[Andrey ``Bass'' Shcheglov]

Attachment: Mozilla 1.1 running its own theme in "classic" mode

Comment 13

[Andrey ``Bass'' Shcheglov]

Attachment: Mozilla 1.2 running native GTK theme in "classic" mode

Here're two screenshots to make the difference obvious.

Not only scrollbars and comboboxes have that "ugly Motif style", but also menubuttons (Back, Forward, Print) have inconsistent border/font color/bg color once hovered.

Since Communicator 4.x, when a menu button is hovered/pressed, it should have a 1-px black border around 1-px bevel border. Font color in hovered/pressed state should be light blue/navy blue.

This behavior have been present in both Xlib and Windows builds, but is broken in both GTK1 and GTK2 builds since Mozilla 1.2.

Comment 14

[Andrey ``Bass'' Shcheglov]

BTW, shouldn't this be moved from "Core" to "Mozilla Application Suite", since this is essentially a SeaMonkey bug?

Comment 15

[Julien "_FrnchFrgg_" RIVAUD]

Gnomestripe is currently not in shape to be used without native theming. Instead of fixing it (i.e. add backgrounds and borders for 50% of widgets), it has been decided to strip it from the remaining unused border/bg rules and make it depend on native integration. This bug is thus WONTFIX (see bug 412307)