Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Gimp Traffic #10 For 21 Jan 2000

By Alex Harford

Table Of Contents

Introduction

GIMP 1.1.15 was released. Check the Changelog for more info.

Mailing List Stats For This Week

We looked at 111 posts in 328K.

There were 46 different contributors. 22 posted more than once. 16 posted last week too.

The top posters of the week were:

1. Coding Menu Translations

12 Jan 2000 - 17 Jan 2000 (5 posts) Archive Link: "menu translation again - how does it work?"

People: Marc Lehmann, Sven Neumann, Michael Natterer, Sven Neumann , , Stanislav Brabec

Marc Lehmann asked the list:

I was alerted by Stanislav Brabec about a problem with menu translations. In his translation of Logulator to czech, he properly changed all occurences of "Logulator", but, while the gimp displays the menus _within_ the Filters/Logulator menu correctly, the Logulator menu itself NOT being translated.

I admit that the time where I even remotely understood how translations is to be handled has long gone, thus:

What do I (or the translators) to do so that menus get translated correctly, all of them, with all components?

Sven Neumann replied that "Adding the Logulator to app/menus.c is the correct fix (at least for now). Of course, you only need to add the submenu name to menus.c, not all the Logulator scripts."

Marc disagreed, saying that "No, it definitely is not. For people not having gimp-perl this just means an empty menu. For third-party plug-ins this means yet another difference between "built-in" plug-ins and themselves."

Sven then replied that this will work. "You just add "Logulator" to the list of dummy_entries in menus.c that only exists for the purpose of adding those strings to the pot files."

Marc had an additionnal question, "But when I understand you correctly I can achieve exactly the same by adding a "dummy translation" in the logulator plug-in? That'd be much less offensive, and the translation would be where it belongs: gimp-perl's pot?"

Michael Natterer confirmed that Marc was correct, and asked, "I didn't know where to add the dummy perl string in the perl plugin, so I added some perl menu paths to menus.c. Could you move them to the perl plugin please?"

There were no more messages in this thread.

2. Bug in Paste to Mask

12 Jan 2000 - 13 Jan 2000 (2 posts) Archive Link: "Discovered paste to mask bug"

People: Carey Bunks, Garry R. Osgood, 

Carey Bunks wrote that he has found a bug in the CVS Gimp 1.1.14. The problem

is that it is no longer possible to paste from the default buffer to a channel or layer mask. Thus, the operations:

does not place the paste into the layer mask! The float just mysteriously disappears. Same behavior occurs when trying to paste into a channel mask.

Garry R. Osgood replied that he and Sven had made some fixes on the 11th and 12th. He continued, saying "While the bug discusses Layer --> Channel pastes, the underlying problem generally affected RGB -->Grayscale translations and would affect pastes to masks as well. Please let us know if what you see persists in newer versions. Thanks."

There were no more messages in this thread.

3. An Opinion on the Gimp Splash Image

13 Jan 2000 (3 posts) Archive Link: "Gimp splash image and "about" image"

People: Raphael Quinet, Tuomas Kuosmanen, John E. Vincent, 

Raphael Quinet had some ideas for the Splash Image and About Screen: "the lightbulb image that is used in File/About could also be updated because it has not changed much since the early days. So what about this: we use the image version 1.14 for the splash screen (or 1.15 if Tigert can improve it), and the version 1.4 with the baloon for the about page. "

He also thought it would be useful to have dates beside tigert's splash image history.

Tuomas Kuosmanen replied quickly to Raphael's message, asking "what do others think? I could edit the brush image (Wilber & Sons) to suit better for "About" -image, anything you would like to have there?"

Regarding the dates, he said that "If someone can provide me the dates, I can add them to the page. It's just static html and I update it by hand whenever the splash changes.."

John E. Vincent added that "I personally have always liked the 1.1.10 image and it seems to have more of an "About" feel to it."

4. Ambiguity in undo.c

13 Jan 2000 (2 posts) Archive Link: "undo.c [i18n problems]"

People: David Monniaux, Austin Donnelly, 

David Monniaux had some questions regarding the translations in undo.c:

#: app/undo.c:2876
msgid "FS rigor"
msgstr ""

What do these options mean?

