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 #16 For 2 Mar 2000

By Alex Harford

Table Of Contents

Mailing List Stats For This Week

We looked at 60 posts in 204K.

There were 22 different contributors. 10 posted more than once. 12 posted last week too.

The top posters of the week were:

1. Gimp on 64 Bit Systems

22 Feb 2000 - 29 Feb 2000 (6 posts) Archive Link: "Crash in Gimp 1.1.7 on Solaris 8."

People: Ludovic Poitou, Tim Mooney, , Daniel Egger

Ludovic Poitou

I'm getting a crash in gimp when trying the Outline tutorial from http://www.obscurasite.com/artstuff/tutorials/gimp-text-outline/

When doing the Edit Stroke command : (brush selected circle 3).

/usr2/gimp/bin/gimp: fatal error: sigbus caught
/usr2/gimp/bin/gimp (pid:1152): [E]xit, [H]alt, show [S]tack trace or [P]roceed: fg
/usr2/gimp/bin/gimp

He also provided a stack trace and the snippet of offending code.

Tim Mooney had a suggestion. "You don't say what architecture you're running on, but Solaris 7 or later on an Ultra would be a LP64 (i.e. 64 bit) OS, so an invalid address alignment would be indicative of incorrect alignment of a pointer. I'm not certain, but odds are good that pointers in Solaris 8 must be aligned on 8-byte boundaries, as opposed to ints which could be aligned on 4-byte boundaries."

He analyzed the code Ludovic provided, and had some ideas. "longc is a 32 bit quantity, which isn't big enough to hold an address on LP64 machines. That's probably why you're getting the crash. I bet I would get the same result (or at least an "unaligned access" warning) on my Tru64 Unix box." He concluded that "I'm not sure what the right fix is, being I haven't looked long enough at the code to decipher what's going on. The problem is almost certainly a 32 bit vs. 64 bit issue, though."

Ludovic Poitou replied with his specs:

SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10 UltraSPARC-IIi

But I haven't compiled with the 64 bit flag on !

A simple program like this :
main(){
printf("%d\n", sizeof(unsigned char *));
}

returns 4 !

Tim didn't have any other suggestions. Daniel Egger asked if Ludovic had any problems with plugins, but Ludovic replied that he hadn't noticed any crashes. EOT.

2. Testing The New i18n Code

24 Feb 2000 - 25 Feb 2000 (10 posts) Archive Link: "Testing and integration of The i18n solution (TM)"

People: Sven Neumann, SHIRASAKI Yasuhiro, Daniel Egger, Sven Neumann , 

Sven Neumann writes:

the new i18n implementation supports localisation of plugins outside the gimp distribution. I'm pretty sure that it works. I have however not yet tested if it really does what we expect and if it solves the problems it targets. Is there anyone out there maintaining a seperate plugin who is interested in internationalising it? It would be very nice to get some feedback if the current solution works under realistic circumstances.

One thing definitely needs to be done before the new framework is really usable: gimptool should provide the LOCALEDIR definition (together with the cflags?) so plug-ins that want to put their compiled message catalogs at the same place where the default gimp catalogs are located, can easily bind their textdomain using:

bindtextdomain ("gimp-plugin-foobar", LOCALEDIR);

and notify the gimp about its textdomain by calling: gimp_plugin_domain_add ("gimp-plugin-foobar");

Would be nice if someone else could take care of changing gimptool and doing a little testing...

If you need more explanations how the new system is supposed to work, let me know. Anyway I'll try to add a few lines to README.i18n in the next days.

SHIRASAKI Yasuhiro noticed:

some paths like:

<Image>/Video
<Image>/Script-Fu/*

are not translated with "The i18n solution"(TM). Shell we move dummy_entries[] items from app/menus.c to each appropriate plug-ins?

Sven exclaimed "Eek, yes of course, that does not work any more. There are two ways to solve this: Either we search in the gimp domain if the lookup of the menupath failed (like we used to do (*)) or we move the dummies into the plugins. I prefer the latter, since it is the cleaner solution." Daniel Egger suggested "testing for existance of the parent menu first and if it's not there extracting the correct translation for it from the full path and initialize it together with the tearoff menu." Sven noted that "On the first thought the idea looks promising, but I fear it isnot that easy. GTK+ wants to create the menu using the orginal strings. The translation is only used when the label is to be displayed." Later in his message he asked "Better ideas anyone?? If not, I'd say we move the dummy_entries into the plugins."

Daniel wanted to stick to his original idea:

Yes. That's why I thought of ripping off a slice from both the translation AND the original.

Consider this:
Plugin wants to create a menu <Image>/Filters/verynew/stupidtool.
Now we first check:
- Is there a menu <Image>/Filters/verynew
-> if not continue ripping off until we found a menu which is already there.
Let's assume we do have the menu <Image>/Filters already which translates into the German <Image>/Filter. We detected that the next instance we have to create is <Image>/Filters/verynew. Unfortuntely we don't have a translation handy but we can get this one by taking the translation from <Image>/Filters/verynew/stupidtool and strip off the same number of instances. The full translation would be <Image>/Filters/ganzneu/dummesteil <Image>/Filters/ganzneu and this is the menu to create.

The really trick is to sell this to Gtk+. The only think we can supply to Gtk+ is the menuname (the shortened one in this case) and a function which translates it. Thus we'd have to create a function which is able to do a translation although we can not directly pass the original.

Sven agreed, and replied that it was "exactly what I proposed at the end of my last mail. Despite that I proposed to build up the menu-structure (actually only the strings) in a hash-table before actually creating it. Would be much faster then going through gtk+ for each and every menu just to know if there's already a matching menu. We'd end up with a hash containing all possible menu-strings with their translations as key-value pairs and would use that table later instead of calling gettext again. This could be hacked in about 20 lines of code using a GHashTable, but I still consider this unnecessary bloat."

Daniel had some additional questions about the hash table, and suggested everyone look at the code used for the tearoff menus, which could be reused here. Sven replied that he had looked at this method, but was unsuccessful because GTK+ creates the submenu on the fly. Daniel still wasn't convinced, and is going to look at it further in the near future. End of Thread.

3. Keyboard Shortcuts To Menus In Toolbox

24 Feb 2000 (2 posts) Archive Link: "Menus in Toolbox"

People: Daniel Egger, 

Daniel Egger had an excellent suggestion:

Would it make sense to you to enable keyboard access to the menuentries in the toolbox?

I find it quite irritating that I can't get the File dialog with Alt-F resp. Alt-D (German Datei). At least for beginners not yet familiar with the shortcuts or the do-it-yourself- shortcut-system it would be a good start to use GIMP like any other program.

Also this would allow to reach the entries from the Xtns menu better.

Patchlet like always attached.... :)

Sven agreed that this was a good idea, and applied the patch.

4. Developing IPTC Support For The Gimp

25 Feb 2000 (5 posts) Archive Link: "I want to develop IPTC-data support for The Gimp."

People: Dirk Fvrsterling, Dirk Försterling, , Sven Neumann

Dirk Fvrsterling asked the list:

I got the CVS version of The Gimp and I am ready to start. The Idea is to introduce an IPTC... button to the file filters for the file types that support IPTC data somehow (JPEG, TIFF) and to implement an filter to write .iptc image files.

My questions so far: Is someone else already doing this? If not: What do I have to do to get CVS write access for this?

Sven Neumann wanted to know what IPTC is, and if it was important enough to add during a feature freeze. Dirk replied that "IPTC is short for "International Press Telecommunications Council". They made a standard for incorporating information about images within the image files. These informations are most important for photographers and their agencies to exchange digital images. Look for example at Adobe's PhotoShop. There you can type in some data about an image (Caption, Photographer, Source, Categorization...) and store it with that file. The format of this data is IPTC conformant." In another message he mentioned a url: http://www.iptc.org/. Sven replied that it looked promising, and Dirk should look at the Plug-In development at SourceForge.

5. Plug-Ins At SourceForge

25 Feb 2000 - 26 Feb 2000 (8 posts) Archive Link: "Why host plug-ins at SourceForge"

People: Kevin Turner, Robert L Krawitz, Robert Krawitz, 

Kevin Turner bracnhed off from the previous thread to reply to Sven. "Basically because gimp.org resources were not percieved as readily available, at least in comparison to SourceForge screaming "here, take it, please!" We wanted to be able to pass out CVS and web write access to an as yet undetermined number of people without disturbing the core. Since plug-in development has a different centre that core development, it did not seem unreasonable to base the community at a seperate site." Robert Krawitz agreed. Sven wanted to make it clear that he was not criticizing people for moving to SourceForge, he just thought that a similar setup could have been built using Gimp resources. This would also help the developers interact more with the core.

Robert L Krawitz replied:

Possibly, but is it worth the effort? VA Linux Systems is backing SourceForge with some fairly serious hardware (see https://sourceforge.net/docs/site/hardware.php) and staffing resources; they have 5 people managing the site. They have a dozen machines that I'd guesstimate are about $50K-$100K of hardware (RAID boxes and fast tape drives aren't cheap), and they've put a lot of programming effort behind it. They're basically running a small scale data center operation. I have yet to see any sign of downtime on the entire system.

I'd argue if anything that it would be worthwhile for the Gimp to move *its* operation to SourceForge, just to save on the system administration and backup headaches. It's always possible to mirror the CVS repository and other important stuff elsewhere (I'm taking a snapshot of gimp-print's repository every night as insurance myself).

6. Select By Color Bugfix

28 Feb 2000 (2 posts) Subject: "Select by Color segfault"

People: Paul E.C. Melis, , Garry Osgood

Paul E.C. Melis posted a bugfix:

If you have a layer that is smaller than the image size and you do a select-by-color using a point outside the layer's area, it gives a segfault. The assertion in image_get_color_at is wrong ... it's impossible to make it fail actually :-).

Sven replied that Garry Osgood had checked the exact same fix. End Of Thread, but thanks for trying Paul!

 

 

 

 

 

 

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.