Re: running ldconfig
On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: 1. libtool should make sure that the libraries are found anyway (unless moved). ld.so.cache is only that, a cache Well, then gimp.m4 does the wrong thing, since after I install a new version of the Gimp I can't use gimp.m4 within autoconf to test for Ah, now I see the problem. Hmm... I guess shared libraries are still largely unexplored for the many ways to do it "right" :( the presence of the Gimp. It's considerably more than "just a cache"; it controls how runtime dynamic linking takes place. On _some_ systems, like linux. Many systems do not even have the notion of ldconfig. 2. only root can run ldconfig (without errors, that is) And make install normally installs software into areas that can only be installed into by root. It is an absolute must, however, that even normal users can install the gimp (remember the long thread on this subject?) 3. not all systems have ldconfig or the same concept of shared libraries as linux (elf or not...) Like I said: this should be run as part of the installation procedure "on Elf-based systems, at any rate". But "Elf" and "ldconfig" are not too related to each other. However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
On Sat, 11 Mar 2000, Marc Lehmann [EMAIL PROTECTED] wrote: I just wanted to note that the suggestion of Raphael is based on assumptions that were either never true, or were true many months ago. Before all of you second his suggestions I would really appreciate it if people looked at the current situation. (I mean: think first!) Marc, it is unfortunate that you are replying in a defensive mode as if my message was a personal attack, because this is not the case. I tried to be as objective as possible and I took the time to check what I was talking about. Maybe I over-argumented my suggestions, but this is because a similar proposal that I sent several months ago was rejected because you said that all my claims were FUD. At that time, some of my assumptions were wrong and some other were right but my suggestions were ignored as a whole. Once bitten, twice shy. So I was more careful this time. I recently installed a new hard disk in my PC, so I decided to check everything on a "clean" system. I installed SuSE 6.3 (including perl, but not Gtk-Perl) and I downloaded, compiled and installed the latest versions of glib, gtk+ and the Gimp. First, I installed these packages with the versions 1.2.6, 1.2.6 and 1.1.17, respectively. Last week, I installed the versions 1.2.7, 1.2.7 and 1.1.18, respectively. So the current situation is: if you do not install the required Perl modules (especially Gtk.pm), most of the scripts do not produce any useful results. Besides, even if they would work, the pop-up messages warning the user about the missing module are not very friendly and lead the user into thinking that the Gimp is half-broken because the menus are cluttered with entries that generate warnings. Disabling all perl-plug-ins because somebody didn't want to check the facts is, for me, a very big decision that should not be made lightly. I agree, but this is _not_ what happened. I suggested to skip the installation of most Perl scripts if their prerequisites were not satisfied. The fact is that most of them do not work without Gtk-Perl and even if some of them would work, running only with the default arguments is not very useful. Running with the default parameters means that the user has no way to change how the script works (of course), has no way to guess what the script could be doing by looking at its parameters and cannot use the help to get additional information (the latter is annoying for newcomers). No script will show up in the menu if it depends on something not installed. For PDL, the scripts won't be installed in the first place. This is only partially true. Most of the scripts depend on Gtk. Currently they do not require it (i.e. it is optional) because they are supposed to be able to run without it by using only the default values, but this does not really work: all of them generate warnings, most of them crash, and their usability is limited. If you prefer, you can re-phrase my suggestion in the following way: all scripts that can use Gtk should _require_ it and should not be installed if Gtk is not present during the "configure" step. The scripts that have no user interface and no dependencies on other modules can be installed if they are useful. I sincerely hope that you will not consider this message as a personal attack. I am not trying to blame you for anything (I repeat that the Perl scripts do work fine on a system that has all required modules). I am simply reporting the fact that if you install the current version of the Gimp on a clean system that has Perl without the optional modules, the user will get a bad impression because many entries in the menus will either not work at all or will not produce useful results. So I am suggesting a solution, which is to disable the installation of anything that would appear to the user as being broken. This does not necessarily mean to disable everything. 1. If PDL is missing, no scripts depending on it will be installed. I don't see why all the majority of scripts not using PDL should also be disabled. OK, then you could just skip the installation of those scripts, and install those that have all their dependencies satisfied. 4. Gtk is a major problem. I feel that an effect running with (sane) default arguments is better then no script at all. It costs just the same mouse-clicks to use these scripts. If people disagree then this is the place to discuss it. That was my main argument. If Gtk is missing, the user will get many warnings (one pop-up every time they try to use a Perl script) which gives the impression that the Gimp is broken. After the warning, most of the scripts crash anyway. You could of course try to fix these crashes, because some of them look like real bugs in the scripts, but my message was not intended as a bug report... Even if the bugs are fixed, I think that it would be better to skip the installation of those scripts if they cannot have a user interface (besides
Re: running ldconfig
On Sun, 12 Mar 2000, Marc Lehmann [EMAIL PROTECTED] wrote: On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: 1. libtool should make sure that the libraries are found anyway (unless moved). ld.so.cache is only that, a cache Well, then gimp.m4 does the wrong thing, since after I install a new version of the Gimp I can't use gimp.m4 within autoconf to test for Ah, now I see the problem. Hmm... I guess shared libraries are still largely unexplored for the many ways to do it "right" :( Hmmm... Strange, because it works for me. Does that happen with the latest version of the Gimp, or with a version older than 1.1.17? Like I said: this should be run as part of the installation procedure "on Elf-based systems, at any rate". But "Elf" and "ldconfig" are not too related to each other. Yup! I have an elf-based Solaris system that does not know anything about ldconfig... :-) However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). First, I would like to be sure that it happens with the latest version of the Gimp. I just checked the source for 1.1.17 and 1.1.18, and both of them are distributed with a version of libtool that includes the following on Linux systems: finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir' This is run immediately after installing each library in $libdir. So at least the recent versions of the Gimp _do_ run ldconfig as part of "make install" and you should not have any problems. On the other hand, maybe you are having a problem with ld.so.conf, not with ld.so.cache. The latter is updated by ldconfig, but the former can only be modified by hand. I think that it would be wrong for a tool to attempt to modify ld.so.conf automatically, because the order of the directories is important and some modifications could break the whole system. -Raphael
Re: running ldconfig
Date: Sun, 12 Mar 2000 21:44:49 +0100 From: Marc Lehmann [EMAIL PROTECTED] On Wed, Mar 08, 2000 at 07:23:49AM -0500, Robert L Krawitz [EMAIL PROTECTED] wrote: the presence of the Gimp. It's considerably more than "just a cache"; it controls how runtime dynamic linking takes place. On _some_ systems, like linux. Many systems do not even have the notion of ldconfig. That's true, but not particularly germane. Where it does exist, it's a standard part of installation: ldconfig should normally be run by the super-user as it may require write permission on some root owned directo- ries and files. It is normally run automatically at bootup, from /etc/rc, or manually whenever new DLL's are installed. I interpret "manually" as "whatever does the installation", i. e. make install. It is an absolute must, however, that even normal users can install the gimp (remember the long thread on this subject?) Agreed, but that doesn't mean that make install shouldn't attempt to run ldconfig. If users do their own installation and have to set LD_LIBRARY_PATH that's their lookout. System installations should not be subject to this. However, the solution is easy: somebody who wants it should write the necessary autoconf and makefile magic to detect wether ldconfig exists and (at installation time) wether it should be run (uid == 0 is a good hint). The hard part is figuring out where ldconfig lives -- on my Linux box it's in /sbin; it doubtless lives elsewhere on other platforms. If the makefile just contains -$(LDCONFIG) it will simply print out a warning message and continue if it doesn't have permission. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
i18n patch
remove blurb,help _() www.geocities.com/art_pl/gimp/gimp-art-003-1.patch.gz po files: www.geocities.com/art_pl/gimp/gimp-art-003-0.patch.gz __ ___ |/ _, | __ | | __ \ |_ _| -- Artur Polaczynski -- | __ | | _/| | -- mail: [ [EMAIL PROTECTED] ]--- |_| |_| |_|\_\|_| -- www: ---[ www.geocities.com/art_pl/ ]---
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Raphael wrote on Mon, 13 Mär 2000: As an end-user, I prefer a stable application that may have less features than another that has more features but that crashes or complains that my system is not correctly configured. Hey, this is, why the most of us don't use Windoze, I think ;-))) Back to the facts: currently, anyone installing the Gimp on a "normal" UNIX system (i.e. from any major Linux distribution, or Solaris, and so on, that has perl but not the optional modules from CPAN) gets a version of the Gimp in which a large number of options do not work. I consider that as a serious bug. If a user does not have the opportunity to download and install the Perl modules from CPAN (no Internet connection, no administrative rights, whatever) then the best workaround for the moment is "make uninstall ; configure --disable-perl ; make ; make install". This is not a good solution. Yes, this is really not a good solution!!! What about making an extra package with all perl-modules required to run Gimp with all powerfull features? Someone (not me, because I don't even understand what happens while perl installs some package:-(() can package all needed Perl packages, make a simple but nice configuration (only install those packages not present) and give any user (not only the perl wizards) the possibility to use the whole power of Gimp. Some addition to the ./configure could lead to a message "You don't seem to have some important perl packages installed. If you wish to use Gimp with all it's power, grab 'gimp-perl-packages.tar.gz' and install it. Then run configure again." And (don't take this seriously ;))) this can solve a lot of documenation updates! Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
GUI Bugs: Levels and Curves
Hello, I just tried to mimik some algorithm for enhancing the colors of an image taken by a digital camera (or a scanner, or ...) that was explained for photoshop (and works very well -- far better than the automatic). By trying this I found some things that have to be discussed (and maybe later reported as errors). But first I describe the algorithm. It is taken from an excerpt of a book about color correction: http://www.daton.de/wargalla/(german) auf dieser Seite gibt es einen Link zu "das BUCH" und dort diesen Algorithmus als Probekapitel 1. make the level of each channel (R, G, B -- _not_ RGB or value) spread from the beginning of the hills to their end (don't know the right english words) 2. take a color pick of some point that has to be gray (say: 123 / 115 / 139) 3. adjust the curves for each channel (again R, G, B, -- _not_ value) with only one aditional point, that all three values meet the middle one (123 in the example): R 123 - 123, G 115 - 123, B 139 - 123 Hope this was clear enough to be valuable. The problems that arise: - for levels and curves there are four channels R, G, B, value. Is the fourth one really "value" (from HSV) or is it the combination of the other three?? The latter one is called "RGB" in photoshop and I think this is clearer. - in curves it is not easy to discover what is the input (x or y) that is matched by the shown curve to the output. As someone a little bit familiar with maths, I can determine that x is input and y output but maybe it would be better to give these two terms directly (or are there problems with i18n strings in a picture?) - if the other two points are really bugs this one is not and though has to be delayed after 1.2: It would be very nice to enter the value for x (input) and y (output) numerical and not by carfully driving the mouse. Photoshop has (albeit since 5.0) two entrys that show up if a point from the curve is selected. Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
