Gimp at the Systems 99 in Munich

1999-10-11 Thread Simon Budig

Hi.

As you may have read at the Gimp News I am coordinating the
Gimp Booth at the Systems 1999 in Munich.

I need some people, who will be there and have some time left to
present the Gimp. So if you are interested, please mail me ASAP,
so I can get a ticket for you.

Further information: http://www.linux-magazin.de/systems/

---german---

Wie Du vielleicht mitbekommen hast, werde ich den Gimp-Stand
auf der Systems 1999 in Muenchen organisieren.

Ich brauche noch ein paar Leute, die dort sein werden und etwas Zeit
uebrig haben um Gimp zu praesentieren. Wenn Du Lust hast, mail mir
so schnell wie moeglich, damit ich noch ein Ausstellerticket
besorgen kann.

Weitere Informationen: http://www.linux-magazin.de/systems/

Bye,
Simon
-- 
  [EMAIL PROTECTED]   http://www.home.unix-ag.org/simon/



Re: swap files

1999-10-11 Thread Raphael Quinet

On Sun, 10 Oct 1999, Federico Mena Quintero [EMAIL PROTECTED] wrote:
 [quoting Jay Cox]
   If we unlink the swap file after opening it then we have no way of
   knowing how much space gimp is using for it's swap file.
 
 lseek() returns the offset to which you seeked, so lseek (swap_fd, 0,
 SEEK_END) will give you its size.

This is fine from within the Gimp.  But most of the time I want to
monitor the size of the swap file from a shell window, while the Gimp
is performing some memory- and CPU-intensive tasks on a large image.
If we unlink the file after opening it, then the file may not be
visible in a directory listing.  I suppose that this depends on the OS
and filesystem used.

On Mon, 11 Oct 1999, Marc Lehmann [EMAIL PROTECTED] wrote:
 a) unlink might not succeed on non-unix-systems. cure: ignore the error from
unlink and try to unlink it again after closing the file

This means in any case, we have to add some code that deletes the file
when a signal handler is called (close and unlink in case of a crash).
So if we have to do this in a signal handler anyway, why would we also
do it just after opening the file?

 b) if the swap file is on nfs (extremely bad idea anyway) it might
go away (physically) on the server when gimp does not access it for
extended periods (10 minutes).

In some cases, you do not have the choice.  On several machines that I
use at work, I have to put the swap file on NFS because all writable
partitions are mounted over NFS (except for /tmp but it is too small).

 However, any other solution (doing it in the signal handler) is extremely
 annyoing (leaves too many swap files around).

Are you sure about that?  I think that it is more likely that the Gimp
crashes and calls the signal handler than to have a power failure
(which has more serious effects than just leaving a swap file around).

 In any case, why not use tmpfile or a similar function to create it? that
 function will do exactly what is required and will work on all systems (as
 good as it can).

The problem with tmpfile() is that it is not as easy for the user to
predict or change the location of the swap file.  This function calls
tmpnam() which relies on TMPDIR for the location of the file.  But in
some cases, the user might want to store the huge Gimp swap file on a
(slow but large) NFS-mounted partition instead of a (fast but small)
local disk, while all other applications would keep their reasonably
small temporary files on a local /tmp disk.

It could still be possible to use tmpfile() as long as we clear or
override TMPDIR from inside the Gimp, but this is not a very elegant
solution.

I would prefer to have the file closed and unlinked in a signal
handler.  This is not a perfect solution (e.g. in case of power
failure), but it has more advantages than the other solutions (or at
least less disadvantages).

-Raphael



[patch] tearoff menus

1999-10-11 Thread SHIRASAKI Yasuhiro

Hi,

This is an easy fix to handle /*/tearoff1 menu item translation handling.
It may reduce translation mismatching error.

enjoy

--
SHIRASAKI Yasuhiro : Experimental Particle Physics, JLC Team
Graduate School of Science, TOHOKU University 980-8578 Japan.


--- app/menus.c.origTue Oct 12 00:35:24 1999
+++ app/menus.c Tue Oct 12 01:10:50 1999
@@ -63,12 +63,7 @@
 static gchar* G_GNUC_UNUSED dummyMenus[] =
 {
   N_("/File/MRU00 "),
-  N_("/File"),
   N_("/File/Dialogs"),
-  N_("/Image/Transforms"),
-  N_("/Layers"),
-  N_("/Tools"),
-  N_("/Dialogs"),
   N_("/View/Zoom"),
   N_("/Stack")
 };
@@ -1233,16 +1228,27 @@
   retval = gettext (path);
   if (!strcmp (path, retval))
 {
-  strcpy (menupath, "Image");
-  strncat (menupath, path, sizeof(menupath) - sizeof("Image"));
-  retval = dgettext ("gimp-std-plugins", menupath) + strlen ("Image");
-
-  if (!strcmp (path, retval))
-   {
- strcpy (menupath, "Toolbox");
- strncat (menupath, path, sizeof(menupath) - sizeof("Toolbox"));
- retval = dgettext ("gimp-std-plugins", menupath) + strlen ("Toolbox");
-   }
+  strcpy (menupath, path);
+  strncat (menupath, "/tearoff1", sizeof(menupath) - strlen(menupath) - 1);
+  retval = gettext(menupath);
+  if (strcmp (menupath, retval))
+{
+  strcpy(menupath, retval);
+  *(strrchr(menupath, '/')) = '\0';
+  return menupath;
+}
+  else
+{
+  strcpy (menupath, "Image");
+  strncat (menupath, path, sizeof(menupath) - sizeof("Image"));
+  retval = dgettext ("gimp-std-plugins", menupath) + strlen ("Image");
+  if (!strcmp (path, retval))
+{
+  strcpy (menupath, "Toolbox");
+  strncat (menupath, path, sizeof(menupath) - sizeof("Toolbox"));
+  retval = dgettext ("gimp-std-plugins", menupath) + strlen ("Toolbox");
+}
+}
 }
 
   return retval;



Re: swap files

1999-10-11 Thread Federico Mena Quintero

  I think this will just give you the LENGTH of the file? So, I don't
  know if it matters, but ISTR that Gimp uses files with holes, and
  therefore LENGTH != SIZE.

Oh, I didn't know this.

In any case, the program *does* know (or should) know the number of
tiles that it can have (tile cache size), the number of tiles in
memory (referenced tiles plus unswapped tiles), and number of tiles on
disk (swapped tiles).  So you really don't care much about the size of
the swapfile, since it can only get so big.

  Federico



Re: swap files

1999-10-11 Thread David Monniaux

On Mon, 11 Oct 1999, Marc Lehmann wrote:

 In any case, why not use tmpfile or a similar function to create it? that
 function will do exactly what is required and will work on all systems (as
 good as it can).

Under Linux at least, tmpfile() simply does an unlink() after opening the
file. :-)

The problem with tmpfile(), as it has been pointed out, is that it does
not allow for changing the path to swap dir.

---
David Monniaux Tel: +33 1 44 32 20 66Fax: +33 1 44 32 20 80 
Laboratoire d'informatique de l'École Normale Supérieure,
45 rue d'Ulm - 75230 PARIS cedex 5 - FRANCE