Re: Testing and integration of The i18n solution(TM)
Hi, 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. Which is 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... Salut, Sven
pnm plugin
Can anyone extend the pnm plugin so it can export pbm?
Re: Magicless file formats
Mattias Engdegård wrote: Anyway, if the user finds that an application doesn't try to load a file whose name ends in .tga as a Targa file (or worse, attempts to load it as a Group 3 fax file), then the same user will assume that the application, or its programmers, or both, are stupid beyond belief. And rightly so :-) I would prefer a program that loads a group3 Fax file even if it is named .tga --Peter -- Peter Kirchgessner WWW:http://www.kirchgessner.net e-mail: [EMAIL PROTECTED]
Re: Testing and integration of The i18n solution(TM)
On 25 Feb, Sven Neumann wrote: Which is 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. For a new translation function I guess? Would be much faster then going through gtk+ for each and every menu just to know if there's already a matching menu. It shouldn't be that complicated, but that depends on the internal representation of menus which I didn't look at. 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. Uhm, no, that's not what I had in mind. This could be hacked in about 20 lines of code using a GHashTable, but I still consider this unnecessary bloat... Look at the code we already have to add the tearoff menus. A similar thing could be used to create the branches itself. I'm leaving home in a few minutes and after spending a whole night on other problems I'm very glad to have a look such an improvement. Don't expect a solution before 17:00 CET... -- Servus, Daniel
Re: Testing and integration of The i18n solution(TM)
Hi, Look at the code we already have to add the tearoff menus. A similar thing could be used to create the branches itself. Don't waste your time at that. I already did that and I tried to explain you why there is no way to hook into that place since GTK+ creates the submenu on the fly. At the time we create the tearoff menu, the submenu is already created. But when the submenu is created, the menu_translate function does not know the complete path and therefore can't lookup a matching translation. Unless I have overseen something obvious, the only way to go is to analyze the menu strings on our own before we actually build the menus using gtk+. The more I think about it, the more I feel it might be worth to try the implementation I've proposed. Eventually this weekend... BTW, is there a function to unbind from a textdomain? There's actually no need to hold the plugins translation tables in memory after the menus are created and we only need such a small portion of it. Or are the message catalogs properly shared if multiple apps use the same catalog? Salut, Sven
Re: I want to develop IPTC-data support for The Gimp.
Hi, 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? My questions are: (1) What does IPTC mean? (2) Can it be considered important enough to be included at the current state? IMHO the answer to question (2) is NO, even without knowing the answer to question (1). The only change considered to go into JPEG for 1.2 is gimp-cosmin-2212.patch which I think is a perfectly valid bugfix. Salut, Sven
Re: Re: I want to develop IPTC-data support for The Gimp.
Hi, (1) What does IPTC mean? I forgot to tell you: See http://www.iptc.org/ -- D i r kF "o r s t e r l i n g [EMAIL PROTECTED] http://www.DeathsDoor.com/milliByte/ -- WorkMan - The civilized CD Player Sent through GMX Free Mail - https://www.gmx.net
Re: Re: I want to develop IPTC-data support for The Gimp.
Hi, My questions are: (1) What does IPTC mean? 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. (2) Can it be considered important enough to be included at the current state? Well, I have to admit that I didn't inform myself about GIMP's development state. Sorry if I ask during a feature-freeze. The only change considered to go into JPEG for 1.2 is gimp-cosmin-2212.patch which I think is a perfectly valid bugfix. There is no need to incorporate it into JPEG, because there is an alternate image format (.iptc). It would just be nice to have it in there, too. -- D i r kF "o r s t e r l i n g [EMAIL PROTECTED] http://www.DeathsDoor.com/milliByte/ -- WorkMan - The civilized CD Player Sent through GMX Free Mail - https://www.gmx.net
Re: Testing and integration of The i18n solution(TM)
On 25 Feb, Sven Neumann wrote: Don't waste your time at that. I already did that and I tried to explain you why there is no way to hook into that place since GTK+ creates the submenu on the fly. At the time we create the tearoff menu, the submenu is already created. But when the submenu is created, the menu_translate function does not know the complete path and therefore can't lookup a matching translation. Hm, but I think I nearly got it. Unless I have overseen something obvious, the only way to go is to analyze the menu strings on our own before we actually build the menus using gtk+. The more I think about it, the more I feel it might be worth to try the implementation I've proposed. Eventually this weekend... Please wait a moment. Otherwise we'll work again in different direction. BTW, is there a function to unbind from a textdomain? No. There's actually no need to hold the plugins translation tables in memory after the menus are created and we only need such a small portion of it. Or are the message catalogs properly shared if multiple apps use the same catalog? With gettext? You must be joking. I've never seen such a bad implementation of anything. -- Servus, Daniel
Re: Magicless file formats
Anyway, if the user finds that an application doesn't try to load a file whose name ends in .tga as a Targa file (or worse, attempts to load it as a Group 3 fax file), then the same user will assume that the application, or its programmers, or both, are stupid beyond belief. And rightly so :-) I would prefer a program that loads a group3 Fax file even if it is named .tga I cannot believe that such a situation would be more common than attempting to load a properly named Targa file. You can always set the format manually, but the automatic mechanism should be optimized for the common case.
Re: Why host plug-ins at SourceForge? (Was: I want to develop IPTC-data support for The Gimp.)
Hi, just do make my position clear: I was not critizing your decision. My feeling was just that we could have built a similar framework on available resources with substantial interest and a little effort. As long as it helps Gimp development I'm all for it. (That's why I pointed Dirk to your project). BTW: I think you should try to interact more with the core. This is in interest of both parties. Here are a few suggestions, that IMO will help to improve the situation for all of us: (1) Add an online version of the Libgimp documentation to your website. You might even want to help us to improve it further. The whole purpose of generating this documents was to help plugin developers. (2) Try to help us improving the documentation shipped with Gimp. For example I found an interesting document about plug-in i18n on your site . This is something we should add least mention in our documentation as a link. I plan to move some of the files in the docs directory into devel-docs and I'd love to get some updates / corrections / links from ypur part as this documentation is primary targeted to plugin developers. Salut, Sven PS: About that document at http://gimp-plug-ins.sourceforge.net/doc/i18n.html: I stronly encouryge you to ask plugin developers to call their textdomain gimp-plugin-name instead of only plugin-name. I even thought about forcing that naming convention when implementing "The i18n solution", but I guess it should work if we nicely ask people to use it. And you will want to add an explanation of the proper usage of gimp_plugin_add_domain() as soon as we have worked out the remaining issues.
Re: Why host plug-ins at SourceForge? (Was: I want to develop IPTC-data support for The Gimp.)
From: Sven Neumann [EMAIL PROTECTED] Date: Sat, 26 Feb 2000 02:37:02 +0100 just do make my position clear: I was not critizing your decision. My feeling was just that we could have built a similar framework on available resources with substantial interest and a little effort. As long as it helps Gimp development I'm all for it. (That's why I pointed Dirk to your project). 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). -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
