pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: Background colour in 0.14.2


From: Duncan
Subject: [Pan-users] Re: Background colour in 0.14.2
Date: Sun, 11 Feb 2007 21:25:38 +0000 (UTC)
User-agent: pan 0.123 (El Nuevo Barretto)

Maurice Batey <address@hidden> posted
address@hidden, excerpted below, on  Sun, 11 Feb
2007 18:14:10 +0000:

> On Friday 09 February 2007 23:32, Duncan wrote:
> 
>> There's an environmental variable that you may need to set (and export) as
>> well, to tell pan where to look for its gtk config.  
>> export GTK2_RC_Files="path1:path2:path3"
>>
>> Here, the paths are
>> /etc/gtk-2.0/gtkrc
>> $HOME/.gtkrc-2.0
>> $HOME/$KDE_CONFIG_DIR/share/config/gtkrc-2.0
> 
> Not familiar with such commands yet, but would like to try.
> 
> Just a few Q's:

Yeah, it's tough knowing at what level to make the reply, sometimes.  I
normally aim somewhere in the middle, figuring those who need more can
ask, while those who need less can skip over what they already know.

>  (1) Although my 'export' shows the $HOME variable, there's no sign of 
> $KDE_CONFIG_DIR. Where is that to be found/ascertained?

That's a "virtual" variable.  The idea is to replace it with whatever it
happens to be on your system.  The default (for users) is I believe ~/.kde
or ~/.kde3 or ~/.kde3.5 (or 3.whatever).  I believe the sources as shipped
from KDE will try each, probably from the most specific (.kde3.5) to the
least specific (just .kde).  However, various distributions might change
that, and users can as well, with symlinking if nothing else.

Complicating things here is that I've long since remodeled things into my
own idea of organization.  We're talking back around 2.x before even 3.0. 
I've various symlinks as appropriate but where current KDE looks by
default I don't know, because all three of those locations mentioned above
are symlinks in my home dir, to a non-hidden (no leading dot) ~/kde3.5
dir, because I like it out where I can easily see and modify it if
necessary, without having to turn on view hidden files.  I've no idea
which one is actually /used/ in most cases, tho a quick "strace
-eopen <command>" will give me an often /very/ long list of all the files
a specific command tries to open and with a bit of grepping I can quickly
see from there what kde location that specific command is finding them in.

So anyway, given the idea of shell variables, it's fairly common for *ix
folks to use "virtual" variables, even in non-computer references.  An
example I've seen several times is a reference to $deity, which of course
could be Allah/Yahweh/Jehovah/God/Jesus/etc. or even (in some contexts)
money/drugs/whatever.  It's a simple way of denoting "replace as
appropriate in your case".

> (2) Not seen the construct "path1:path2:path3" in export. Is the command
> to be executed here e.g.:
>    export GTK2_RC_Files="/etc/gtk-2.0/gtkrc:$HOME/.gtkrc-2.0:$HOME etc....  ?

Yes.

I suppose had I been consistent I would have written
"$path1:$path2:$path3". =8^)

> (In my Madriva setup, 'path1' looks as though it 
> is "$HOME/.kde/share/config/gtkrc/gtkrc-2.0", presumably not (as I also see)
> "/etc/gimp/2.0/gtkrc" - the only other occurrence of "gtkrc" I could find.

Path1 looks pretty accurate, as you should now be able to figure out,
given the above explanations for my previously unexplained shortcuts. 
Fast learner! =8^)  That'll be the location of the KDE's color export
file.  Open it in a text editor if you are interested in seeing exactly
what the color config KDE exports looks like.

The way it works, however, is that the settings from multiple files are
combined, such that each individual file need only define the aspects of
interest to it.  KDE's file of course will therefore define general colors
and a few other general style settings, since that's its purpose, to apply
those settings to GTK apps as well as KDE apps (if the checkmark is
checked).  

However, you may have other files that define other gtk aspects.  It's
possible to define the fonts and colors not only in general but for each
state (four states possible, normal, hilited, disabled, another one I
forgot) of each individual widget, so a commandbutton and a scrollbar and
a radiobutton will each have different settings, again, for each of the
four different states. As an example, for various reasons I'll skip
detailing here, the KDE color scheme didn't transfer correctly for the
GTK tooltips widget and I ended up with unreadable white tooltips on a
light yellow background!  After some research and experimentation, I
figured out which settings I needed to switch (just) the tooltip text to
black, and have that in one of the other files listed in the paths above,
making it readable again.  GTK combines the settings from all the files
listed, including both the KDE colors export file and the one containing
my tooltips touchup, to make the config it uses.

So basically what I'm saying is that it's possible the gimp file is also
used and the settings combined, if both paths (colon delimited) are
exported in the same GTK2_RC_FILES variable at the same time.