General note to programmers: please document the meaning of some obscure abbreviations and sentences, especially if you coin words yourselves...

Austin Donnelly replied that

FS is floating selection. I agree, the messages are not exactly very clear.

"FS to layer" is what happens when you convert a floating selection into a full, proper layer.

"gimage" is a pretty non-descriptive catch-all undo type used in many places, mostly when pushing an entire tile manager on the undo stack. Ideally, we'd go round all the places "gimage" is used, and give a more meaningful undo type (eg paint or fill or whatever). Ditto for "gimage mod" and "paint core".

"FS rigor" and "FS relax" are used in pairs to temporarily hide the floating sel and display what's under it (eg during floating selection moves). They should never actually appear as undos by themselves, but as part of a larger group. I don't think there's any need to translate them.

In my opinion, floating selections should be taken out and shot, since we now have proper layers. They cause much confusion to users, and require lots of special-case code.

There were no more replies in this thread.

5. Making Plug-ins Intuitive

13 Jan 2000 (3 posts) Archive Link: "plug-in functionality [PolarCoord, MapObject...]"

People: David Monniaux, Tom Rathborne, 

David Monniaux wrote the list:

I am currently reviewing plug-ins with "real users".

Some plug-ins apparently and annoyingly lack much needed functionality. For instance, the PolarCoord plug-in insists on rendering into the same image as source, with same dimensions.

It is not the only plug-in with that problem, MapObject also insists on rendering into an image of the same size.

Either

  1. I have not found the "right way" to have these plug-ins render images of the right size. It is then very much unlikely that normal users will find a way to do this.
  2. The needed functionality is absent. I consider this to be a BUG that needs to be fixed before 1.2 is out. It is a bug because we feature some plug-ins that provide a functionality provided by decent painting programs, yet this functionality lacks some fundamental setting, contrary to the intuition of all users.

Tom Rathborne replied to Daid's message, saying "Expanding the image to 1400x1400 first would fix that. However, I can imagine that you might want to wrap an 8000x100 image into a 1000x1000 circle, but expanding the image to 8000x8000 might be beyond your machine's resources."

He also added that there is no right way when using this plug-in right now, and thinks that many other plug-ins suffer from this problem. He feels that they will not be fixed in a reasonable amount of time.

David Monniaux replied to this, agreeing with Tom. He suggested a feature that would help this plug-in to be more intuitive, "Two input fields: target-width and target-height in each of the plug-ins where this bug is most annoying?"

There were no additional messages in this thread.

6. Improving Tool Tips

13 Jan 2000 - 14 Jan 2000 (2 posts) Archive Link: "tip messages"

People: David Monniaux, Sven Neumann, 

David Monniaux again wrote the list about making the Gimp more user friendly,

One complaint was that there is no obvious way to rotate the image. Of course, WE all know it's the transform tool in rotation mode, but it's not trivial to guess: the tip for the tool just says "Transform".

Do you agree to some modifications on the English (and of course French) texts on this example and others so that tip messages supply more immediately understandable information?

Sven replied,

Yes, please go for it. The "Tip of the day" messages haven't seen an update for long and should definitely be extended and checked for correctness.

Please also add the following stuff:

End of thread.

7. Writing a Shockwave Format Plug-in

10 Jan 2000 - 16 Jan 2000 (5 posts) Archive Link: "gimp SWF plugin"

People: , Marc Lehmann, John E. Vincent, Kelly Lynn Martin

alex wrote the list to say that he "I've recently noticed libswf.a, a C http://the-labs.com/PerlFlash interface for Shockwave Flash, at http://reality.sgi.com/grafica/flash/. I also came across http://the-labs.com/PerlFlash , a Perl interface to the above. Unfortunately, libswf.a is not GPL, so what is the feasability of writing a gimp plugin for SWF? The SWF file-format is open, so it could easily be reimplemented as some sort of GPL-thing. Another reason to reimplement it is that it is only available for Irix, BSD and Linux/x86. It would be a bit of a kludge, as Gimp clearly is not a vector graphics app. Your thoughts appreciated."

Marc Lehmann replied to say that he does not see a problem with a plug-in not being GPL'd. He also added that "At some distant future, gimp's vector capabilities will be vastly improved. But at the moment there shouldn't be much incentive for a swf plug-in. Re-implementing it as a GPL library (maybe LGPL is suited, even), would be worthwhile despite this, however!!!!"

