Re: file_gih_save
Marc Lehmann writes: > file_gih_save in current cvs saves ALL images with the following header > (or similar): > H Bare Bush.gih:0 ncells:0 cellwidth:0 cellheight:0 step:0 dim:0 cols:0 > rows:0 placement:(null) > > and no image information at all. (file_gih_save does not allow you to > specify any parameters except spacing, btw). Umm, I cannot reproduce this. To me, .gih saving looks like it always has. (I checked it on Windows, with GTK+ 1.3.0.) --tml
Re: Gimp + Solaris + i18n
[EMAIL PROTECTED] (Raphael Quinet) writes: > On Fri, 10 Nov 2000, David Monniaux <[EMAIL PROTECTED]> wrote: > > I compiled Gimp under Solaris with --with-included-gettext. Trying to run > > it with LANG=fr... does not yield anything translated. Nevertheless, Gimp > > seems to load the translation file (seen in strace). > > > > Has anyone else noticed this behavior, or is it my setup? > > I compiled Gimp 1.1.29 under Solaris 2.6 without the included gettext > (I have GNU gettext 0.10.35 installed in my path, and "configure" is > happy with it). I had never tried to set LANG=fr under Solaris, so I > just tried to see if I had any problems. Well, I got the answer in > less than 2 seconds... > > csh> setenv LANG fr > csh> gimp Ehm, this is AFAIK not a valid locale setting. LC_ALL=fr_FR gimp or LC_MESSAGES=fr_FR gimp works fine for me. OTOH it took me days to get the beast running on Solaris and I don't know if my working locale stuff comes from some mystic environment variables that were set when compiling gtk+ and gimp. (there are lots of mystic variables set in the university's heterogeneous network) ;) Another important point to mention is that GIMP wants to be compiled with the same version of gettext that GTK was compiled with, which should not be solaris gettext (didn't work for me) but GNU gettext. So compiling GTK with some GNU gettext lying around (not linking against it because that's the job of the app which links against GTK) _and_ GIMP with --with-included-gettext should do the job because then GTK will use the GNU gettext that ships with the GIMP tarball. bye, --Mitch
Re: test program for waitpid/sigchld problems
On Wed, 08 Nov 2000, Michael Natterer <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Raphael Quinet) writes: > > Maybe we should all do our "mea culpa" and test a bit more seriously > > especially on non-Linux platforms, now that 1.2 is just around the > > corner. > > Nope, it's just me with the "mea culpa" thing. > > The > > gimp_signal_private (SIGCHLD, gimp_plugin_sigchld_handler, SA_RESTART); > > call is just to restart system calls interrupted by SIGCHLD. > The signal handler does nothing more than removing the zombie. > > But as all plug-ins which fork() also want to fetch waitpid()'s > return values K I know that you added that "feature" to the code, but it was working well under Linux at that time, so everything looked OK for you. The "mea culpa" should be for all of us who saw the problem on the non-Linux systems and never reported it. Five plug-ins (including "gz" and "screenshot", which are used quite often) were broken for six months (!) on non-Linux platforms and nobody reported the problem to the bug database. Some problems with the screenshot plug-in were reported on this list during the summer, but that's all. As I wrote, I am partially to blame because I knew about the problem for at least two of the plug-ins mentioned above. But the fact that such a serious bug was ignored for such a long time does not make me feel confortable about the testing on non-Linux platforms. And the list of systems on which the Gimp was broken is larger than I thought. Here is the list of systems on which waitpid() could not return any status for the child processes, thanks to Ludovic Poitou, Jarda Benkovsky, David Brownlee, David Edelsohn, Mike Turk, Tomas Ogren, Jaromír Dolecek, Ignatios Souvatzis, Martin Husemann and Christian Biache who sent me their results by e-mail: - Solaris 2.5, 2.6, 8 - SunOS 4.1.1, 4.1.4 - OSF1 V4.0 - HP-UX 10.20, 11.00 - AIX 3.4, 4.2, 4.3.2, 4.3.3 - FreeBSD 3.4 - NetBSD 1.4.1, 1.4.2, 1.5_BETA (m68k), 1.5_BETA2 (arm32) - LynxOS 2.5.0 The only systems that are reported to work are various versions of Linux 2.2.x and IRIX (5.3 and 6.5). Windows was not really affected by this problem, because the code is not the same on this platform. Looking at the list of platforms that were partially broken for several months does not make me feel good, that's why I sent the message quoted above. Thanks to all who reported the results of the test program. -Raphael
Re: Gimp + Solaris + i18n
On Fri, 10 Nov 2000, Raphael Quinet wrote: > I compiled Gimp 1.1.29 under Solaris 2.6 without the included gettext > (I have GNU gettext 0.10.35 installed in my path, and "configure" is I was referring to CVS Gimp _with_ the included gettext. 1.1.29 with the Solaris gettext runs into memory corruption and segfaults when building the list of file loading procedures. Try 1.1.29 with the included gettext. It should work fine. David Monniauxhttp://www.di.ens.fr/~monniaux Laboratoire d'informatique de l'École Normale Supérieure, Paris, France
Re: revert/undo/question?
[EMAIL PROTECTED] (2000-11-10 at 1243.23 +0100): > > > However exactly the same happened to me, which meant loss of half an hour > > > of work. I'll add a warning dialog just as the "chanes were made to %s. > > > really close?" one. > > Yes, it should ask if undoable "Reverting 'imagename' will lose all Sorry, I meant "non undoable". > > changes including undo stack" "Revert" "Cancel" (two lines + two > > buttons, the important part is the buttons labels). > > This is clearly a cool idea but it's also clearly a fat feature :( [...] > Maybe a good idea for 1.3... The undoable (without question then ;] ) revert would be cool indeed. Until it can be coded, I would like it to ask (that is easy coding, no?) and the docs show that is not undoable in this version, but maybe in next (aka check next version with a dummy image), and that opening another instance of the same image is a good solution too (cos you can save the first try or the second). GSR
active layers (was: Onion Skinning for GIMP/GAP)
On Fri, 10 Nov 2000, "wolfgang hofer" <[EMAIL PROTECTED]> wrote:
> For painting Animations it can be useful
> to see the previous or next frame(s)
> more or less transparent.
>
> Here are 2 Variants A) and B) how to implement such features in GIMP.
[...]
> B) OnionLayer is a new 'special' layertype,
>known to the GIMP core app.
>GIMP offers a PDB Interface
>
>- gimp_image_add_onionlayer(image_id, src_image_id,
>OnionPosition,
>OnionRevers,
>OnionOpacity,
>OnionMode)
>
>(do we need a special PDB interface for remove ?)
>
>GIMP should display the OnionLayer like any other Layer,
>but set to ReadOnly. (if possible)
>
>The Display of image_id colud be updated on
>every change of src_image_id
>as long as src_image_id is valid.
[...]
This looks very similar to the concept of "active layers" or "shadow
layers" that I explained some time ago on this list. Other proposals
have been discussed as well, using different or similar names ("action
layers", "plug-in layers") and doing different or similar things, so
it is a bit difficult to remember what each proposal is about (because
the similar names are confusing but the underlying concepts are
sometimes different). The concept that I am refering to is the
following:
- You could add an "active layer" to an image. This layer takes as
parameters the name of a PDB function, plus some other parameters
such as references to other layers or layer groups (the layer groups
are planned for 2.0, I think).
- The references to other layers can be relative (N layers above or
below the current one) or absolute (layer number X in the stack).
- The "active layer" cannot be edited by the user.
- The layer shown or hidden, its opacity can be changed like a normal
layer, and it can be moved up or down in the stack (as long as the
contstraints of the relative references are respected).
- When you create the layer or whenever one of the referenced layers
changes, the PDB function associated with the "active layer" is run
(taking its input from the other layers) and the result is stored in
the tiles of the "active layer".
- It is possible to disable the automatic updating of the "active
layer" and to switch to manual updates for performance reasons.
Originally, I was thinking about using layer references inside the
current image only, because then you can save all parameters of the
active layer into the XCF file and they would have no dependencies on
other files.
But your proposal for "onion layers" looks like a natural extension of
this concept, if you allow an "active layer" to reference some layers
in another image. These layers with external dependencies could not
be saved in the XCF file (or we would have to come up with a very
clever mechanism for maintaining the dependencies between images) but
that would be enough for what you want to do with them. In this case,
the PDB function would be a simple copy of the referenced layer.
There are some plans to implement something like this for 2.0, so we
could start thinking about the details as soon as 1.2 is out.
-Raphael
擁抱高薪 懷抱夢想
±zÃh¤~¤£¹J¶Ü?
§A¤ß¤¤¦³¹Ú¶Ü?
³\§A¤@Ó¾Ö¦³°ªÁ~ªº¾÷·|
³\§A¤@Ó¹ê²{¹Ú·Qªº¾÷·|
Re: Gimp + Solaris + i18n
On Fri, 10 Nov 2000, David Monniaux <[EMAIL PROTECTED]> wrote: > I compiled Gimp under Solaris with --with-included-gettext. Trying to run > it with LANG=fr... does not yield anything translated. Nevertheless, Gimp > seems to load the translation file (seen in strace). > > Has anyone else noticed this behavior, or is it my setup? I compiled Gimp 1.1.29 under Solaris 2.6 without the included gettext (I have GNU gettext 0.10.35 installed in my path, and "configure" is happy with it). I had never tried to set LANG=fr under Solaris, so I just tried to see if I had any problems. Well, I got the answer in less than 2 seconds... csh> setenv LANG fr csh> gimp gimp: fatal error: Segmentation Fault gimp (pid:15480): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s #0 0xef560cb8 in g_on_error_stack_trace (prg_name=0xec24 "gimp") #1 0xef560ba8 in g_on_error_query (prg_name=0xec24 "gimp") at gerror.c:133 #2 0x801d4 in gimp_fatal_error (fmt=0xef30e916 "Segmentation Fault") #3 0xdf2a4 in gimp_sigfatal_handler (sig_num=11) at main.c:464 #4 #5 0xef29c2c4 in key_2_text () #6 0xef29c188 in dcgettext_u () #7 0xef29ba0c in gettext () #8 0x343f8 in make_initialization_status_window () at app_procs.c:373 #9 0x34970 in app_init () at app_procs.c:502 #10 0x33c40 in gimp_init (gimp_argc=0, gimp_argv=0xeb20) at app_procs.c:138 #11 0xdf238 in init () at main.c:430 #12 0x140228 in user_install_verify (user_install_callback=0xdf220 ) #13 0xdf1fc in main (argc=1, argv=0xeb1c) at main.c:396 It crashed before opening any windows. I tried "truss" to see the list of system calls that are done before crashing, and I see that it crashes soon after opening and mmap'ing ".../lib/locale/fr/LC_MESSAGES/gimp.mo". So it does open the file, but it crashes immediately afterwards. -Raphael
Gimp + Solaris + i18n
I compiled Gimp under Solaris with --with-included-gettext. Trying to run it with LANG=fr... does not yield anything translated. Nevertheless, Gimp seems to load the translation file (seen in strace). Has anyone else noticed this behavior, or is it my setup? David Monniauxhttp://www.di.ens.fr/~monniaux Laboratoire d'informatique de l'École Normale Supérieure, Paris, France
Re: revert/undo/question?
"Guillermo S. Romero / Familia Romero" <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (2000-11-09 at 1830.06 +0100): > > However exactly the same happened to me, which meant loss of half an hour > > of work. I'll add a warning dialog just as the "chanes were made to %s. > > really close?" one. > > Yes, it should ask if undoable "Reverting 'imagename' will lose all > changes including undo stack" "Revert" "Cancel" (two lines + two > buttons, the important part is the buttons labels). This is clearly a cool idea but it's also clearly a fat feature :( It would mean to convert one image into another and pushing all operations needed into a single undo group. Sounds a bit too much like voodoo to be implemented cleanly ;) Maybe a good idea for 1.3... bye, --Mitch
