Re: User installation
Hi, On Sat, Apr 01, 2000 at 05:29:49AM +0100, Nick Lamb wrote: * Is the end-user installation stuff broken, or is it just me? On my system, cleaning out all old Gimp installs, installing latest CVS and then trying to install Gimp as a new user (ie to create .gimp-1.1 and all the rest) does not work. This seems to result from the changes to the system data directory... the error is approximately... /usr/local/share/gimp/user_install [or something] does not exist. It is just you! Doing a clean installation does not only involve removing the installed stuff. You should clean your source directory too and rerun autogen.sh. The problem you see is caused by the fact that you did not correctly rebuild llibgimp/gimpenv.o. FLAME The feature freeze has also thawed again. I can't tell if the new trouble I'm seeing is caused by changes to the installer in /app/ but I shouldn't have to, because IT SHOULD NOT BE BEING REPLACED DURING THE FREEZE. /FLAME I will try to ignore the stupidity and ignorance you are expressing... I apologise for shouting, but AFAICT again all the existing bugs or misfeatures of the old dialog are retained, but now we have new bugs and a prettier interface, pardon me if I'm not impressed, but right now I can't even install Gimp :( At least bug #7307 was fixed by our changes. The problem that people do not adjust important parameters like the tile_cache_size was discussed several times and each time the only reasonable solution was to ask for it during the user installation. I have announced at least twice that I'm planning to change it and noone objected. Please, think about what you have said. We have put a lot of work into this and tried to test everything. You should also not forget that Mitch and me are the ones who fix the bugs, not you! Salut, Sven
Re: User installation
On Sat, Apr 01, 2000 at 12:09:11PM +0200, Sven Neumann wrote: Hi, On Sat, Apr 01, 2000 at 05:29:49AM +0100, Nick Lamb wrote: * Is the end-user installation stuff broken, or is it just me? On my system, cleaning out all old Gimp installs, installing latest CVS and then trying to install Gimp as a new user (ie to create .gimp-1.1 and all the rest) does not work. This seems to result from the changes to the system data directory... the error is approximately... /usr/local/share/gimp/user_install [or something] does not exist. It is just you! Doing a clean installation does not only involve removing the installed stuff. You should clean your source directory too and rerun autogen.sh. The problem you see is caused by the fact that you did not correctly rebuild llibgimp/gimpenv.o. Automake's dep tracking doesn't get 100% of cases. The datadir moved into a versioned directory to facilitate version coexistance. It's controlled by a -D on the compile line, so make doesn't really see it. -Yosh
Re: single-instance gimp? (using gnome)
On Fri, Mar 31, 2000 at 11:44:58AM +0200, Raphael Quinet [EMAIL PROTECTED] wrote: applications. Well, over the last year I discovered that it was not the case and that it was possible to install some GNOME libraries It is _no longer_ the case, fortunately ;) would avoid the duplication of efforts. For example, using CORBA to allow the GIMP to run only in a single instance would be nice. It would be braindamaged and broken behaviour. This is totally un-unix behaviour, and I can't remember any application doing such a dumb thing (except on windows). If gnome does it (uh-oh) it totally lost. What's next, shared libraries with shared data-segments? Oh, by the way, I think that the "single instance" feature should be an option. Yes, the normal non-broken behaviour must be the default. Having a switch (like netscape) to remote-control the gimp is a nice feature, but that's a very different concept to singleton-apps. running side-by-side on the same machine (but not often, so the default should probably be to have only a single instance). NO, NOT THE BROKEN WINDOWS WAY AGAN! ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Gimp Wishes (efficient trivial wishes)
On Thu, Mar 30, 2000 at 08:49:16PM +0200, Stanislav Brabec [EMAIL PROTECTED] wrote: -- Other problem is about translating some splitted messages to many languages (gender problems etc.) Example with Czech: Free = Volny (Selection) Free = Volna (Curve) Yeha, that's a long-known gettext limitation. In Apache::PApp, I will soon support language-tagging and id-tagging. Sinc eit's perl, I'll just append a zero byte and the neecessary information, but I am really looking for a gettext replacement (maybe just a dbm-file(?)). The short-term solution with gettext is indeed adding prefixes (nonsense ones like "#1 Free" or "Free ~curve", "Free ~selection" and then use a en_US translation table to map these to english. This would be similar to the xopen way, but for long messages (which are very probably unique), you could "just" use the message as key, and for short messages (like "Free"), you would just add a suffix or some other tag, since the chance of collisions is very high. That could be done before 1.2, with added stress for the translators, but... -- Jpeg: There is a problem to guess compression and some save options from jpeg data. So we load image compressed in 98% quality, and consequent Save will default to 75% quality. I don't think this really is so much of a problem. Saving a jpeg in the same quality as it was originally saved will do no good to your quality. The only thinvg it will ensure is that the file-size will be similar. Tell it the programmers; they will have to add "prifixes" to make the strings different; e.g.: I think using optional(!) tags (which will be more verbose) will be even more useful: Not much added strain on the programmer, not much strain on translators (we need one more translator for the en mapping). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: User installation
On Sat, Apr 01, 2000 at 02:58:30AM -0800, Manish Singh wrote: Automake's dep tracking doesn't get 100% of cases. The datadir moved into a versioned directory to facilitate version coexistance. It's controlled by a -D on the compile line, so make doesn't really see it. make distclean [doesn't/ didn't for me] work, nor did clobbering everything in sight, but a fresh checkout worked finally. YMMV. BTW in case there's any doubt, I do *like* the new installer, whatever the color scheme might say about us, I just want a stable Gimp soon. Nick.
Re: Gimp Wishes (efficient trivial wishes)
On Sat, Apr 01, 2000 at 07:46:03PM +0200, Marc Lehmann wrote: That could be done before 1.2, with added stress for the translators, but... -- Jpeg: There is a problem to guess compression and some save options from jpeg data. So we load image compressed in 98% quality, and consequent Save will default to 75% quality. I don't think this really is so much of a problem. Saving a jpeg in the same quality as it was originally saved will do no good to your quality. The only thinvg it will ensure is that the file-size will be similar. Saving at a higher quality certainly won't do any good to your quality either. The only thing you will notice, is that the file size goes UP... If you look in the source code for the JPEG plugin, you will see that there is no easy way of deducting what quality the file as saved in. /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
