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
ANNOUNCE: gimp-print 3.1.0
This is the first version on the 3.1 (development) series. It is available at http://gimp-print.sourceforge.net. In addition to the plug-in for the Gimp, the same source base is used as the nucleus of a GhostScript driver to support Epson Stylus printers. Gimp developers, should I send these announcements to gimp-developer, or should individuals simply subscribe to gimp-print-announce? Also, any other suggestions about where I should send this announcement? The release notes follow: This is the Print plugin for the Gimp, version 3.1.0. This is a development release, the first on the 3.1 branch. If this software causes your print head to zoom off the end of your printer, spilling ink all over your 1000 year old Persian rug, don't blame us. Remember, you installed the software. This software also comes with a GhostScript driver for Epson Stylus printers. The support for Epson Stylus printers in the GhostScript driver is identical to the support for these printers in the Print plugin -- they use the identical code base. This plugin can be compiled against either Gimp 1.1 or 1.0. Print 3.1.0 contains the following user-visible improvements over Print 3.0.5, the version distributed with the Gimp 1.1.17: 1) Preliminary support for Canon BubbleJet printers (specifically the BJC6000). 2) Preliminary support for the Epson Stylus Color 440/640/740/900 and Stylus Photo 750/1200 printers. These printers should in theory work in all modes, although that has not been comprehensively tested. 1440 dpi mode on the 900 in particular may not work. There is also pre-preliminary support for the Stylus Photo 870 and 1270 based on the published specifications. This driver is completely untuned for these printers at present. 3) Ability to position the image on the page to the point (1/72", or about .35 mm), along with a more accurate depiction of the positioning on the page. 4) One-click ability to scale to the image resolution (Gimp 1.1 only). 5) Much better handling of the saved state (printrc file), including saving of parameters related to file output. 6) Utilities (in various states of completion) to reconstitute an image from a print file. 7) Bug fixes for density in indexed and gray modes, and for excess pseudo-black printing in general. There are additional improvements over Print 2.0.2 (the version distributed with Gimp 1.1.11 and earlier) too numerous to list here. -- 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
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
Hi, 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? Oh well, there are more areas. Not even the core strictly follows a common style. But this has got much better since Mitch and me got infected with the "indentation paranoia". If we take care that new code is correctly formatted, it's only a matter of time until all code got overworked. But if you look into the plugins you will find a collection of all sorts of coding styles and even some examples of the total lack of it. I do not think that it is necessary to reformat all scripts, but since you wanted to go through most Script-Fu's anyway, I suggest you use the indendation emacs proposes for Scheme code. I've just checked and IMHO it's a useful default. Salut, Sven
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
3.0.8
I did a 3.0.7 this evening, and then decided to port a few of the juicier GUI features over from the mainline (specifically the separation of printrc save from cancel and print, the positioning entry boxes, and the correct sizing computations), so I quickly did a 3.0.8. I sent Sven the patches from 3.0.6, and in addition put it up on Sourceforge. 3.0.6-3.0.7 contains some important bug fixes, in addition.
Crash in Gimp 1.1.7 on Solaris 8.
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
S
#0 0xfef8a35c in g_on_error_stack_trace ()
#1 0xfef8a16c in g_on_error_query ()
#2 0xba3a0 in gimp_fatal_error ()
#3 0x1576a8 in on_signal ()
#4 signal handler called
#5 0x177858 in color_pixels ()
#6 0x18ceb0 in paintbrush_motion ()
#7 0x18d2d8 in paintbrush_non_gui_paint_func ()
#8 0x18d524 in paintbrush_non_gui_default ()
#9 0x1eca54 in paintbrush_default_invoker ()
#10 0x1b8778 in procedural_db_execute ()
#11 0x1b8c04 in procedural_db_run_proc ()
#12 0xdadc8 in gimage_mask_stroke ()
#13 0x8a7bc in edit_stroke_cmd_callback ()
#14 0xff1c1724 in gtk_item_factory_callback_marshal ()
#15 0xff1e9160 in gtk_marshal_NONE__NONE ()
#16 0xff260228 in gtk_handlers_run ()
#17 0xff25e38c in gtk_signal_real_emit ()
#18 0xff2595bc in gtk_signal_emit ()
#19 0xff2e08d8 in gtk_widget_activate ()
#20 0xff1fcce0 in gtk_menu_shell_activate_item ()
#21 0xff1fa8dc in gtk_menu_shell_button_release ()
#22 0xff1e8730 in gtk_marshal_BOOL__POINTER ()
#23 0xff25e434 in gtk_signal_real_emit ()
#24 0xff2595bc in gtk_signal_emit ()
#25 0xff2e04d8 in gtk_widget_event ()
#26 0xff1e83fc in gtk_propagate_event ()
#27 0xff1e5f48 in gtk_main_do_event ()
#28 0xff02c9b0 in gdk_event_dispatch ()
#29 0xfef945dc in g_main_dispatch ()
#30 0xfef953d0 in g_main_iterate ()
#31 0xfef9576c in g_main_run ()
#32 0xff1e4eb4 in gtk_main ()
#33 0x157550 in main ()
Under the debugger :
(dbx) cont
signal BUS (invalid address alignment) in color_pixels at 0x177858
color_pixels+0x110: ld [%l0], %i1
(dbx) where
=[1] color_pixels(0x847bb0, 0xffbedbb2, 0x19, 0x4, 0x0, 0x0), at
0x177858
[2] paintbrush_motion(0x329110, 0x7bf940, 0x287758, 0x0, 0x0, 0x0), at
0x18cea8
[3] paintbrush_non_gui_paint_func(0x329110, 0x7bf940, 0x0, 0x0,
0x4052c000, 0x0), at 0x18d2d0
[4] paintbrush_non_gui_default(0x7bf940, 0x52, 0x8d5cb8, 0x0, 0x0,
0x0), at 0x18d51c
[5] paintbrush_default_invoker(0x847b18, 0x2bfea8, 0xfed36000, 0x23c0,
0x21dc0, 0xfecc0d48), at 0x1eca4c
[6] procedural_db_execute(0x2bfea8, 0x847b18, 0x0, 0x0, 0x0,
0x8d25f0), at 0x1b8770
[7] procedural_db_run_proc(0x2bfea8, 0xffbedf0c, 0x10, 0x3, 0x0,
0xa4), at 0x1b8bfc
[8] gimage_mask_stroke(0x70d6b0, 0x7bf940, 0x1, 0x0, 0x20478,
0x5f85c0), at 0xdadc0
[9] edit_stroke_cmd_callback(0x5fd140, 0x0, 0x0, 0x0, 0x0, 0x0), at
0x8a7b4
[10] gtk_item_factory_callback_marshal(0x5fd140, 0x5ed940, 0x0, 0x0,
0x0, 0x5fb060), at 0xff1c171c
[11] gtk_marshal_NONE__NONE(0x5fd140, 0xff1c1658, 0x5ed940,
0xffbee218, 0x214e0, 0xfee9b410), at 0xff1e9158
[12] gtk_handlers_run(0x5fcf50, 0xffbee184, 0x5fd140, 0xffbee218, 0x0,
0xffbee510), at 0xff260220
[13] gtk_signal_real_emit(0x5fd140, 0x5b, 0xffbee218, 0x1, 0x0,
0xffbee218), at 0xff25e384
[14] gtk_signal_emit(0x5fd140, 0x5b, 0x0, 0xffbeece4, 0x20, 0x330fd0),
at 0xff2595b4
[15] gtk_widget_activate(0x5fd140, 0x5f59c0, 0x330ff0, 0x330fd0,
0x32d458, 0x0), at 0xff2e08d0
[16] gtk_menu_shell_activate_item(0x5f9970, 0x5fd140, 0x1, 0x0,
0x20478, 0x5f85c0), at 0xff1fccd8
[17] gtk_menu_shell_button_release(0x5f9970, 0x3c0de8, 0x0, 0x74b610,
0x0, 0x6a4735), at 0xff1fa8d4
[18] gtk_marshal_BOOL__POINTER(0x5f9970, 0xff1fa4a8, 0x0, 0xffbee820,
0x0, 0x0), at 0xff1e8728
[19] gtk_signal_real_emit(0x5f9970, 0x15, 0xffbee820, 0x0, 0x0,
0xffbee838), at 0xff25e42c
[20] gtk_signal_emit(0x5f9970, 0x15, 0x3c0de8, 0xffbeeba0, 0x0,
0xfeea6134), at 0xff2595b4
[21] gtk_widget_event(0x5f9970, 0x3c0de8, 0x0, 0x8, 0x0, 0x7c00462),
at 0xff2e04d0
[22] gtk_propagate_event(0x5fd140, 0x3c0de8, 0x32d458, 0xffbeece4,
0x20, 0x330fd0), at 0xff1e83f4
[23] gtk_main_do_event(0x3c0de8, 0x0, 0x330ff0, 0x330fd0, 0x32d458,
0x0), at 0xff1e5f40
[24] gdk_event_dispatch(0x0, 0xffbeee48, 0x0, 0x0, 0x20478,
0xfef95d2c), at 0xff02c9a8
[25] g_main_dispatch(0xffbeee48, 0x3328f0, 0x1, 0x74b610, 0x0,
0x6a4735), at 0xfef945d4
[26] g_main_iterate(0x1, 0x1, 0x0, 0x0, 0x0, 0x0), at 0xfef953c8
[27] g_main_run(0x6a4730, 0x6a4730, 0x0, 0x0, 0x0, 0x0), at 0xfef95764
[28] gtk_main(0x0, 0x6, 0x1575b0, 0x0, 0x33b548, 0x3305a0), at
0xff1e4eac
[29] main(0x1, 0xffbef024, 0xffbef02c, 0x26fc00, 0x0, 0x0), at
0x157548
The comment in the code is rather explicit !!! It crashes.
void
color_pixels (unsigned char *dest,
const unsigned char *color,
intw,
intbytes)
{
/* dest % bytes and color % bytes must be 0 or we will crash
when bytes = 2 or 4.
Is this safe to assume? Lets find out.
This is 4-7X as fast as the simple version.
*/
register unsigned char c0, c1, c2;
register guint32 *longd, longc;
register guint16 *shortd, shortc;
switch (bytes)
{
case
I'm away till 2000-03-13
I'll be away from now until March, 13. Chances are low that I will be able to answer mail during that time. If you visit the CeBIT, be sure to meet me at the Linux international booth, and stay away from non-free software! If you don't come to the CeBIT, consider visiting the 2nd German Perl-Workshop instead ;) "But I do have this important question!" If you haven't heard back from me yet, you probably won't unless it's _really_ important. - for gcc-related questions, use the gcc mailinglist(s) (see http://gcc.gnu.org/). - for pgcc-related questions, use the pgcc mailinglist (see http://www.goof.com/pcg/). - for gimp- gimp-perl-related questions, use the gimp-developers mailinglist (http://www.gimp.org/) or ask the gimp-perl mailinglist (see http://gimp.pages.de/). - for other perl-related questions, use the comp.lang.perl.modules or comp.lang.perl.moderated newgroups. Thanks, Marc -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Fixed?
On Tue, Feb 22, 2000 at 09:37:28PM +0100, [EMAIL PROTECTED] wrote: Hiho tigert, Can you still reproce bug #6444 or is it like the others I recently merged together with this one, fixed? Yes, my gimp is built on Feb 22th from CVS. I get this gdk error: Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 37493 error_code 9 request_code 14 minor_code 0 ** WARNING **: wire_read: unexpected EOF (plug-in crashed?) the it burns to ashes. However it might be related to something else, I have had a lot of crashes in the last week or so. In random places, trying to figure out where. Some seem to be related to undo stuff. Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Magicless file formats
Targa files have no magic header, and cannot be reliably identified that way.
The TGA plugin tried to register some nonsense magic string which didn't work
anyway, and any attempt to load a TGA file without explicitly selecting the
load format will usually cause gimp to handle it as a group 3 fax or
something. (A correct TGA magic pattern *could* be constructed, but it would
be so generic that it would match a lot of other files as well.)
A reasonable solution is to match the file suffix against all formats that
do not have a magic pattern first, before any attempt to determine the file
type by the header.
I'm a newcomer to gimp development so I didn't know where to send the patch,
but it is short so I included it here.
--- gimp-1.1.17/plug-ins/common/tga.c.orig Wed Feb 23 01:19:04 2000
+++ gimp-1.1.17/plug-ins/common/tga.c Wed Feb 23 03:44:05 2000
@@ -252,10 +252,10 @@
nsave_args, 0,
save_args, NULL);
- gimp_register_magic_load_handler ("file_tga_load",
- "tga",
- "",
- "0,byte,10,2,byte,1,3,byte,0,3,byte,9");
+ gimp_register_load_handler ("file_tga_load",
+ "tga",
+ "");
+
gimp_register_save_handler ("file_tga_save",
"tga",
"");
--- gimp-1.1.17/app/fileops.c.orig Wed Feb 23 01:21:27 2000
+++ gimp-1.1.17/app/fileops.c Wed Feb 23 01:42:04 2000
@@ -1754,16 +1754,64 @@
gtk_widget_set_sensitive (GTK_WIDGET (filesave), TRUE);
}
+static PlugInProcDef *
+file_proc_find_by_name(GSList *procs,
+ gchar *filename,
+ gboolean skip_magic)
+{
+ GSList *p;
+ gchar *ext = strrchr(filename, '.');
+ if(ext)
+ext++;
+
+ for(p = procs; p; p = p-next)
+{
+ PlugInProcDef *proc = p-data;
+ GSList *prefixes;
+
+ if(skip_magic proc-magics_list)
+ continue;
+ for(prefixes = proc-prefixes_list; prefixes; prefixes = prefixes-next)
+ {
+ if(strncmp(filename, prefixes-data, strlen(prefixes-data)) == 0)
+ return proc;
+ }
+ }
+
+ for(p = procs; p; p = p-next)
+{
+ PlugInProcDef *proc = p-data;
+ GSList *extensions;
+
+ for(extensions = proc-extensions_list; ext extensions;
+ extensions = extensions-next)
+ {
+ gchar *p1 = ext;
+ gchar *p2 = (gchar *)extensions-data;
+
+ if(skip_magic proc-magics_list)
+ continue;
+ while (*p1 *p2)
+ {
+ if (tolower (*p1) != tolower (*p2))
+ break;
+ p1++;
+ p2++;
+ }
+ if (!(*p1) !(*p2))
+ return proc;
+ }
+}
+
+ return NULL;
+}
+
PlugInProcDef *
file_proc_find (GSList *procs,
gchar *filename)
{
PlugInProcDef *file_proc, *size_matched_proc;
GSList *all_procs = procs;
- GSList *extensions;
- GSList *prefixes;
- gchar *extension;
- gchar *p1, *p2;
FILE *ifp = NULL;
gint head_size = -2, size_match_count = 0;
gint match_val;
@@ -1771,11 +1819,11 @@
size_matched_proc = NULL;
- extension = strrchr (filename, '.');
- if (extension)
-extension += 1;
+ /* First, check magicless prefixes/suffixes */
+ if( (file_proc = file_proc_find_by_name(all_procs, filename, TRUE)) != NULL)
+return file_proc;
- /* At first look for magics */
+ /* Then look for magics */
while (procs)
{
file_proc = procs-data;
@@ -1810,46 +1858,8 @@
if (size_match_count == 1)
return (size_matched_proc);
- procs = all_procs;
- while (procs)
-{
- file_proc = procs-data;
- procs = procs-next;
-
- for (prefixes = file_proc-prefixes_list; prefixes; prefixes = prefixes-next)
- {
- p1 = filename;
- p2 = (gchar *) prefixes-data;
-
- if (strncmp (filename, prefixes-data, strlen (prefixes-data)) == 0)
- return file_proc;
- }
- }
-
- procs = all_procs;
- while (procs)
-{
- file_proc = procs-data;
- procs = procs-next;
-
- for (extensions = file_proc-extensions_list; extension extensions;
extensions = extensions-next)
- {
- p1 = extension;
- p2 = (gchar *) extensions-data;
-
- while (*p1 *p2)
- {
- if (tolower (*p1) != tolower (*p2))
- break;
- p1 += 1;
- p2 += 1;
- }
- if (!(*p1) !(*p2))
- return file_proc;
- }
-}
-
- return NULL;
+ /* As a last ditch, try matching by name */
+ return file_proc_find_by_name(all_procs, filename, FALSE);
}
static void
