Maurice Batey <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
