Bug 1367 - FryskGui/Source Window does not accept GTK Theme Changes
Summary: FryskGui/Source Window does not accept GTK Theme Changes
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P1 normal
Target Milestone: ---
Assignee: Igor Foox
Depends on:
Blocks: 1633 1975 2031
  Show dependency treegraph
Reported: 2005-09-22 17:18 UTC by Phil Muldoon
Modified: 2006-01-31 16:25 UTC (History)
3 users (show)

See Also:
Host: i386
Target: i386
Build: i386
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Phil Muldoon 2005-09-22 17:18:53 UTC
In FC4:


Select a theme

Observe that all other GTK apps accept new theme. Observer the Frysk GUI does not.

This may have something to do with us shipping a seperate GTK stack in /opt
Comment 1 Phil Muldoon 2005-10-13 15:43:59 UTC
After a little digging around, it might be that we do not have corresponding
frysk-gtk rpm that should mirror gtk2-engines. The version in FC4 is 


I can't find a corresponding frysk-gtk2-engines component
Comment 2 Igor Foox 2005-10-14 19:17:08 UTC
So I looked at what's going on here, and asked a bit in the gtk+ irc channel.

What happens is that GKT+ has directories in which it looks for dynamically
loaded  things like extra .sos and themes. These are usually based off of the
GTK+ installation directory, in our case /opt/frysk.

We can override these with environment variables. Specifically GTK_DATA_PATH
specifies the prefix of the data directory (should be /usr) and GTK_EXE_PATH
specifies the prefix of the directory where GTK looks for dynamically loaded
.sos, like the sos from the gtk2-engines package. 

If you set these 2 environment variables to /usr and then invoke frysk, the
themes change. Now the question is how should we deal with this? 
One way to do this is to get the installation prefix at configure time, and
stick it in a Config.java.in (or something like that), and have FryskGui set the
environment variables when it starts (before initializing the gui). 

Any ideas/suggestions/thoughts?

Comment 3 Sami Wagiaalla 2005-10-18 11:11:19 UTC
GTK_DATA_PATH=/usr GTK_EXE_PATH=/usr did not work for me.

But this did :

Comment 4 Igor Foox 2005-10-25 12:29:21 UTC
After some more messing around I found out that GTK_DATA_PREFIX is defined in
gtk/Makefile.am, so we can stick a definition in there. However, GTK_EXE_PREFIX
is not defined anywhere at compile time, and is only checked for at runtime.
However both places where GTK_EXE_PREFIX is checked for check to see if
GTK_LIBDIR is defined in case GTK_EXE_PREFIX is not. GTK_LIBDIR is also defined
in gtk/Makefile.am. Setting these two variables to '/usr' and '/usr/lib'
repsectively  solves the theme problem. 
However it seems to introduce another problem. When GTK_DATA_PREFIX is set in
the Makefile to /usr and GTK_EXE_PREFIX is defined on the command line OR
GKT_LIBDIR is also defined in the Makefile, frysk crashes when trying to run it
over ssh on a computer to which one is not logged in graphically. This is a
weird, obscure behaviour that doesn't seem to happen with other programs (non
Java-Gnome, I haven't had a small Java-Gnome program to test on). I'll try to
get that ironed out before updating packages.
Comment 5 Igor Foox 2005-10-26 15:23:49 UTC
It seems that even if the packages are build with GTK_DATA_PREFIX set to /usr
and GTK_LIBDIR set to /usr/lib, the running-over-ssh bug can be avoided by
running the command with GTK_EXE_PREFIX=/opt/frysk.

I'm going to rebuild the frysk-gtk2 package with this patch, and leave it like
that for the time being, since more urgent things need to be adderssed. In FC5
this problem will be gone since the packages will all be in the standard places.
This will be a problem for RHEL4 U3, but we might be able to circumvent it by
sticking some symlinks in the /opt/frysk tree. This will need to be investigated
when the time comes for building RHEL4 U3 packages.
Comment 6 Igor Foox 2005-10-26 17:23:21 UTC
Comment 7 Igor Foox 2005-10-26 17:25:09 UTC
Whoops, wrong button, reassigning.
Comment 8 Igor Foox 2005-10-26 17:25:55 UTC
And closing.