Re: [Gimp-developer] SMP support
Hi, Michael Soibelman [EMAIL PROTECTED] writes: I just noticed that there no longer seems to be the --with-smp configuration option! Is this an omission or intentional? IIRC, the configuration option to add support for multiple processors has always been --with-mp and it's still there. Also, excuse my ignorance, but can options such as --with-smp be passed to the rpm command rpm's do include prebuilt binary packages, you can't reconfigure them later. I suggest you build from source if you want SMP support. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
This is going to be a bit long, but here is a quick summary: I would like to change the API to the load/save plug-ins by adding one extra parameter. This parameter would be ignored by almost all current plug-ins, but it would be useful for the file formats that can contain multiple images. For example: icon files, tar files, various game files, etc. Since this API change would probably break all plug-ins, I would like to discuss this and get some comments. Note that I could submit a patch for all plug-ins that are currently in the Gimp CVS, but I cannot fix the other load/save plug-ins that are not part of the standard distribution. 1) History of the problem A long time ago, I started implementing some plug-ins for loading and saving various images contained in Doom WAD files or Quake PAK files. These files can contain many images in different formats (wall and floor textures, sprites, skins, ...) and my goal was to be able to edit these images directly from within the Gimp without having to unpack and the repack the archive file using an external tool that was slowing down the whole process. However, selecting the right image within the file is not easy. For the file_*_load plug-in used interactively, I can use a tree widget showing the structure of the archive file and letting the user choose the image to edit (among several hundreds). But this does not work in non-interactive mode and this is annoying when saving the image, because the user must select again the appropriate location for the image within the archive file. I stopped the development of these plug-ins when I saw that I could not find a user-friendly solution to this problem. Later, I realized that the problem was common to all file formats that support multiple images. This includes the Windows icon files, containing multiple icons at different sizes and bit depths, as well as the standard archive file formats such as tar and zip (these archives could be handled at a lower level by something like gnome-vfs, but this is not an option for icon files or game files). 2) A solution Then I thought about CGI scripts and the environment variable PATH_INFO that is set by the web server when the URL contains some path information after the name of the CGI script (for example, a script /cgi-bin/stuff gets called with PATH_INFO=/some/path if the URL of the request is http://your.hostname/cgi-bin/stuff/some/path). This is exactly what we need in order to support multi-image files in the Gimp: simply add the name of the selected image to the name of the archive file. For example, let's say that I want to edit the image of the chainsaw in Doom. I would tell the Gimp to open .../doom.wad/P/CSAWA0. The Gimp would find that the real file to open is doom.wad (because this is a file, not a directory containing a sub-directory called P) and it would tell the WAD plug-in to open it. It would also pass the extra path P/CSAWA0 to the plug-in. The same would happen when saving the file, so the plug-in would know where the image has to be saved inside doom.wad. If I want to edit one of the floor textures in the same file, I would tell the Gimp to open .../doom.wad/F/F1/FLOOR7_2 and the plug-in would be called with the extra path F/F1/FLOOR7_2. A similar thing could be done for icon files, if we invent special names that would identify the different images (size and bit depth) that can be stored in an icon file. For example, one could edit .../favicon.ico/16x16x4 (16x16, 4 bits) or .../favicon.ico/48x48x8 (48x48, 8 bits). Both of these would open the same favicon.ico file, but a different image would be choosen inside this file. 3) Changes to the plug-in API The File-Open dialog would behave as follows: if the given path leads to a regular file, open it as usual (no extra path). If the path does not exist, then try to remove the last element from the path and see if there is a file (not a directory) with that name. If yes, open it and pass the remaining part of the path as a parameter to the plug-in. Repeat the shortening of the path until a valid file or directory is found. If a directory is found, then report a failure (file does not exist). The same thing would be done for File-Save. In order to support this, the file_load/save API has to be changed by adding one parameter (extra_path or path_info or something like that). This parameter would be NULL when a regular file is loaded or saved, but it would contain the name of the image when a multi-image file is edited. The only thing that would have to change in the current plug-ins is the addition of this parameter that would be ignored. The plug-ins for the file formats supporting multiple images would use this extra parameter. If it is not NULL, then the plug-in would open the corresponding image within the file. If it is NULL, then the user has selected the whole file instead of specifying a single image from that file. In this case, the plug-ins would pop up a tree or list
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
On Tue, Aug 07, 2001 at 05:28:15PM +0200, Raphael Quinet [EMAIL PROTECTED] wrote: 3) Changes to the plug-in API The File-Open dialog would behave as follows: if the given path leads to a regular file, open it as usual (no extra path). If the path does A loong time ago I hacked the gimp to allow a variable number of arguments in pdb calls - if the code still works then it's already possible to call functions with a variable number of arguments. Each plug-in gets the actual number of arguments so it's a matter of checking it to see wether an extra argument exists. In order to support this, the file_load/save API has to be changed by extended, only, even ;) file is edited. The only thing that would have to change in the current plug-ins is the addition of this parameter that would be ignored. Even if we didn't have variable-number-of-args, the gimp itself knows how many agruments a plug-in takes and could act accordingly, i.e. by not passing in more argument than neccessary. 4) Feedback Any comments? I just looked at gif.c, it does this: if (nparams != 9) in the noninteractive case, which nobody cares about and leaves the interactive case untouched (i.e. it doesn't check). The same is true for pnm.c. I only expect problems with the non-optimal plug-in load/save data api or maybe something obvious that I miss, but it would be sensible to call plug-ins interactively with other arguments (or specially pre-populated agruments) than in the interactive case - the api already allows all this, I think. The noninteractive part is much more difficult (in that it requires sourcecode changes), but we could actually use the argument names (this is off-topic). This might sound ugly in C, but most scripting languages (e.g. perl) actually have functions which accept many arguments. The key is not to use them but default them sensibly: new Coro::Socket PeerHost = gimp.org, PeerPort = 80; and the many other arguments get sensible default values (like Multihomed = 1). In the long run, we need to use this approach anyway (think all the nice gimp functions with waaay to many arguments). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
On Tue, Aug 07, 2001 at 05:28:15PM +0200, Raphael Quinet wrote: 4) Feedback Any comments? IMHO you'd be better off just using: wad://home/raph/slimy.wad/p/alien.foo This can be handled today in Gimp 1.2, see url.c Non-interactive stuff would go exclusively through these URLs while the interactive user would also need an Open, and possible Save As... handler for the WAD file itself, which would simply be a browser or other UI for picking sub-directories and files. Hmmm, in fact this inspires me to play with loading KiSS .cnf instead of .cel as well, which I had always intended to do after finishing GnomeKiSS some time. Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp menu thumbnail
Hello, I wrote patch codes for gimp and gtk+ to append filter thumbnail on gimp menu: + Change feature of Gtk+ itemfactory to specify pixmap data. + When plug-in install, pixmap (icon) data are transfered to gimp core on wire mechanism. + Install data of pixmap are cached to ~/gimp/pluginrc file; list data is constructed from line number and XPM format lines. + Contain thumbnail data of plug-in sample image. Please try and check my code. http://mibai.tec.u-ryukyu.ac.jp/~oshiro/Programs/others/gimp-iconmenu/index-eng.html P.S. I don't subscribe gimp-developer, sorry. = OSHIRO Naoki: [EMAIL PROTECTED] http://mibai.tec.u-ryukyu.ac.jp/~oshiro/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
Hi, Raphael Quinet [EMAIL PROTECTED] writes: 3) Changes to the plug-in API The File-Open dialog would behave as follows: if the given path leads to a regular file, open it as usual (no extra path). If the path does not exist, then try to remove the last element from the path and see if there is a file (not a directory) with that name. If yes, open it and pass the remaining part of the path as a parameter to the plug-in. Repeat the shortening of the path until a valid file or directory is found. If a directory is found, then report a failure (file does not exist). The same thing would be done for File-Save. I don't think this is a good solution to your problem. It is in no way compatible with others programs or file system layers we might want to use in the future (like gnome-vfs for example). How is this supposed to work with non-local files? I don't think we want to wait for timeouts or interpret File not found error messages from a web|ftp|nfs|smb server while recursively stripping off stuff from our filename. If you want to support special filetypes that support filesystems inside files, please stay with standards and use a correct URI. As Nick already pointed out, the current API already supports this sort of stuff. If it needs additions or changes, we can of course change it now during the development cycle towards 1.4, but please let us find a reasonable solution. In order to support this, the file_load/save API has to be changed by adding one parameter (extra_path or path_info or something like that). This parameter would be NULL when a regular file is loaded or saved, but it would contain the name of the image when a multi-image file is edited. The only thing that would have to change in the current plug-ins is the addition of this parameter that would be ignored. The current plug-in API already allows to specify any number of additional parameters you like. As long as you document this, I can't see why this feature shouldn't be used. It's definitely a good solution for the non-interactive case. For the interactive case, a GUI to choose the relevant part of the file implemented inside the plug-in is probably what the user wants. The current API also allows the plug-in to store arbitrary data, so you can default to the last choice if the plug-in is subsequently used interactively. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compile error with 1.2.2
Finally figured this out over the weekend. Once i compiled perl-5.6.1 single-threaded gimp also compiled. Hm. i still don't really get it. b [EMAIL PROTECTED] On Wed, Aug 01, 2001 at 04:33:48PM -0400, ben soo wrote: i get the following errors when i try to compile Gimp 1.2.2 . It's been happening since 1.2.2-pre1, when i sent more or less this same report into the mailing list. Not being a Gimp or perl guru, i've no idea what's going on; could someone give me some clues abt this so i can fix it? i'm using glibc 2.2.3 make 3.79.1 gcc 2.95.3 perl 5.6.1 Gtk-Perl 0.7007 PDL 2.2.1 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp menu thumbnail
Hi, Guillermo S. Romero / Familia Romero [EMAIL PROTECTED] writes: IIRC, no new features will go into 1.2.x. this is correct. About GTK+, they are working in 1.3/2.0 now, so I doubt the patch will be applied. You should check what is going in CVS of both, and then see if it still applies, and how. current development GIMP in CVS uses the unstable GTK+ tree that has support for icons in menus and GIMP already makes use of this feature. We want to allow plug-ins to register an icon together with their menu entry and I'd prefer this solution over trying to create an icon automatically. It's a nice hack though and we might want to pick up the idea of applying the filters to a wilber image to create the plug-ins icons. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SMP support
On Tue, Aug 07, 2001 at 10:48:37AM +0200, Sven Neumann wrote: Hi, Michael Soibelman [EMAIL PROTECTED] writes: I just noticed that there no longer seems to be the --with-smp configuration option! Is this an omission or intentional? IIRC, the configuration option to add support for multiple processors has always been --with-mp and it's still there. Also, excuse my ignorance, but can options such as --with-smp be passed to the rpm command rpm's do include prebuilt binary packages, you can't reconfigure them later. I suggest you build from source if you want SMP support. Unless you build from source RPMs, of course. Just install it and edit the spec file to include what options you want and rebuild the RPM. Keeps the dependency tracking nice and orderly. Stephen -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Auto save?
Is there any way to add an auto save every (?) minutes function to GIMP? I've pushed this program very hard and sometimes might forget to save my work until after a couple of hours (seems like minutes). Well, one of those plug in crashes and it's all gone. This would be an excellent function to have.unless it's already there and I missed it...AGAIN??? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
