Re: [Gimp-developer] 1.2 Bug Hunting
Sven Neumann wrote: Hi, went out for some bug-hinting in the 1.2 wilderness tonight and came up with this list of beasts that are still alive and should be killed in 1.2 if possible: #51358 Acquire-screenshot not working with enlightenment http://bugzilla.gnome.org/show_bug.cgi?id=51358 I'm sure it's enlightenments fault ;-) Perhaps we can do something about it anyway... I've had this problem, and it appears to exist only with the version of xwd that's shipped with XFree86 4.0.x where x=2. I upgraded to 4.0.3 and the problem went away. Same problem (with same version of X) existed with WindowMaker too. #51164 Default image comment not set correctly http://bugzilla.gnome.org/show_bug.cgi?id=51164 I've added some comments on how one could be fixed to the report. Not sure what is the correct fix for this. Comments? The default Made with the GIMP comment is hard coded into plug-ins/common/xbm.c - and presumably into the others too. It seems to me that the easiest solution would be to include gtkrc in the relevant plug-ins, and do a read on the gimprc when loading the plug-ins. Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
On Wednesday, 20 Jun 2001, Dave Neary wrote: The default Made with the GIMP comment is hard coded into plug-ins/common/xbm.c - and presumably into the others too. It seems to me that the easiest solution would be to include gtkrc in the relevant plug-ins, and do a read on the gimprc when loading the plug-ins. No. These plugins are sufficiently old that they pre-date parasites. The correct thing to do is ensure that images have the right gimp-comment parasite, and make all the plugins looks at it. In the same way as freshly created images are defaulted to 72 dpi, maybe they should also have a gimp-comment parasite added. File load plugins would then just override the parasite if the file format includes a more specific parasite. I believe current file load plugins than know about parasites wouldn't need modification. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] show jpeg preview time
Hello, I'm using the GIMP to creat image files for my web site. So, I want to know how much time is necessary for loading the images which is saved by jpeg or other file type. It's useful to show loading time in jpeg saving dialog. See attachment file if you interested in it. Thanks. G'bye. Takashi Kido, or Iccii [EMAIL PROTECTED] jpeg-show-cost-time.diff
Re: [Gimp-developer] 1.2 Bug Hunting
On 20 Jun 2001, at 10:27, Dave Neary wrote: Sven Neumann wrote: #51164 Default image comment not set correctly http://bugzilla.gnome.org/show_bug.cgi?id=51164 I've added some comments on how one could be fixed to the report. Not sure what is the correct fix for this. Comments? The default Made with the GIMP comment is hard coded into plug-ins/common/xbm.c - and presumably into the others too. It seems to me that the easiest solution would be to include gtkrc in the relevant plug-ins, and do a read on the gimprc when loading the plug-ins. This is what I could find. I am not a programmer, however, and may be mistaken about which strings do get gettexted and which do not. Made with ... plug-ins/common/gtm.c Created with ... plug-ins/common/csource.c plug-ins/common/jpeg.c plug-ins/common/tiff.c xbm.c, however, does seem to use gettext: INIT_I18N_UI(); strncpy (xsvals.comment, _(Created with The GIMP), MAX_COMMENT); Also I noticed that when saving TIFFs, sometimes the 'hard coded' comment is used, sometimes the one I supplied in the preferences. The difference seems to be between images that I acquired from the Windows clipboard and images that I started with File/New. Is that at all possible? I will do some more testing. (HTH) -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] show jpeg preview time
On Wednesday, 20 Jun 2001, Iccii wrote: I'm using the GIMP to creat image files for my web site. So, I want to know how much time is necessary for loading the images which is saved by jpeg or other file type. It's useful to show loading time in jpeg saving dialog. See attachment file if you interested in it. Its a nice patch. I think it should get into the development CVS tree (but probably not the 1.2 stable branch, since this is definitely a new feature). Just one thing: 14.4Kbps means 14.4 * 1000 bits per second, not 14.4 * 1024. Similarly, 10Mbps is 10 * 1000 * 1000 bits per second, not 10 * 1024 * 1024. 1024 is only involved when addresses are, ie for sizes of buffers, memory, files. Never when talking about bandwidth. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] show jpeg preview time
On 20 Jun 2001, at 11:54, Steinar H. Gunderson wrote: On Wed, Jun 20, 2001 at 06:45:23PM +0900, Iccii wrote: I'm using the GIMP to creat image files for my web site. So, I want to know how much time is necessary for loading the images which is saved by jpeg or other file type. It's useful to show loading time in jpeg saving dialog. See attachment file if you interested in it. IMHO, the JPEG dialog box is cluttered up enough as it is. In addition, predicting loading speed is a much more difficult factor than just taking the theoretical maximum of a line -- don't forget that one usually loads a HTML file along with the image, for instance, and one often has multiple images per page. In addition, server load etc. could also influence this. Thus, I don't think such a number makes too much sense :-) I agree. There are too many variables influencing load time on the web. Any good web design reference will tell you what size to limit your files to. What would be nice though, and I hope I am not asking for something that already exists, is a web export filter that shows previews and file sizes of the same image in different formats. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] show jpeg preview time
On Wed, Jun 20, 2001 at 12:21:57PM +0200, Branko Collin wrote: What would be nice though, and I hope I am not asking for something that already exists, is a web export filter that shows previews and file sizes of the same image in different formats. I've seen shareware programs for such things, and I considered implementing it in GIMP once, but I wrote the JPEG previewing functionality instead, which I find quite a lot cleaner and simpler to use (now, the _code_ sucks, but... ;-) ). :-) /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Sven Neumann wrote: Hi, went out for some bug-hinting in the 1.2 wilderness tonight and came up with this list of beasts that are still alive and should be killed in 1.2 if possible: Speaking of bug-hunting... I couldn't build gimp 1.2 (with gcc 2.96 - RedHat's 7.0 prerelease) for the first time recently because of the following line in app/histogram_tool.c: Line 230: gimp_option_menu_set_history (g_list_nth_data (gtk_container_children (GTK_CONTAINER (histogram_tool_dialog-channel_menu)), 1), GIMP_HISTOGRAM_VALUE); The prototype for gimp_option_menu_set_history is void gimp_option_menu_set_history (GtkOptionMenu *option_menu, gpointeruser_data); and GIMP_HISTOGRAM_VALUE is an enum value equal to 0. The problem is hidden with a cast to gpointer. My question is whether this is a compiler bug, or whether a constant 0 is valid as a gpointer value? Does this problem show up in the shiny new gcc 3.0? Is it a case of just upgrading the compiler? Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Hi, Branko Collin [EMAIL PROTECTED] writes: Also I noticed that when saving TIFFs, sometimes the 'hard coded' comment is used, sometimes the one I supplied in the preferences. The difference seems to be between images that I acquired from the Windows clipboard and images that I started with File/New. Is that at all possible? Yes, it's exactly the problem described in the bug-report. Gimp does only attach a gimp-comment parasite to an image if it is created using File-New. Other ways to create an image (Paste as New, Screenshot, Clipboard) do not attach the default comment. If you save an image that has no comment parasite attached, the save plug-ins use their hardcoded value. If we'd fix this by making gimp_image_new() attach a default comment parasite (just like it sets the default resolution), all images touched by The GIMP would get the default comment unless they already have a comment and the respective load plug-in takes care of setting it as a parasite. Another way to fix this is to change places like Paste as New, Screenshot, Clipboard etc. where images are created and let them take care of attaching the default comment. I don't consider this problem serious enough to insist on having it fixed in 1.2. If it turns out that there is no simple solution, we'll tackle this problem in the 1.3 tree. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Sven Neumann wrote: Hi, I'll look into fixing this later or wait for a patch. Please report if you find more of these. Patch attached. If I find any more I'll let you know... I did think that an integer constant 0 could be used in a pointer context without a cast, though... Salut, Sven Cheers, Dave. PS. I forgot the patch the last time... -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ? GINT_TO_POINTER.patch Index: app/histogram_tool.c === RCS file: /cvs/gnome/gimp/app/Attic/histogram_tool.c,v retrieving revision 1.40.2.1 diff -u -r1.40.2.1 histogram_tool.c --- app/histogram_tool.c2001/05/06 21:15:05 1.40.2.1 +++ app/histogram_tool.c2001/06/20 11:05:43 @@ -227,9 +227,15 @@ /* Channels can only have value histograms; reconfigure channel menu. */ /* Note: gimp_histogram_get_mean() in gimphistogram.c. garo 5/7/2001 */ histogram_tool_dialog-channel = GIMP_HISTOGRAM_VALUE; - gimp_option_menu_set_history (g_list_nth_data (gtk_container_children (GTK_CONTAINER (histogram_tool_dialog-channel_menu)), 1), GIMP_HISTOGRAM_VALUE); + gimp_option_menu_set_history (g_list_nth_data + (gtk_container_children +(GTK_CONTAINER + (histogram_tool_dialog-channel_menu)), +1), + GINT_TO_POINTER (GIMP_HISTOGRAM_VALUE)); gtk_widget_hide (histogram_tool_dialog-channel_menu); - histogram_tool_gradient_draw (histogram_tool_dialog-gradient, GIMP_HISTOGRAM_VALUE); + histogram_tool_gradient_draw (histogram_tool_dialog-gradient, + GIMP_HISTOGRAM_VALUE); } /* calculate the histogram */
Re: [Gimp-developer] handling of image comments (was 1.2 Bug Hunting)
On Wed, 20 Jun 2001, Sven Neumann wrote: [about http://bugzilla.gnome.org/show_bug.cgi?id=51164 ] Yes, it's exactly the problem described in the bug-report. Gimp does only attach a gimp-comment parasite to an image if it is created using File-New. Other ways to create an image (Paste as New, Screenshot, Clipboard) do not attach the default comment. If you save an image that has no comment parasite attached, the save plug-ins use their hardcoded value. The real problem is that the plug-ins use their hardcoded value. If they would use the value specified by the user (saved in gimprc), then there would be no surprises for the user. If we'd fix this by making gimp_image_new() attach a default comment parasite (just like it sets the default resolution), all images touched by The GIMP would get the default comment unless they already have a comment and the respective load plug-in takes care of setting it as a parasite. IMHO this is a bad idea. It would hide the problem from a developer's point of view, but I am not sure that it would be really helpful for the average user. Currently, the only places where the users see the image comments are the preferences dialog and the save plug-ins (the parasite editor is for experts only). Therefore, most users (that I have observed) think that the comment is set when the image is saved, not when it is created. This is a problem in the following scenario: - user creates several images or modifies existing images - user goes to the preferences dialog and changes the default comment - user saves all images, expecting them to get the default comment because no comment was set previously for these images Another problem is when an image without comment is loaded and then saved in another format. It is probably not appropriate to add a new image comment saying Created with the Gimp if this image was simply converted. On the other hand, if the user has replaced the default comment with a copyright message, she probably wants this to be attached to all images by default. The best way to solve this would be the following: - the image comment is never set when creating or loading an image, except if one was already present in the file - in all save plug-ins, add an option replace current comment with default comment (this assumes that the plug-ins get it from gimprc). This would be more convenient for the user, who could then choose if a comment should be added or not, and would also have the opportunity to replace an old comment with the current default value. This is useful for those who change their copyright message and want to update this comment in several files (currently, it is necessary to delete the old comment and re-type or copy the new one in all files). It would also be nice to add the following multiple choice in the preferences dialog, on the same page as the one in which you set the default comment: [ ] do not modify or add image comments [x] add the default comment to the images that have no comment yet [ ] always replace the existing comment with the default one Another way to fix this is to change places like Paste as New, Screenshot, Clipboard etc. where images are created and let them take care of attaching the default comment. Same problems as above. I think that it would be better to leave the comment undefined, until the file is saved. I don't consider this problem serious enough to insist on having it fixed in 1.2. If it turns out that there is no simple solution, we'll tackle this problem in the 1.3 tree. Agreed. In general, the handling of image comments and other parasites should be discussed a bit more on this list (so this will probably not be fixed in 1.2). For example, some file formats support comments in 7-bits ASCII only while others support ISO-8859-1, UNICODE or other charsets. Some of them allow only a single line, some of them are much more flexible. There is currently no good conversion between these formats. If you have ever tried to preserve a multi-line comment containing accented characters accross several load/save operations using different image formats, you will know what I mean. There are other parasites that should also be converted (and made more visible to the user than through the parasite editor). See for example the bug report that I entered this morning about the TIFF/EP and EXIF data that is saved by most digital cameras but ignored by the Gimp: http://bugzilla.gnome.org/show_bug.cgi?id=56443 -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] handling of image comments (was 1.2 Bug Hunting)
On Wednesday, 20 Jun 2001, Raphael Quinet wrote: On Wed, 20 Jun 2001, Sven Neumann wrote: If we'd fix this by making gimp_image_new() attach a default comment parasite (just like it sets the default resolution), all images touched by The GIMP would get the default comment unless they already have a comment and the respective load plug-in takes care of setting it as a parasite. I originally held this view. However Raphael makes a persuasive argument why this is a bad idea and I now agree with him. Only images actually generated by the Gimp should have the default comment added. I agree the image properties editor plugin is badly needed. The best way to solve this would be the following: - the image comment is never set when creating or loading an image, except if one was already present in the file - in all save plug-ins, add an option replace current comment with default comment (this assumes that the plug-ins get it from gimprc). Yes. Although I'm not entirely happy about cluttering every save plugin with an extra comment-related box, I can't think of a better way of doing it. It would also be nice to add the following multiple choice in the preferences dialog, on the same page as the one in which you set the default comment: [ ] do not modify or add image comments [x] add the default comment to the images that have no comment yet [ ] always replace the existing comment with the default one Yes. [Should New, Screenshot, Paste as New get comments be default? Quinet says no, only add comment at save time.] I think they should get the comment added when the image is created. I know this means if the user changes the preferences before saving then its not entirely obvious what happens, but I think this should be a rare occurence. All this discussion means that I don't think anything should be done to 1.2 Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Dave Neary wrote: I did think that an integer constant 0 could be used in a pointer context without a cast, though... Hi all, I've confirmed that this code (for the case where the enum value passed is 0) should work in any ANSI conforming compiler (according to the impressarios of comp.lang.c anyway). Whether it's wise to do this is another matter, but in this case it's the compiler that's broken. Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
