Re: request for help with gimp_register_save_handler problem!
On Wed, Nov 24, 1999 at 06:14:52PM -0500, Steve Lipa <[EMAIL PROTECTED]> wrote: > .amp, .cif, .il, il43, and .mag sometimes show up *twice* in the I don't know the exact problem, but maybe, during development, gimp queried your plugin twice (try rm ~/.gimp/pluginrc). Also, be sure that you do not have your executables twice in your plug-in search path. (And lastly, make sure (printf!) that youn really only register your handlers _once_) There are only some general comments.. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Tons of useless translations???
> Still, nothing is different! However, > > [glyph@helix ~]$ ls -al /opt/gimp/share/locale/ Ok... have you compiled gimp yourself to this location? If yes, maybe gimp errornously installs its locale files somewhere else (and doesn'T find it anymore). > That can't be good. I've checked out a recent CVS ... nothing is > installing into the Locale directory! Well: *cerebro:~# ll /usr/app/share/locale/fr/LC_MESSAGES/ -rw-r--r-- 1 root root 105113 Nov 23 02:11 gimp.mo (that's when I last typed "make install"). But, not surprisingly, LANG=fr gives me a (sparsely translated) french gimp menu. > I don't believe that's true ... OK > Is there something I need to do to get gimp to be localized? Thanks, In theory (and in pratcise on my machine) all you need to do is "LANG=fr gimp". This also happens to work on many machines, but it also does not work on many others. What does gettext --version (and locale --version) say on your system? (Yes, I am just seeking the difference in setups) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
ANNOUNCE: GIMP 1.1.12
GIMP 1.1.12 is out there: ftp://ftp.gimp.org/pub/gimp/unstable/v1.1.12/ The various po files prolly need updating (although this is definately not the last of it), so LANG!=C might be pretty broke. -Yosh
Re: Some menu stuff..
> > 2) L&C -> (Right Mouse) -> Layer to Image Size > > > > This is in Image -> Layers, IMHO it belongs to L&C menu too. > > Can plug-ins register in the L&C menu (this is a perl plug-in). No, they can't (yet). > OTOH, it would be trivial to re-implement this in C (for 1.2). This has been on my TODO list for oh so long. Expect this feature to appear in CVS soon... Salut, Sven
another datapoint on the multiple Datei-menu problem
Ok, it is not redhat. Too bad, this was my only clue so far. - Forwarded message from Joachim Ansorg <[EMAIL PROTECTED]> - >We are working on this. Do you use redhatlinux 6.x? I'm using SuSE Linux 6.2. SuSE 6.2 uses the LAMG environment variable to set the language. I18n wokred in earlier CVS versions. - End forwarded message - -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Tons of useless translations???
Hello Marc, 23. Nov 1999 Marc Lehmann wrote: ML> Sven, do you use redhat? anybody here with the same problem but ML> not ML> on redhat? no, but I use RedHat and I don't suffer from this problem... crazy, isn't it ? (RedHat 5.0, kernel 2.0.36, glibc 2.0.7, 'setenv LANG sk' actually works !) Bedo.
request for help with gimp_register_save_handler problem!
Hello GIMP developers! I have just submitted a plug-in to the GIMP plug-in registry. I'm happy to say that it seems to work, but sorry to say that it has a cosmetic defect that I've been unable to figure out how to fix. I was hoping that someone on this list might take a look at it and help me figure out what I am doing wrong. The gory details: The plug-in is called p2m_plugin, with source available at the GIMP plug-in registry. It installs five save_handlers which allow you to save your image in a variety of EDA formats for inclusion on a chip or PC board. I have only tried to use it with 1.0.4, which is where I am having the difficulty. The difficulty is that the EDA formats, which have names AMPLE, CIF, SKILL, SKILL43, and MAGIC, and file extensions named .amp, .cif, .il, il43, and .mag sometimes show up *twice* in the extensions submenu of the SAVE dialog. They show up at the top of the list in the order in which gimp_register_save_handler is called, and then later in alphabetical order. The plug-in requires an RGB* drawable, and the alphabetical entries of the list are properly grayed out when saving an indexed or grayscale drawable, but the entries at the top of the list are not grayed out. Otherwise the plug-in seems to work fine. I tried to mimic other plug-ins which register save_handlers as well as I could, but I seem to have introduced some subtle difference that causes this behavior. All other save plug-ins work fine on my installation. Also I have looked long and hard on dejanews for evidence that someone else has had this problem but could not find anything. I would greatly appreciate any help you can offer with this problem or any constructive criticism of the plug-in in general, as I am a novice at this. Thanks in advance for any help you may offer! Steve Lipa [EMAIL PROTECTED]
Re: Tons of useless translations???
On Tue, 23 Nov 1999, Marc Lehmann wrote: > On Tue, Nov 23, 1999 at 03:27:54PM -0500, Glyph Lefkowitz <[EMAIL PROTECTED]> >wrote: > > (btw, can anybody tell me why redhat ignores LANG? and what is this > LINGUAS thing anyway? maybe because other variables like LC_ALL are also > set and take precedence?) You may find this interesting. Upon launching a shell (before changing my configuration as described below): [glyph@helix ~]$ echo $LC_ALL en_US [glyph@helix ~]$ echo $LANG en_US [glyph@helix ~]$ echo $LINGUAS en_US > Ok, try this: > > LC_ALL=fr gimp I installed the Locale configuration stuff for RH, then set my locale to fr_FR. I now have this: [glyph@helix ~]$ locale LANG=fr_FR LC_CTYPE="fr_FR" LC_NUMERIC="fr_FR" LC_TIME="fr_FR" LC_COLLATE="fr_FR" LC_MONETARY="fr_FR" LC_MESSAGES="fr_FR" LC_ALL=fr_FR [glyph@helix ~]$ gimp Message: Passed serialization test Still, nothing is different! However, [glyph@helix ~]$ ls -al /opt/gimp/share/locale/ total 8 drwxr-xr-x 2 glyphusers4096 Nov 23 18:12 ./ drwxr-xr-x 5 glyphusers4096 Nov 23 18:12 ../ That can't be good. I've checked out a recent CVS ... nothing is installing into the Locale directory! > BTW: I was just told that redhat 6.1 was released quite some time _before_ > glibc-2.1 was released. Maybe they have used a slightly patched libc? (no > flame intended) I don't believe that's true ... when was glibc 2.1 released? RH 6.1 is pretty recent. At least, if my locale is properly set (all those env vars above), I don't get any "C library does not support locale" messages. At any rate, all GNU utils print out messages in french now. Is there something I need to do to get gimp to be localized? Thanks, --glyph
Re: Some menu stuff..
> 2) L&C -> (Right Mouse) -> Layer to Image Size > > This is in Image -> Layers, IMHO it belongs to L&C menu too. Can plug-ins register in the L&C menu (this is a perl plug-in). OTOH, it would be trivial to re-implement this in C (for 1.2). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: RFC: new animation parasite
On Wed, Nov 24, 1999 at 09:51:35PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > multilayer image describing an animation. > > If it does not exist then the multiple layers describe a single > > image (as usual) > > > > Who is supposed to set this parasite? All plug-ins (mostly file loaders) who have this information. For example almost all file-formats naturally know wether they store an animation or not. xcf doesn't, and for the rest it probably doesn't matter. (it is fine to leave this undefined). > How can Gimp know if your image is an animation or just a weird > multi-layer image? Most gfx formats now this intrinsically. > Did I miss something? Probably not. Let's speculate on how export might behave: image is anim? filter handles anim?export does = yes yes do nothing yes no asks or autoconverts no yes asks or autoconverts no no do nothing unknown any asks However, I have not proposed on how to decode that an image is _not_ an animation. Maybe in that case we can set interframe-delay to "N/A". The only problem I see is when a user loads multiple jpeg files and concatenates them, but we can still chose to just leave the "animtype" undefined (so export can skip the dialog box when an animation is saved as an animation). (btw it is trivial to write a plug-in that erases or sets animation status). Also, this does not need to be implemenbted in export before 1.2. But we can safely leave this half implemented in a few load-save plug-ins. I just wanted to standardize on some future extensions to the animation handling. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: fileops
> > Eek! ..and I got swamped by work.. nice timing :P > > Is this still relevant? I'm sorry for not doing this while I offered to > volunteer :( > Mitch and me have already worked a bit ;-) on the plug-ins. Well, compare the current menu with Olofs proposal. If there are any differences left, yes changing the menupath means just replacing the one string used in gimp_install_procedure() that indicates the menu path. But I think you'd qualify most for providing nicer icons ;-) We are still missing a new anchor... Salut, Sven
Re: RFC: new animation parasite
> I do not really like being asked wether a multilayer image should be > flattened before save because it might not be an animation (or vice versa). > > Sven, what do you think if we had a parasite as hint, e.g. > > "is_animation" (IMAGE, PERSISTENT) > If exists (without content), indicated that the image is a > multilayer image describing an animation. > If it does not exist then the multiple layers describe a single > image (as usual) > Who is supposed to set this parasite? How can Gimp know if your image is an animation or just a weird multi-layer image? Did I miss something? Salut, Sven
Some menu stuff..
Hello.. I had 2 things in my mind that would be nice in Image -> Layers -menu: 1) Stack -> Toggle Visible I think it would be handy to have a menu entry for this so one could define a shortcut for it. I notice I travel to the L&C dialog a lot to toggle layer visibility.. 2) L&C -> (Right Mouse) -> Layer to Image Size This is in Image -> Layers, IMHO it belongs to L&C menu too. Had these thoughts when I talked with montana today at work. Thoughts? Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
libgimpui <-> libintl?
Does anybody work on the libgimpui vs. libintl problem? The only solution that I can implement is to disable shared libraries when we build with our own version of libintl (and even that might be difficult given the atomic autoconf macro of gettext). Or is there any other solution? (except adding libintl to each and every plug-in?) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
i18n of menupaths - perl
How do I get the perl menupaths into the gimp .po file? it is no problem to mark them, but the standard xgettext program is not able to parse perl source. Should these go into the gimp-std-plugins-file? Should I put all translations into that file then? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
RFC: new animation parasite
I do not really like being asked wether a multilayer image should be flattened before save because it might not be an animation (or vice versa). Sven, what do you think if we had a parasite as hint, e.g. "is_animation" (IMAGE, PERSISTENT) If exists (without content), indicated that the image is a multilayer image describing an animation. If it does not exist then the multiple layers describe a single image (as usual) This would be a hint that the export facility can skip asking the user wether he wants to flatten the image. OTOH, we could combine the hint an some mroe useful parasite (more useful for the future): "interframe-delay" (IMAGE|LAYER, PERSISTENT) Specifies the default delay in seconds between frames of an animation, as a ratio in the form "n/d" (n and d are integers). The image parasite gives the default interframe delay, the layer parasite can override it. The existance of an image or layer parasite would server as an indicator that this is an animation. File-plug-ins can/should still create/parse the layer name, but in the future we might store this information seperately. What do you think? (This would not need to touch the core, and the transition can be done smoothly, i.e. upgrade plug-ins to create the parasites but do not read them yet). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: fileops
On Thu, Nov 18, 1999 at 03:03:38PM +0100, Michael Natterer wrote: > Tuomas Kuosmanen wrote: > > > > PS. How hard is the menu reorganization to do? Just changing the register() > > stuff on plugins? Would it be possible for me to do some part of it? Just > > remember I dont know half a jack about C, but I can read it and replace > > strings > > What about the following job-sharing: you may want to reorganize the > "Filters" subtree and I'll do the rest (I did the original menu-path-to- > help-path mapping together with Olof anyway and know what scheme we > agreed on) > > And, Olof: is your "Review and better --> Clean up and Re: Help System (fwd)" > mail (sent on nov., 12) still the mapping the list has agreed on? > > If yes, I'll take it as template for the menu reorganization then. Eek! ..and I got swamped by work.. nice timing :P Is this still relevant? I'm sorry for not doing this while I offered to volunteer :( Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: using dpi more than 72
On Wed, Nov 24, 1999 at 11:21:29AM +0200, Koot <[EMAIL PROTECTED]> wrote: > now my "script-fu" is not working (most of them), will have to go and figure what is > needed to get it to work again. There is a perl script named scm2scm that can, in theory, read in a script-fu and write it out again, updated for the version 1.2 api. I.e. try something like this on a BACKUP of your scripts: scm2scm -t 1.2 *.scm The problem is that it was not updated since a few months, so many changes are not yet reflected. However, if you find it useful and tell me whats missing I'd be happy to update it for 1.2. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Tons of useless translations???
>I'd vote for creating such menusentries in the core. Not only to solve this >problem (that can eventually be solved another way), but so that we can put >the Filter menus into a nice order with seperators etc. It seems reasonable. -- yasuhiro
Re: [patch] adding gimp-image-get-undo
On Wed, 24 Nov 1999, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Wed, Nov 24, 1999 at 12:42:39AM +0100, Sven Neumann <[EMAIL PROTECTED]> >wrote: > > I'd say lets call the function gimp_image_is_undo_enabled () since it > > gimp_image_undo_is_enabled would be consistent with the pdb, however. > Yes, that would probably be better. I will not re-post the updated patch here. Instead, I suggest that whoever wants to put it into CVS runs the patch through this simple command first: sed -e 's/get_undo/undo_is_enabled/' -e 's/get-undo/undo-is-enabled/' | patch That should be enough... -Raphael
