** Changed in: human-theme (Ubuntu)
Status: Fix Committed => Fix Released
--
Human theme makes bad GTK widget class assumptions
https://bugs.launchpad.net/bugs/237261
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
gtkrc change fixes this bug
** Changed in: human-theme (Ubuntu)
Status: In Progress => Fix Committed
--
Human theme makes bad GTK widget class assumptions
https://bugs.launchpad.net/bugs/237261
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Changed in: human-theme (Ubuntu)
Status: Confirmed => In Progress
--
Human theme makes bad GTK widget class assumptions
https://bugs.launchpad.net/bugs/237261
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mail
My point is that there could be 1000 custom apps out there doing similar
things. Your solution is to ignore them. You have to realize that there
are some extremely serious issues regarding GTK theming, and as a theme
designer, you need to respect that. Just because you want something to
look a fanc
My point is that the only apps which have these problems are ones that
create their own custom widgets. Trying to play around with the few
colors that we can define just makes things unbelievably hard for the
theme developer to do something different than the norm (light grey bg
with dark text). I
My example of "bad" is not setting bg[SELECTED], which just sets it to
the defined color constant, it's setting the "treeview" hint on the
Clearlooks engine. This causes Clearlooks to do something special with
the bg[SELECTED] color (make it lighter).
Because of this hint, two separate background
No, it means that if the app used normal gtk classes this problem would
not occur :-) In your example of "bad" theme code we set the
bg[SELECTED] color to the color value of @selected_bg_color which only
makes sense, really. The fact that one has to explicitly set it is bad
but that is not a proble
"The correct way to do this would be to ask apps to follow the rules and
don't hack together widgets from classes which were not intended to be
hacked thusly."
I'm sorry, but what? Are you saying that it's wrong to write custom
widgets? Are you saying that everything you could ever want to
accompl
** Changed in: human-theme (Ubuntu)
Status: New => Confirmed
--
Human theme makes bad GTK widget class assumptions
https://bugs.launchpad.net/bugs/237261
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Kenneth:
You create a theme which works by not special casing colors to certain
widget classes. While it might be nice to do, unfortunately the GTK 2
theme system is extremely limited and is a layer of hacks.
The argument that no one should write widgets not derived from standard
GTK widgets is a
As the app is using a non-standard class widget how can we create a
theme which works? Firefox, gnome-control-center, and vlc all have these
problems (it has become apparent when switching to the dark theme). The
only way I know how to work around this is to apply the correct theme
info to these sp
Maybe this is related: I use the Ubuntustudio theme (colours and
controls) and banshee 0.99.3 (from the ppa mentioned on the website).
When I move the cursor over an item in the left hand side list of
playlists, the item disappears. It reappears again when I remove the
mouse cursor from it. I guess
Here's the most relevant upstream bug on this issue:
http://bugzilla.gnome.org/show_bug.cgi?id=534731
--
Human theme makes bad GTK widget class assumptions
https://bugs.launchpad.net/bugs/237261
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ub
13 matches
Mail list logo
