Bug 443309
| Summary: | firefox looks ugly in kde 4 (gtk theme wrong) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Philipp N. <neo6238-redhat> | ||||
| Component: | kdebase-workspace | Assignee: | Kevin Kofler <kevin> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 9 | CC: | ben.lewis, kevin, ltinkl, rdieter, than, tuju, tuxbrewr | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 4.0.4-4.fc9 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-05-21 10:58:17 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Philipp N.
2008-04-20 14:35:04 UTC
Firefox just reads the system settings, so this definitely isn't a firefox bug. I'm guessing the KDE4 spin needs to somehow set the default GTK theme or something to match what is used in the default GNOME spin or something? Sending over to KDE for now, but this is probably a spins issue... not sure who gets that. "Firefox just reads the system settings", what exactly does that mean? Shouldn't the default gtk2 theme "just work"? I'll have to double-check whether this applies to all gtk2-based (themed) apps or just firefox. Fwiw, I see proper theming on my box, but I've got both kde-desktop and gnome-desktops installed. Which implies to my untrained eye, that the gtk2 default theme isn't being pulled in or used automatically for some reason. Right. It needs to get pulled in. If not, then there's not much firefox can do. It can't guess what the theme should be. The Nodoka theme is on the KDE Live spin, the problem appears to be that it doesn't get enabled if nothing starts gnome-settings-daemon. The problem is: I don't understand why, because Nodoka is set as the systemwide default theme in /etc/gtk-2.0/gtkrc. pong over to kind gtk2 folks to help determine why nodoka isn't working in the absence of g-s-d or possibly missing dep. isn't this because kde is setting GTK2_RC_FILES to point to some gtkrc file of its own ? It sets it to a list of files, /etc/gtk-2.0/gtkrc is first in that list. Ugh, this may have something to do with it (from kde-settings): /usr/share/kde-settings/kde-profile/default/share/config/gtkrc-2.0 don't remember when/how that got there. OK, that's not it, did rm -f /usr/share/kde-settings/kde-profile/default/share/config/gtkrc-2.0 rm -f ~/.gtkrc* logout/login, can now reproduce. next stop, login to gnome, kill gnome-settings-daemon, see what happens. Tried testing under gnome too, but darn sucker (re)starts gnome-settings-daemon every time I tried to kill it. but... upon looking further, it *is* at least partly kde's fault: $ set | grep gtk GTK2_RC_FILES=/home/rdieter1/.gtkrc-2.0-kde4:/home/rdieter1/.kde/share/config/gtkrc-2.0 GTK_RC_FILES=:/home/rdieter1/.kde/share/config/gtkrc No /etc/gtk-2.0/gtkrc in there. Oh, and appending /etc/gtk-2.0/gtkrc to GTK2_RC_FILES did the trick. OK, then let's take the bug again. This is a KDE 4 regression, in KDE 3 the file is there. The code to add the file is still there in KDE 4 though, we'll have to look at what changed so we can revert it. By "the file is there", I mean it's listed in GTK2_RC_FILES. related upstream report: http://bugs.kde.org/show_bug.cgi?id=146779 Looking into it, if I come up with a patch, I'll submit it to the upstream bug report too. Should be fixed in kdebase-workspace-4.0.4-2.fc9 which is currently building. I wrote the patch, Rex tested and built it, that's teamwork. :-) http://koji.fedoraproject.org/koji/buildinfo?buildID=48468 Created attachment 304870 [details]
don't lost SystemGtkrc
Here's a patch we tested to work, to ensure that systemGtkrc doesn't get lost.
Not sure exactly why the old code didn't work (it's almost the same as the kde3
versions that were ok).
patch comitted upstream. kdebase-4.0.4-2.fc9, kdeaccessibility-4.0.4-1.fc9, kde-l10n-4.0.4-1.fc9, kdetoys-4.0.4-1.fc9, kdebindings-4.0.4-1.fc9, kdenetwork-4.0.4-2.fc9, kdegraphics-4.0.4-1.fc9, kdeartwork-4.0.4-1.fc9, kdesdk-4.0.4-1.fc9, kdegames-4.0.4-1.fc9, kdebase-workspace-4.0.4-4.fc9, kdeutils-4.0.4-1.fc9, kdeedu-4.0.4-2.fc9, kdebase-runtime-4.0.4-1.fc9, kdemultimedia-4.0.4-1.fc9, kdelibs-4.0.4-1.fc9, kdeadmin-4.0.4-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kdebase kdeaccessibility kde-l10n kdetoys kdebindings kdenetwork kdegraphics kdeartwork kdesdk kdegames kdebase-workspace kdeutils kdeedu kdebase-runtime kdemultimedia kdelibs kdeadmin'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-3664 Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Update to *-4.0.4 fixes the problem for me. kdebase-workspace-4.0.4-4.fc9, kdebase-4.0.4-2.fc9, kde-l10n-4.0.4-1.fc9, kdesdk-4.0.4-2.fc9, kdemultimedia-4.0.4-2.fc9, kdelibs-4.0.4-4.fc9, kdeedu-4.0.4-2.fc9, kdebase-runtime-4.0.4-1.fc9, kdepimlibs-4.0.4-1.fc9, kdenetwork-4.0.4-2.fc9, kdegraphics-4.0.4-1.fc9, kdeaccessibility-4.0.4-1.fc9, kdeartwork-4.0.4-1.fc9, kdeutils-4.0.4-1.fc9, kdebindings-4.0.4-1.fc9, kdetoys-4.0.4-1.fc9, kdegames-4.0.4-2.fc9, kdeadmin-4.0.4-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. |