Note that if it's the same variable but set two different times, and
there's no self-referencing part (as in
GTK2_RC_FILES="$GTK2_RC_FILES:newpath), the second will erase the first. 
Maybe THAT'S your problem?

> (3) Presumably the 'export' command has to be executed prior to each call of 
> Pan (or once per bootup)?

That depends. =8^)

The true situation is rather complex, but to simplify things somewhat,
there are normally three places such a thing could be set (1) in the
system environment, set for (most) apps that run on the entire system, no
matter which user they run as, (2) in your user environment, set for
(most) apps that run as you, and (3) in an individual script or for one
application, set for only it.

At the system level, you likely have files such as /etc/bashrc and
/etc/profile.  These contain settings that apply to the entire system. 
(Part of the complexity is that profile is normally only run for login
shells, while bashrc is only run for interactive shells, but some
distributions simply have one call the other... and then there are other
files run under certain conditions... and how you start X affects
what's run if you run it from X... and some distributions change things
up a bit... you can see why I didn't want to try to explain it /all/.) Of
course, these files often reference /other/ files or even directories with
multiple files, each with settings specific to one thing.

At your user level, you likely have (normally hidden, again, because they
have a leading dot) ~/.bashrc and ~/.profile, the corresponding files that
run only for your user.

At the individual script or command level, anything you can type in a
terminal window (konsole or xterm or whatever) to run from there, you can
also create a script to do, and then just run the script.  Thus, while
experimenting, you can simply open your terminal window and type
in export <whatever....> as one command, perhaps do some other stuff, and
then run pan.  You should be able to export GTK2_RC_FILES once per
terminal session, then run pan from that terminal session and quit it and
run it again, without exporting further.  However, that export /only/
applies to that terminal session, so if you open another, it won't have
the same settings, and as soon as you close that session, you lose the
settings as well and have to do the same export the next time.

When you are satisfied you have the export doing what you want, you can
create a simple script something like the following:

--- begin script example ---
#!/bin/bash
# says it's a bash script, # starts a comment, by the way

# export our gtkrc settings
# only include :path2 if you have a second file to add
# and substitute as necessary
export GTK2_RC_FILES="~/.kde/share/config/gtkrc/gtkrc-2.0:path2"

# now run pan
pan

--- end script example ---

Of course, if you take out all those comments, it's just two commands, but
it could be more.

Save the file to someplace like ~/bin/pan-starter.  Change the
permissions, setting it executable for your user (chmod u+x
~/bin/pan-starter, or do it in konqueror or whatever).  Now, you can run
pan-starter and it will do the export and start pan.

If you were starting pan from a kmenu entry or the like and you want to,
you can edit that entry to point to pan-starter instead, or create a new
entry, as desired.

> I don't understand why the 'export' was not neeeded when running the
> same  Pan under SuSE, but may be elsewhere, unless there is a mismatch
> between the SuSE RPM Pan code and Mandriva.

Each distribution's rpms will be customized a bit, some more, some less,
to that specific distribution.  It's likely that if you took my suggestion
and used rpmfind or simply googled for an appropriate version Mandriva
rpm, it would work as you are used to, since it's setup to work with
Mandriva.  One package is likely looking in an entirely different place
for the config than the other, by default if GTK2_RC_FILES isn't set.  If
the file isn't where it's looking...

It may also depend on how you start pan. Here on Gentoo, if I start pan
directly from the command line (konsole, in my case), it won't use my KDE
customized colors.  If I start it from the menu entry or the KDE run
dialog, it will.  I didn't like that and I had a couple other things I
wanted to do with the launch script too, so I created a script with
several commands in it, that set things up the way I wanted before it
launched pan itself.  I then set the kmenu entry to point to my script,
and start my script instead of pan itself from the command line, so it
doesn't matter how I start it anymore (as long as it's with the script),
it always comes up the same, because the script sets things up the way I
want them before starting pan.

BTW, a bit more about "export".  export is a bash (borne again shell, the
most popular command shell on Linux) builtin command. It simply tells bash
to export the listed environmental variables, which may have been set
previously or may be set in the export command itself, as here.  If you
don't export a variable, bash keeps it to itself.  If you do, it passes it
on it its children, like pan.  This allows you to use some variables for
scripting purposes inside bash itself, while you export others to be used
by child applications (like pan) as necessary.  To get an idea of what
other sorts of commands are bash builtins, type "help" at the bash prompt.
To get a bit more info about export, type "help export".  Of course,
there's a whole /bunch/ of info in the bash manpage (man bash), but
that's /way/ too much info and too detailed for beginners, and tends to be
a bit overwhelming even later.  There are good bash tutorials available
for the googling if you find it interesting and would like to know more
about it.  Or do what I did.  Buy Running Linux and Linux in a Nutshell,
read them (they are WELL worth it many times over!!) and go from there.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]