Kelly Lynn Martin added that it does have to be compatible with the LGPL.

John E. Vincent mentioned that Marcomedia may be opening the Shockwave player. He also cautioned that "Having said all that, Don't expect Macromedia to fully open up shockwave formats. If someone could write an open source flash type development tool, It couldn't be good financially for them."

8. Duplicate PDB Error Messages

15 Jan 2000 - 16 Jan 2000 (4 posts) Archive Link: "Startup - duplicate PDB messages? - 1.1.15"

People: Glenn PM, Marc Lehmann, Garry R. Osgood, 

Glenn PM wrote about his troubles with 1.1.15:

I just sucessfully made the 1.1.15 version of gimp this morning, but am getting some PDB messages each time I start it up:

$ gimp

** WARNING **: removing duplicate PDB procedure "perl_fu_blowinout"
** WARNING **: removing duplicate PDB procedure "perl_fu_border_average"
** WARNING **: removing duplicate PDB procedure "plug_in_ditherize"

Etc.

Marc Lehmann wanted to confirm some things before continuing:

Did you remove your old gimp installation? The error messages below are probably caused by left-over plug-ins in your $PREFIX/lib/plug-ins directory.

I wouldn't expect much breakage due to these messages (if at all).

Glenn answered that "Yes I did. You know I also experienced some strange behavior when I made this version. After I finished it the first time ( a real long time too on my 133), I got lots of errors since the 1.1.15 version was referring to the last build I made which was 1.1.12. I do not have gimp in my library path so I thought that was kind of odd. I also did a make uninstall on the old version after I got a good make on the new. Then I installed the new. I deleted the old install and remade the new so it is strange that I'm getting these PDB messages now. Since nothing appears wrong, I'll just ignore them."

Marc Lehmann suggested that Glenn does a:

rm `gimptool --prefix`/lib/gimp/1.1/plug-ins/*.pl

In response to the 'make uninstall', he requested the error message, but said that nothing will go wrong with the Gimp, except for the long startup time.

Garry R. Osgood asked if "Was "make uninstall" invoked on Makefiles generated by the 1.1.15 package? These are not likely to be symmetrical with those generated by 1.1.12, and, I don't believe, can be expected to clean up after what Makefiles generated under 1.1.12 produced."

Glenn replied that Marc suggestion of getting rid of the old plugins fixed the problem, and there were no additional messages in this thread.

9. Bugfix For Double Quotes in Script-Fu

17 Jan 2000 - 18 Jan 2000 (4 posts) Archive Link: "[patch] escaping double quotes in SF_STRING values"

People: Tamito KAJIYAMA, Nick Lamb, Tor Lillqvist, 

Tamito KAJIYAMA wrote to say:

I've just installed 1.1.15 and found a bug (IMO) that Script-Fu failed if a string containing double quotes was given as an argument of the SF_STRING type. Attached is a quick and dirty patch for fixing that bug.

I wonder if we need to escape the values of the SF_FILENAME type in the same way, although I believe that few people use double quotes in file names.

Nick Lamb wrote that he "Didn't look at the patch, but it sounds like a good idea to do this to SF_FILENAME as well."

Tor Lillqvist confirmed this, and explained the situation:

This patch is unnecessary when using GLib 1.3 or later, as the whole point of g_strescape() (which is what the ESCAPE macro in the source calls) is to escape chars that are risky in a C (or script-fu) string, like double quotes or nonprinting characters.

Unfortunately g_strescape as implemented in GLib 1.2 escapes only backslashes... (because or my shortsightedness, I confess), not double quotes (or nonprinting characters). However, the code in the GIMP that uses g_strescape() gets unnecessary complex if we start taking that into consideration.

Wouldn't it be far simpler to release a newer version of GLib 1.2, with g_strescape() having the same calling convention as before (the prototype was changed in GLib 1.3 (partial sigh)), but with a wider range of characters handled, and then require this GLib version (1.2.7?) for the development GIMP?

Tamito KAJIYAMA replied to say that he agreed with fixing GLib 1.2, as his patch was a compromise.

There were no more messages in this thread.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.