Re: Coding style (was: PROPOSAL: New i18n solution)
:set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0
Works most of the case.. (maybe not perfect, but..)
Thanks a lot! I just put it in the programming guidelines.
Federico
Re: PROPOSAL: New i18n solution
Hi, I have some working code that does use the pluginrc to store the additional locale info for plugins (as described in my earlier mail). Additionally the framework for setting the domain (and optionally a path) from a plugin through a PDB call is complete and tested. The new PDB call would be (in its wrapped form): gimp_plugin_add_locale_domain (gchar *domain_name, gchar *domain_path) and can only be called in the query function of a plug-in. The domain_path may optionally be NULL. Proposals for a better name are welcome. Daniel, if we can agree on this solution, I would like to check this code in, so that you can work on adapting your code to the framework. While working on the code I came across a new idea which would simplify things quite a bit eventually: The plugins create their menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why not use the knowledge about the domain_name the translated string is to be found in and only look it up in that domain by passing it to menus_create_item_() ? You'd only have to change the code to iterate through the plug_in_defs instead of proc_defs since the domain is stored with the plug_in definition. Salut, Sven
Re: PROPOSAL: New i18n solution
Hi, Ok, one shouldn't just bitch about other people's code, so here is my patch that adds an optional locale_domain and locale_path to the plugin structure and extends the pluginrc code to read and write that information from/into the pluginrc. This code is obviously a few lines longer than what Daniel proposes, but it seems to work very well here. The locale information is optional and if the locale_domain is given, there _can_ be an additional locale_path entry. The code handles the case that pluginrc registers the locale_domain twice (by using the last given entry), but that should never happen unless the user edits the pluginrc by hand. You will find the patch at http://sven.gimp.org/files/locale_parse.patch. It only contains the code to read, store and write the locale info for the plug-ins. This will have to be extended to do build a list out of this entries (eventually checking for the existence of the given paths). Other necessary parts can be taken from Daniels patch. What is missing right now is a function to add the locale_domain and locale_path information from a plugin using a PDB call. This will follow later. Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
On Wed, 23 Feb 100, Miles O'Neal wrote: [snip thought GNU style was bad but it's OK] I still don't. Two spaces just isn't enough. Three or four is much better. And I like space before the paren only if it isn't after a function or procedure name. And I firmly believe that if God had intended we format our code with spaces, He would have made them wider. In my own projects, I use a one-tab-per-indent style. (I have no idea if my style is analagous to someone else's; I wrote my own .emacs files.) This drives some of my developers nuts, but it's my perogative, just as it's the GIMP community's perogative to enforce GNU style. [snip consistent style important] I use to feel this way. But now, so long as each file has a consisten, reasonable style (or preferably, package of files, say a directory), I'm happy. If it's a requirement of a project that one adhere to a specific coding style, I think it's pretty rude to ignore such a request in contributions to that code, regardless of one's personal beliefs on the matter. I handle perl as closely as possible to how I handle C. I think Perl should standardize on only 10 or 20 different ways to write a loop before you start worrying about indentation. And people wonder why Python has the whitespace enforcement rules... ::runs from Marc :-):: __ __ __ _ _ _ | | \_/ |_] |_| |_| |_ || | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: gimp_plugin_add_locale_domain (gchar *domain_name, gchar *domain_path) and can only be called in the query function of a plug-in. The domain_path may optionally be NULL. Proposals for a better name are welcome. I'd recommend gimp_plugin_domain_add (gchar *domain_name) and gimp_plugin_domain_add_with_path (gchar *domain_name, gchar *domain_path) because it IMHO fits better into the namespace and is more obvious than to have just 1 function with two meanings. Daniel, if we can agree on this solution, I would like to check this code in, so that you can work on adapting your code to the framework. I sent a newer patch in my last mail. It should do everything we need for now. I totally agree with this solution, so let's finalize it and get it into the tree. While working on the code I came across a new idea which would simplify things quite a bit eventually: The plugins create their menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why not use the knowledge about the domain_name the translated string is to be found in and only look it up in that domain by passing it to menus_create_item_() ? You'd only have to change the code to iterate through the plug_in_defs instead of proc_defs since the domain is stored with the plug_in definition. I'm afraid I don't understand that. Could you please explain it again? -- Servus, Daniel
Re: PROPOSAL: New i18n solution
Hi, I'd recommend gimp_plugin_domain_add (gchar *domain_name) and gimp_plugin_domain_add_with_path (gchar *domain_name, gchar *domain_path) because it IMHO fits better into the namespace and is more obvious than to have just 1 function with two meanings. Ok, I'll change it then and provide two wrappers for one PDB call. I sent a newer patch in my last mail. It should do everything we need for now. No, it will most likely crash the Gimp (explanation of the usage of GSList in a private mail) and it won't work the first time the plug_in is started. I totally agree with this solution, so let's finalize it and get it into the tree. I'll check my code in in a few minutes. Should provide a framework to add the rest upon. While working on the code I came across a new idea which would simplify things quite a bit eventually: The plugins create their menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why not use the knowledge about the domain_name the translated string is to be found in and only look it up in that domain by passing it to menus_create_item_() ? You'd only have to change the code to iterate through the plug_in_defs instead of proc_defs since the domain is stored with the plug_in definition. I'm afraid I don't understand that. Could you please explain it again? Ok, I'll try: Right now we will have to iterate through all domains when trying to translate the menus. Since we know what domain the plugin is in, we are able to choose the right one when its procedures try to install the menupath. Since that is done from plug_in.c it would be possible to pass the domain to the menu_item_factory code. Of course we will still have to bind to all domains in our list. Salut, Sven PS: BTW, I did not ment you and Marc in my comment about the print plugin. Why do you think so? But I might be at least partly guilty ...
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: No, that won't work. Of course you need to hook somewhere into plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins won't be able to register their domain on the first call. Of course you are right, just a braino. The only thing missing now is the pluginrc write code. Huh? The info is already written into the pluginrc! I didn't say what I mean (TM), I meant the PDB code. New patch appended. -- Servus, Daniel diff32.gz
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, 22 Feb 2000, [EMAIL PROTECTED] wrote: On 22 Feb, Manish Singh wrote: True, although we have a couple other inconsistencies already. The coding style needs to be the same as the rest of gimp though. I tried to bring it as near as possible. Of course a lot things could be better I noticed two obvious differences in your code: it does not use two spaces for indentation (the default in Emacs and the recommended GNU style) and there is no space between the function names and the opening parenthesis for the arguments. I suggest that you use a recent version of GNU indent to process your source code and re-indent everything automatically, or that you use Emacs with the default settings (no modifications in a ~/.emacs file) and call indent-region on the whole file. I did not like the GNU style at first (especially the space before the opening parenthesis) but now I understand that it is very important to keep a consistent coding style in each project, because it keeps the code manageable and maintainable. So I always use whatever coding style is recommended for the each project, even if this means that I have to format my patches differently for the Gimp and for a Linux driver, for instance. Since the Gimp uses the GNU style, I think that it is important to follow the GNU coding guidelines faithfully. While we are on the subject of coding style, there are two areas of the Gimp that are not using a consistent coding style: the Script-Fu scripts and, to a lesser extent, the Perl scripts. Is there a recommended style for these? It's not that much code, and does fix a gaping hole in the i18n framework for plugins not distributed with gimp. Especially if we want 1.2 to last a while.. That's absolutely right. Yup! Me too (tm). -Raphael
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 Feb, Raphael Quinet wrote: I did not like the GNU style at first (especially the space before the opening parenthesis) but now I understand that it is very important to keep a consistent coding style in each project, because it keeps the code manageable and maintainable. So I always use whatever coding style is recommended for the each project, even if this means that I have to format my patches differently for the Gimp and for a Linux driver, for instance. Since the Gimp uses the GNU style, I think that it is important to follow the GNU coding guidelines faithfully. Okay, will turn from the Standard vi indention into GNU coding style. BTW: While browsing the code I saw some file not matching ANY standard like xcf.h. It has neither a GNU header nor any guardings It's not that much code, and does fix a gaping hole in the i18n framework for plugins not distributed with gimp. Especially if we want 1.2 to last a while.. That's absolutely right. Yup! Me too (tm). Glad to hear that. -- Servus, Daniel
Re: Coding style (was: PROPOSAL: New i18n solution)
Raphael Quinet said... | |I did not like the GNU style at first (especially the space before the |opening parenthesis) I still don't. Two spaces just isn't enough. Three or four is much better. And I like space before the paren only if it isn't after a function or procedure name. |but now I understand that it is very important to |keep a consistent coding style in each project, because it keeps the |code manageable and maintainable. So I always use whatever coding |style is recommended for the each project, even if this means that I |have to format my patches differently for the Gimp and for a Linux |driver, for instance. Since the Gimp uses the GNU style, I think that |it is important to follow the GNU coding guidelines faithfully. I use to feel this way. But now, so long as each file has a consisten, reasonable style (or preferably, package of files, say a directory), I'm happy. |While we are on the subject of coding style, there are two areas of |the Gimp that are not using a consistent coding style: the Script-Fu |scripts and, to a lesser extent, the Perl scripts. Is there a |recommended style for these? I handle perl as closely as possible to how I handle C. -Miles
Re: PROPOSAL: New i18n solution
Hi, This idea will cirumvent most of the problems which gettext alone just can't deal with. It's little and as such not very likely to introduce many new bugs. With the usage of static array and buffer lengths you demonstrated in your patch it will most likely introduce one or two new bugs, but that could easily be hacked up a little cleaner I also don't like the format of the localerc you proposed since it doesn't look like the other files in ~/.gimp-1.1. Why not use the scheme-like syntax people are used to use and that the gimp can parse anyway? It would allow us to ship GIMP 1.2 with the possibility to add plugins which will also benefit from localisation without any hassle. I'm not yet convinced that this goal is worth all the hassle. What do other people on this list think about this? Salut, Sven
Re: PROPOSAL: New i18n solution
On Tue, Feb 22, 2000 at 10:50:55AM +0100, Sven Neumann wrote: Hi, This idea will cirumvent most of the problems which gettext alone just can't deal with. It's little and as such not very likely to introduce many new bugs. With the usage of static array and buffer lengths you demonstrated in your patch it will most likely introduce one or two new bugs, but that could easily be hacked up a little cleaner I also don't like the format of the localerc you proposed since it doesn't look like the other files in ~/.gimp-1.1. Why not use the scheme-like syntax people are used to use and that the gimp can parse anyway? True, although we have a couple other inconsistencies already. The coding style needs to be the same as the rest of gimp though. It would allow us to ship GIMP 1.2 with the possibility to add plugins which will also benefit from localisation without any hassle. I'm not yet convinced that this goal is worth all the hassle. What do other people on this list think about this? It's not that much code, and does fix a gaping hole in the i18n framework for plugins not distributed with gimp. Especially if we want 1.2 to last a while.. -Yosh
Re: PROPOSAL: New i18n solution
On 22 Feb, Sven Neumann wrote: With the usage of static array and buffer lengths you demonstrated in your patch it will most likely introduce one or two new bugs, but that could easily be hacked up a little cleaner Of course I could have used a linked list, but I'm not sure if it's worth using it. I also don't like the format of the localerc you proposed since it doesn't look like the other files in ~/.gimp-1.1. Why not use the scheme-like syntax people are used to use and that the gimp can parse anyway? I'd like to avoid having to extend the parser from GIMP because I don't need much functionality and this would surely introduce more bugs. But if this is a real concern, then I'll do it together with point 1. I'm not yet convinced that this goal is worth all the hassle. What do other people on this list think about this? If we don't change it know we'll be shipping 1.2 with crippled localisation support, since the number of plugins is increasing constantly and we're trying to get rid of some in the main distribution I really thing that something like this is a really must-have. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 22 Feb, Manish Singh wrote: True, although we have a couple other inconsistencies already. The coding style needs to be the same as the rest of gimp though. I tried to bring it as near as possible. Of course a lot things could be better It's not that much code, and does fix a gaping hole in the i18n framework for plugins not distributed with gimp. Especially if we want 1.2 to last a while.. That's absolutely right. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On Tue, 22 Feb 2000, Sven Neumann wrote: I also don't like the format of the localerc you proposed since it doesn't look like the other files in ~/.gimp-1.1. Why not use the scheme-like syntax people are used to use and that the gimp can parse anyway? I agree strongly with this... there are already too many different configuration styles; although I don't like scheme, it's consistent (and as sven says, there are libs to handle it already) I'm not yet convinced that this goal is worth all the hassle. What do other people on this list think about this? I think that the current quality of localization support could reasonably considered a 'bug'. (Replying in the negative here is my way of avoiding saying "me too" to the rest of this thread. Whoops, said it anyway...) --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu PS: please prune my address from your reply headers. I *DO* subscribe to this list.
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, Feb 22, 2000 at 02:59:18PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote: scripts and, to a lesser extent, the Perl scripts. Is there a recommended style for these? Yes, just copy mine ;) For perl-only-syntax-questions, the reference should be "perldoc perlstyle". All the remaining questions (which excludes syntax, and includes things like "how to add documentation", "how to name fucntions etc.." should go into it's own style-document that I plan to write since, well, years or so). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: PROPOSAL: New i18n solution
On Tue, Feb 22, 2000 at 10:50:55AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: I'm not yet convinced that this goal is worth all the hassle. What do other people on this list think about this? Being able to add plug-ins with i18n support is _extremely_ important. Unless the release would be delayed it should be given priority. Remember that gimp-1.2 will be there to stay for a long time, presumably. If the obvious problems with that solution is fixed (rc-format...), it looks feasible to me. Especially since the original "solution" to the i18n problems "officially" has the status of an imperfect hack. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, Feb 22, 2000 at 03:56:44PM +0100, [EMAIL PROTECTED] wrote: Okay, will turn from the Standard vi indention into GNU coding style. "Standard vi indentation" is fine. Just follow the GNU coding style on when to indent, and when not (and when to add spaces, when not...) ;) The idea, however, is very sane. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Coding style (was: PROPOSAL: New i18n solution)
Uhm, I use vim and vim uses tabs by default and doesn't indent
the { after an if like GNU suggests. Du you have working settings to
achieve this?
I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentation style. If you tweak it a bit it may work for GNU
indentation style. You can look at it here:
http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html
Please tell me if this works or if you had to change something; I'd
like to keep that part of the programming guidelines as accurate as
possible.
Sorry if this is not of any help, I don't do vi :-)
Federico
Re: PROPOSAL: New i18n solution
Hi, [ ... many thought about localerc deleted ... ] Well, you are right in all your points. I just decided to use a new file because I don't need much functionality and therefore could keep it simple as well as the functions in GIMP and libgimp to deal with it. IMHO adding lines into the pluginrc is much easier than to add code to parse another file. So why, I ask you, don't we just put the locale information into the pluginrc. It should be trivial to extend the parser to optionally read two additional lines after the proc-args in the form of: (locale-domain "funky_plugin") (locale-path "~/.gimp-1.1/po") Yes, this was an idea, too. But like you said: We'd - need to expand the parser. Which just means adding another token to the parser code. You can't do much wrong here. - need to check the domainlist for duplicated entries on every addition of a new domain otherwise we'd have possibly hundreds of gettext calls for a translation lookup. Which you will have to do in any case. Actually I don't see hundreds of internationalized plugins in addition to the ones that come with gimp and even if there were hundreds, iterating through a list of strings and comparing them is pretty fast. If that's not enough, we could always a hash... - need to add parsing functionality to libgimp to write the entries to pluginrc. Eeek, no! Libgimp doesn't have to know much about this at all. The plugin would just call a second special gimp_install_domain() procedure if it needs to register a domain. Of course this means adding a new type to the gimpprotocol, but I see no substantial problem in doing so. or instead of the last point we'd need to change the wire protocol and add additional fields to the plugin structures and thus introduce an imcompatibility. Your additional libgimp function introduces the same incompatibility. There's no way to avoid this. To make it clear, I don't speak about changing the gimp_install_procedure(). I totally agree with you that adding a function like gimp_set_domain() to the query() part of the plug-ins is the way to go. I just do not see your point in keeping this very plug-in-specific info out of pluginrc where it belongs. app/plug_in.c contains all the code you need to parse and write the pluginrc. Additionally there's code to keep the plugin info in sync with the actually installed binaries. Your solution is very weak when it comes to that point and I see some substantial problems in that weakness. Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, Feb 22, 2000 at 07:59:21PM +0100, [EMAIL PROTECTED] wrote:
Uhm, I use vim and vim uses tabs by default and doesn't indent
vim, like vi and emacs, has a manual and can be configured quite freely ;)
the { after an if like GNU suggests. Du you have working settings to
achieve this?
One of my 99 config lines is:
set formatoptions=croql cindent cinkeys={,},:,0#,!^F,o,O,e cinoptions={.5s,}0,g0,^-2
sw=2 comments=sr:/*,mb:*,el:*/,://
(However, that's not exactly gnu-style).
HTH,
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 Feb, Federico Mena Quintero wrote: I don't know if this will be useful at all, but the GNOME Programming Guidelines has a snippet for .vimrc to set the Linux kernel indentation style. This is the standard vim style. If you tweak it a bit it may work for GNU indentation style. No, unfortunately I couldn't get vim used to GNU indention style. Please tell me if this works or if you had to change something; I'd like to keep that part of the programming guidelines as accurate as possible. It'd work, but not for GIMPs code. :/ -- Servus, Daniel
Re: Coding style (was: PROPOSAL: New i18n solution)
On Tue, Feb 22, 2000 at 11:54:03PM +0100, [EMAIL PROTECTED] wrote:
Well, that the thing I'm talking about.
I tried this options and think that it doesn't match it very good.
After the first { of a function the source isn't indented for example.
Then, most probably, you have a very very old or broken version of vim
(or maybe you use another editor, or vim in vi-emulation mode). The whole
point of these options is to make indentation automatic and more-or-less
gnu-style.
Anyway, read the docs. It's not black magic to get a little help from your
editor. Or, maybe, change your editor ;)
In any case, giving "my editor does indent differently" is a very poor
reply to a request to follow a specific coding style. You can write
gnu-style using any non-broken editor! So if your editor does indent
differently, use the keys of your keyboard to correct your editor, or read
the docs on how to persuade your editor to do it for you.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: Coding style (was: PROPOSAL: New i18n solution)
If you tweak it a bit it may work for GNU indentation style. No, unfortunately I couldn't get vim used to GNU indention style. Please tell me if this works or if you had to change something; I'd like to keep that part of the programming guidelines as accurate as possible. It'd work, but not for GIMPs code. :/ Oh, well. Thanks anyway. Please tell me if you find a way to make it work; other people may find it useful. Federico
Re: PROPOSAL: New i18n solution
Hi, Actually I don't see hundreds of internationalized plugins in addition to the ones that come with gimp But even those will have their own entry. One entry per plugin. Considering the amount of plugins we ship with GIMP nowadays this would alone lead above hundred entries. Why should they have an entry? The current solution for the plugins distributed with The GIMP works reasonably good. I don't see why we should ditch the hardcoded path in favor of a config file the user will be able to mess with. I thought your proposal would only be a hook for additional plugins?! There's no way to avoid this. There is a way, my way. I was speaking about the fact that whatever solution we come up with will not be backward compatible. It should however be robust and shouldn't keep old plugins from running. I will have to look through the code in app/plug_in.c a little more, but I think I was wrong in my last mail and there's no need to change the wire protocol at all. I just do not see your point in keeping this very plug-in-specific info out of pluginrc where it belongs. app/plug_in.c contains all the code you need to parse and write the pluginrc. Additionally there's code to keep the plugin info in sync with the actually installed binaries. Your solution is very weak when it comes to that point and I see some substantial problems in that weakness. And I see bigger problems in changing all the parse and wireprotocol code to add such a small "feature" (it's more a bugfix). The amount of code-changes is IMHO more or less equal. The small feature you want to add should be well-thought and I don't see why you simply wipe away the arguments have I put up against your solution. Don't tell me that you have spent days to create your patch and don't want your hard work to be discarded. Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 February, 2000 - [EMAIL PROTECTED] sent me these 0.6K bytes:
On 22 Feb, Federico Mena Quintero wrote:
I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentation style.
This is the standard vim style.
If you tweak it a bit it may work for GNU indentation style.
No, unfortunately I couldn't get vim used to GNU indention style.
:set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0
Works most of the case.. (maybe not perfect, but..)
/Tomas
--
Tomas Ögren, [EMAIL PROTECTED], http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
Re: PROPOSAL: New i18n solution
Hi, I have thought about the problem a little more and there's one question that has not been addressed until now. How should the plugin now where its mo-file will be installed? If we want to stay with the existing procedure that the plug-in may be installed in a configured list of paths, it does IMHO not make sense to hardcode the path to the mo-file into the plugin so that it can register it together with its domain. The only solution I came with up until now is to have a configurable list of po-paths defaulting to the standard path for message catalogs $prefix/share/locale and to ~/gimp/locale. The core would then have to try to bindtextdomain() to all possible paths until success (or total failure if no message catalog was found). Is there another solution for this? Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
On 23 Feb, Marc Lehmann wrote: Then, most probably, you have a very very old or broken version of vim (or maybe you use another editor, or vim in vi-emulation mode). Actually it's the latest stable version of vim. The whole point of these options is to make indentation automatic and more-or-less gnu-style. I was told that the style I used before is not acceptable as GNU style so I guess it's the less in "more-or-less". In any case, giving "my editor does indent differently" is a very poor reply to a request to follow a specific coding style. Well, Marc, if you followed this list then you'd know that I already posted an well indented and improved version of my patch. It was just a kind of a BTW note that I can't bring my editor to automatically create this indention style. You can write gnu-style using any non-broken editor! So if your editor does indent differently, use the keys of your keyboard to correct your editor, or read the docs on how to persuade your editor to do it for you. This seems impossible, but fortunately indent is working quite nice for me so this is now just an annoyance no "problem" anymore. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: The current solution for the plugins distributed with The GIMP works reasonably good. Really? I wouldn't call "we have to pre-add the menuentries to GIMPs core source otherwise it wouldn't work" working good. Actually my patch doesn't really address those problems, but the current code for plugin localisaing is more or lass an evil hack. I don't see why we should ditch the hardcoded path in favor of a config file the user will be able to mess with. I thought your proposal would only be a hook for additional plugins?! It was meant such, but from your description it seemed to me that you'd like to add those entries to ALL plugins. From your answer I can see that this was just a misunderstanding. Sorry, Sven. But this make it even harder to modify the parser like you'd like since it's only usable for a fixed number of arguments. It would work to insert those parameters before the pdb-args but that would a) be incompatible and b) mean that every plugin must have such an entry. I was speaking about the fact that whatever solution we come up with will not be backward compatible. Of course it will or at least should try to be. My current solution for example is. And your suggested solution will also as long as you don't touch the wire protocol. I will have to look through the code in app/plug_in.c a little more, but I think I was wrong in my last mail and there's no need to change the wire protocol at all. It would be really bad to do so. And even worse: This code is very simple to break, just look at it and it won't compile on DEC Alpha anymore; another look and it will cause every plugin under Solaris to fail. :( The amount of code-changes is IMHO more or less equal. The small feature you want to add should be well-thought and I don't see why you simply wipe away the arguments have I put up against your solution. Of course I try to wipe them away if they seem not reasonable or correct to me, that's how argumentation works. HOWEVER this doesn't mean that I don't care about your thoughts, they are really helpful and result in new ideas in my head. Just to clarify what I do think of: I'd like to have this done as simple as possible that means: - No PDB calls - No wire protocol changes There should be a simple libgimp call which allows plugins to register themselves in a new domain. If the domain is already available, check whether the path matches (not done in my patch yet!), if not simply add it. The GIMP on the other side should simply be able to get all the registered domains and to do the right things when gimpgettext() is called. Sven, your ideas are very nice but they are neither simple nor so easy to implement like mine. Please consider that we have already feature freeze, are trying to get a stable version out and just don't have the time for a fullfeatured platinum solution. Don't tell me that you have spent days to create your patch and don't want your hard work to be discarded. Sarkasm on GOD, I spend days without anything to eat and drink in my room just to get this idea into a working patch. PLEASE don't blow it away! Sarkasm off Sven, if you have good ideas, tell them to me and the world, any ideas are really appreciated. My only goal is to do my very best to get a new stable release of this great project done ASAP. I don't care about anything else at the moment and would rather like to concentrate on the GIMP instead of wasting time with flaming. -- Servus, Daniel
