Re: [Gimp-developer] Save As JPG Integrated (mockup)
Hi, On Thu, 2007-02-08 at 10:41 +0300, Alexandre Prokoudine wrote: > What I was trying to tell you is that that message exists, but doesn't > show up. Which means that something is broken ;-) It does show up. So the brokeness seems to be on your setup. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
On 2/8/07, Sven Neumann wrote: > > As of 2.3.14 there is not such tooltip. DIsplay of tooltips is enabled > > in preferences. > > There is. I just checked once more (and I had already checked > yesterday). What I was trying to tell you is that that message exists, but doesn't show up. Which means that something is broken ;-) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
Hi, On Wed, 2007-02-07 at 13:13 +0200, Aurimas Juška wrote: > It actually uses GtkDrawingArea. This is related to zoom & cropping > functionality. If we dropped cropping, one of Gimp widgets could be > used. I don't see why you couldn't implement cropping with one of the GimpPreview widgets. > Is there any widget which supports > - zoom in & out > - GIMP quick navigation widget in the corner of the scroll bars > - access to cursor coordinates to give extra control with mouse? GimpZoomPreview Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
Hi, On Thu, 2007-02-08 at 02:36 +0300, Alexandre Prokoudine wrote: > As of 2.3.14 there is not such tooltip. DIsplay of tooltips is enabled > in preferences. There is. I just checked once more (and I had already checked yesterday). Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Comments on code
Hi, On Thu, 2007-02-08 at 01:28 +0100, Mu wrote: > I thought in putting comments in the code as I achieve to > understanding functions and files, and submitting them as patche. I > want to know if you think it is a good idea or it would be a useless > task, or if there is some reason for leaving things as they are now. We would appreciate if someone commented some more of the internal functions with well-written gtk-doc style comments. That would improve the documentation of the core as seen on http://developer.gimp.org/api/2.0/app/index.html Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Crop+Scale (was Save As JPG Integrated)
Hi, On Wed, 2007-02-07 at 10:50 -0800, Akkana Peck wrote: > Crop's Aspect Ratio got a lot easier to manage in 2.3 as opposed to 2.2. > So "crop to a fixed aspect ratio, then rescale" is much easier now -- > presuming you understand aspect ratio and don't mind typing two > colon- separated numbers. (Though I haven't figured out the "<->" > and "Set" buttons, which have no tooltips and don't seem to do > anything, or why you'd want a 1:1 preset button but not presets > for 4:3 or 4:6 or "Keep image's aspect ratio"). If you had read the specification (and I expect all of you to have done that), you would know that the current state of the rectangle tool options panel is far from final. I plan to devote some time to it soon so that hopefully it will look and feel a lot better with the next development release. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
Hi Marco,
if I remember correctly this is fixed by removing the generated files
POTFILES in all po subdirectories. Try this command in the toplevel gimp
source directory:
find . -name POTFILES -exec rm {} \;
Then do a rebuild. The problem here is that the Makefile rules to
generate the files used to be broken. We fixed the Makefiles but there's
no dependency that would cause the broken files to be regenerated.
Sven
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Comments on code
Hello. There's some time I wanted to contribute to a free software project and now I am diving in the code of gimp. I find it quite difficult to know where to start with. One thing that surprised me is the lack of comments in the code. I am used to have at least one comment per function and one for each file explaining what goes there and what it does. I don't know if this is a question of style, but I think it would make things easier for new people aiming to help. I thought in putting comments in the code as I achieve to understanding functions and files, and submitting them as patche. I want to know if you think it is a good idea or it would be a useless task, or if there is some reason for leaving things as they are now. I also want to use this occasion to ask advice in where to start reading and taking familiarity with the gimp code. Thanks, Mu. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
On 2/7/07, Sven Neumann wrote: > Hi, > > On Wed, 2007-02-07 at 05:39 +0300, Alexandre Prokoudine wrote: > > > While we are discussing it, is it possible to add a remark to the > > current dialog that enabling preview also calculates size of resulted > > file? I already heard several times from new users that GIMP doesn't > > calculate resulted JPEG files size at all. This is a tiny change and > > it I believe that it can make it's way to 2.4 > > There's a tooltip on the file-size label for exactly this purpose. As of 2.3.14 there is not such tooltip. DIsplay of tooltips is enabled in preferences. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colorize - Lightness != luminosity?
On Wed, 2007-02-07 at 20:08 +0100, Michael Natterer wrote: > I don't remember the actual math involved and didn't try to follow > your elaborate code path description. When I implemented this it > was pretty clear from the beginning that -100% 'L' would have to > make the image all black and +100% 'L' all white, and all values > in between would be linear interpolations. That's how it was > implemented in the end. > > No voodoo involved :-) > > The only point potentially open for discussion would be what > the proper word for 'L' is. I think Lightness is fine from an end user perspective. The docs need to be updated to reflect the real meaning behind the slider (and it's name - the docs call it "Value" at the moment). The reason this came up at all was that someone asked what units were associated with those sliders, which led me to ask what the real meaning was for each slider. Now I know. :-) I've got a minor patch for the english version of the online docs. I'll submit it to the gimp-docs mailing list. Thanks. -- Michael J. HammelSenior Software Engineer [EMAIL PROTECTED] http://graphics-muse.org -- His men would follow him anywhere, ... but only out of morbid curiosity. -- From a real employee performance evaluation. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Crop+Scale (was Save As JPG Integrated)
On Wed, 07 Feb 2007 19:50:53 +0100, Akkana Peck <[EMAIL PROTECTED]> wrote: > > But I can certainly understand why so many users want Crop+Scale > all in one step. It's a very common operation, and it would be a > shame to offer it, then cripple it by putting it in a plug-in where > the crop has to happen in a small preview area. yes, this makes a lot of sense. Association of crop and scale has no relation to the final image file format. I always work in a lossless format until all cropping scaling and other data processing is done, so I would be very unlikely to associate either of these actions with a save as jpeg operation. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colorize - Lightness != luminosity?
On Wed, 2007-02-07 at 10:23 -0700, Michael J. Hammel wrote: > On Wed, 2007-02-07 at 08:57 +0100, Sven Neumann wrote: > > As far as I understand the dialog doesn't show absolute values for > > Saturation and Lightness but relative ones. Perhaps the Saturation > > slider should also go from -100 to +100 then. > > Saturation appears to be absolute. Lightness is relative. See below. Exactly. I don't remember the actual math involved and didn't try to follow your elaborate code path description. When I implemented this it was pretty clear from the beginning that -100% 'L' would have to make the image all black and +100% 'L' all white, and all values in between would be linear interpolations. That's how it was implemented in the end. No voodoo involved :-) The only point potentially open for discussion would be what the proper word for 'L' is. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Crop+Scale (was Save As JPG Integrated)
Aurimas Juška writes: > The idea is based one of bug list's enhancment request which asks to > save image for Internet, ie user wants image to be as small as > possible (for example to send with mail or put to forum) and some > parts could be cropped and picture could be resized until wanted file > size is reached. I'd love to see this integrated into the crop tool somehow, rather than hidden off in a "save for web" plug-in. When I crop to a fixed size it's usually not for the web -- I more likely want a desktop background image, or a slide background, or a print. Crop's Aspect Ratio got a lot easier to manage in 2.3 as opposed to 2.2. So "crop to a fixed aspect ratio, then rescale" is much easier now -- presuming you understand aspect ratio and don't mind typing two colon- separated numbers. (Though I haven't figured out the "<->" and "Set" buttons, which have no tooltips and don't seem to do anything, or why you'd want a 1:1 preset button but not presets for 4:3 or 4:6 or "Keep image's aspect ratio"). But I can certainly understand why so many users want Crop+Scale all in one step. It's a very common operation, and it would be a shame to offer it, then cripple it by putting it in a plug-in where the crop has to happen in a small preview area. -- ...Akkana "Beginning GIMP: From Novice to Professional": http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colorize - Lightness != luminosity?
On Wed, 2007-02-07 at 08:57 +0100, Sven Neumann wrote: > As far as I understand the dialog doesn't show absolute values for > Saturation and Lightness but relative ones. Perhaps the Saturation > slider should also go from -100 to +100 then. Saturation appears to be absolute. Lightness is relative. See below. > First of all someone should take a look at the code and find out what it > really does. I very much doubt that anyone here can tell you this > without looking at the code. So why don't you just have a look and tell > us what you found? Okay, here's how it looked to me. I had to trace through to figure out where the meat was being cooked, so this includes my tracing (in case I missed something): Call sequence for changing the Lightness slider in the Colorize dialog: * app/tools/gimpcolorizetool.c:colorize_lightness_adj_update() colorize_lightness_adj_update() is the callback in the Colorize dialog that handles Lightness slider changes. * app/tools/gimpcolorizetool.c:colorize_lightness_adj_update() colorize_lightness_adj_update() calls colorize_update() after retrieving the L value from the dialog and saving it in a Colorize structure. The Colorize structure holds current HSL values as gdoubles and two sets of 3 256-entry tables, one set of 3 for Luminance lookups and one set of 3 for RGB lookups. Colorize is initialized (by colorize_init()) so that the Lum lookup table is non-zero. * app/tools/gimpcolorizetool.c:colorize_update() colorize_update() calls colorize_calculate() before updating dialog controls. * app/base/colorize.c:colorize_calculate() Doesn't use the L component of Colorize structure. It simply computes 256 RGB lookup values (0-255) and sets L to i/255.0 for each component, using the S and H components passed in the Colorize structure. The H and S components are used as you would expect in HSV space: the value for H is divided by 360 and the value for S is divided by 100. * app/tools/gimpimagemaptool.c:gimp_image_map_tool_preview() For the Colorize dialog, which has a preview, this function calls gimp_image_map_tool_map(). colorize_lightness_adj_update() then calls gimp_image_map_tool_preview(). * app/tools/gimpimagemaptool.c:gimp_image_map_tool_preview() This call sequence eventually calls the gimp_colorize_tool_map() function to do the preview update. * app/tools/gimpcolorizetool.c:gimp_colorize_tool_map() gimp_colorize_tool_map() calls gimp_image_map_apply(), which is passed the colorize() function and a Colorize structure, along with the a structure containing a pointer to the drawable (re: preview) to update. app/base/colorize.c:colorize() At each pixel across the width and height of the preview: Note: L = slider setting in the dialog, ie colorize->lightness "lum" inits to the combined luminance of the current pixel based on the luminance lookup table in the Colorize structure. If L > 0, lum = (gdouble) lum * (100.0 - colorize->lightness) / 100.0; lum = += 255 - (100.0 - colorize->lightness) * 255.0 / 100.0; else if L < 0 lum = (gdouble) lum * (colorize->lightness + 100.0) / 100.0; New pixel value is RGB = Colorize.RGBlookup[lum] (Alpha preserved) This means: If L = 0 then the pixel is always the luminance of the selected H/S combination. If L < 0 then the pixel is the (absolute value of the lightness slider)% of the current pixels luminance for the selected H/S combination. If L > 0 Add the (lightness slider)% of 0-255 to (lightness slider)% of the pixels current luminance and use that to compute the new color from the RGB table based on the H/S combination. It's unclear to me why the percent of 0-255 is added to a percent of the current luminance value instead of directly to the current luminance value though I can see why you might want to have -100 to 100 for the L slider: negative slider values reduce luminance of the current pixel while positive values increase it. You need to do this because your working relative to the current pixel and not on an absolute scale. In other words, the L slider is a percent increase or percent decrease in any given pixels luminance. Sort of. -- Michael J. HammelSenior Software Engineer [EMAIL PROTECTED] http://graphics-muse.org -- Failure is not an option. It comes bundled with your Microsoft product. -- Ferenc Mantfeld ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
On Wed, Feb 07, 2007 at 11:59:43AM -0200, Joao S. O. Bueno Calligaris wrote: > On Wednesday 07 February 2007 07:31, Alexandre Prokoudine wrote: > > On 2/6/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > On Mon, 2007-02-05 at 22:38 +0100, Marco Ciampa wrote: > > > > I just noted this strange behaviour: when I see the the > > > > Image menu->View->Display filters->Color Deficient Vision > > > > options (Protanopia, Deuteranopia, Tritanopia) with the Italian > > > > locale, _all_ but these three options are translated. Is it my > > > > svn copy fault or does it have this behaviour in other > > > > languages too? > > > > > > Sorry, but I don't understand your question. What's translated > > > and what's not? And did you already check in the it.po files that > > > the strings have been translated at all? > > > > As of current po-libgimp/it.po > > > > #: ../modules/cdisplay_colorblind.c:67 > > msgid "Protanopia (insensitivity to red)" > > msgstr "Protanopia (insensibilità al rosso)" > > > So, do you know if ther eis an Italian word for it,a nd which it is? > If there are proper Italian words for that, just send then to the list > and we will fix(exceptionally, the normal course would be to ask for > the change in bugzilla.gimp.org) > > I am the trasnaltor for Brazillian portuguese, and as far as I know > these exact terms can be used in my language, so they are not changed > in the pt_BR translation as well. > The terms are the same in italian (they actually come from Latin) so the translation is correct and complete, thanks. See the other thread, perhaps the problem is in the automake/autoconf process that creates an invalid Makefile for the po-libgimp directory. I'm sorry, I'm not an expert in automake/autoconf/make so I do not know how should look a correct Makefile to handle correctly the compilation/update of these .po files. bye -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On 2/7/07, gg wrote: > I should probably have chosen a more precise and less emotive term than > lame. In chosing "save for the web" the use indicates he does not know > what is involved and is expecting gimp to magically do it for him, not > unreasonably since the program is offering that as an option. I believe > offering that option to be a mistake. It seems to be mainly motivated by > "Photoshop does it so we ought to as well". When you save JPEGs, generally you do it either for web-gallery, or for print, or for display (to be used as wallpaper or something). Peter might correct me, but "Save for Web" implies doing a tradeoff between quality and file size, whereas neither print nor display destinations require that. Thus "Save for Web" is a plug-in that deals with a specialized usecase. That's it. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On Wed, 07 Feb 2007 14:32:04 +0100, Thorsten Wilms <[EMAIL PROTECTED]> wrote: > On Wed, Feb 07, 2007 at 01:58:21PM +0100, [EMAIL PROTECTED] wrote: > >> Despite the idiot-user title of this feature (copied for PS it seems) > > ... > >> If the user is so lame that they are going to click on a feature called >> "save for the web" > > If a user wants to save images for use on the web, save_for_the_web > is high level thinking and not lame or idiotic. > I said idiot-user title, it is that sort of title that is treating the user as an idiot. I should probably have chosen a more precise and less emotive term than lame. In chosing "save for the web" the use indicates he does not know what is involved and is expecting gimp to magically do it for him, not unreasonably since the program is offering that as an option. I believe offering that option to be a mistake. It seems to be mainly motivated by "Photoshop does it so we ought to as well". > The choice of format is secondary. > 1. save for web > 2. use most appropiate format > > >> Someone >> choosing "save for the web" needs help, let's provide some rather than >> maintaining them in thier ignoracen and providing enevitably compromised >> solutions. > > I know the characteristics of JPG, PNG, GIF. I can usually tell > what will work best. There are border cases, though. Then I have > to experiment and can't formulate save_as_jpg or save_as_my_png > as my initial goal at all. > Well if you can tell what usually works best that probably means you'll slightly better than a "save for the web" feature anyway. You'll probably be able to set an appropriate jpeg compression level for your specific image based on the quality your require for your context. In other cases, where you need to experiment, you clearly indicate you know what you're doing and my comments dont apply to you. What I am suggesting is empowering users to get to that stage rather than providing mediocre results with "optimisations" determined without established criteria or prior knowlege of the data. We have the choice to provide a better solution than PS rather than just playing catch-up. That's what I'd like to see. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
On Wednesday 07 February 2007 07:31, Alexandre Prokoudine wrote: > On 2/6/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On Mon, 2007-02-05 at 22:38 +0100, Marco Ciampa wrote: > > > I just noted this strange behaviour: when I see the the > > > Image menu->View->Display filters->Color Deficient Vision > > > options (Protanopia, Deuteranopia, Tritanopia) with the Italian > > > locale, _all_ but these three options are translated. Is it my > > > svn copy fault or does it have this behaviour in other > > > languages too? > > > > Sorry, but I don't understand your question. What's translated > > and what's not? And did you already check in the it.po files that > > the strings have been translated at all? > > As of current po-libgimp/it.po > > #: ../modules/cdisplay_colorblind.c:67 > msgid "Protanopia (insensitivity to red)" > msgstr "Protanopia (insensibilità al rosso)" So, do you know if ther eis an Italian word for it,a nd which it is? If there are proper Italian words for that, just send then to the list and we will fix(exceptionally, the normal course would be to ask for the change in bugzilla.gimp.org) I am the trasnaltor for Brazillian portuguese, and as far as I know these exact terms can be used in my language, so they are not changed in the pt_BR translation as well. js -><- > > Alexandre > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On Wed, Feb 07, 2007 at 01:58:21PM +0100, [EMAIL PROTECTED] wrote: > Despite the idiot-user title of this feature (copied for PS it seems) ... > If the user is so lame that they are going to click on a feature called > "save for the web" If a user wants to save images for use on the web, save_for_the_web is high level thinking and not lame or idiotic. The choice of format is secondary. 1. save for web 2. use most appropiate format > Someone > choosing "save for the web" needs help, let's provide some rather than > maintaining them in thier ignoracen and providing enevitably compromised > solutions. I know the characteristics of JPG, PNG, GIF. I can usually tell what will work best. There are border cases, though. Then I have to experiment and can't formulate save_as_jpg or save_as_my_png as my initial goal at all. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On Wed, 07 Feb 2007 11:16:33 +0100, <[EMAIL PROTECTED]> wrote: > On Tuesday, February 6, 2007, 20:03:59, peter sikking wrote: > >> - that in-dialog cropping looks like a very uncomfortable way >>to do that to me; >> - simply display the Size in the fields that are now called >>Resize now without the open/close triangle, and remove the >>other size display; > I actually find resize/crop controls redundant in the Save for Web > dialog - > I usually prepare the image beforehand while keeping it in a native > (lossless) format, then just expect to use Save for Web to export the > image > for upload to a website without touching the original. > Instead, I'd want to see the colour subsampling setting in the export > plugin > - some images just can't be made good looking with 2x2 colour > subsampling. > >> - why can't the plug-in figure out which combination of >>Optimise/Progressive/Baseline will produce the smallest >>file size, and let me select that as Smallest? Despite the idiot-user title of this feature (copied for PS it seems) there is no magic optimum or true minimum size. All this depends on the nature of the image and quality compromises one is prepared to accept. This is necessarily subjective and can never be predetermined by software. If the user is so lame that they are going to click on a feature called "save for the web" I sincerly think the most useful way to help him fullfil his needs would be to display a dlg with a brief guide to the key tasks required: cropping , image file format choice, quality/size play-offs etc. Perferably with links to fuller information. The necessary tools are already in Gimp so why duplicate them? Someone choosing "save for the web" needs help, let's provide some rather than maintaining them in thier ignoracen and providing enevitably compromised solutions. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
On Wed, Feb 07, 2007 at 09:29:57AM +0100, Sven Neumann wrote: > On Wed, 2007-02-07 at 09:12 +0100, Marco Ciampa wrote: [...] > > Resolving this error I get another error: > > > > Making all in po-libgimp > > make[2]: Entering directory `/home/marco/svn-gnome/gimp/trunk/po-libgimp' > > Makefile:159: *** target pattern contains no `%'. Stop. > > make[2]: Leaving directory `/home/marco/svn-gnome/gimp/trunk/po-libgimp' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/marco/svn-gnome/gimp/trunk' > > make: *** [all] Error 2 > > > > Exaclty on the po files where I see the problem, perhaps resolving this > > fixes it all... > > Yes, that might very well fix the problem for you. I remember that I > used to have this issue with the po-libgimp Makefiles myself. Now if > only I could remember how I fixed it... Perhaps may help if I post the source lines of the Makefile that trigger the error: [...] all: all-yes all-yes: $(CATALOGS) all-no: #here is the problem! $(GETTEXT_PACKAGE).pot: $(POTFILES) $(GENPOT) [...] TIA -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
Hi, On 2/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Tuesday, February 6, 2007, 20:03:59, peter sikking wrote: > > > - that in-dialog cropping looks like a very uncomfortable way > >to do that to me; > > - simply display the Size in the fields that are now called > >Resize now without the open/close triangle, and remove the > >other size display; > > I actually find resize/crop controls redundant in the Save for Web dialog - > I usually prepare the image beforehand while keeping it in a native > (lossless) format, then just expect to use Save for Web to export the image > for upload to a website without touching the original. The idea is based one of bug list's enhancment request which asks to save image for Internet, ie user wants image to be as small as possible (for example to send with mail or put to forum) and some parts could be cropped and picture could be resized until wanted file size is reached. It was then decided that this functionality should be put in save for web plug-in. (see http://bugzilla.gnome.org/show_bug.cgi?id=317100 ) Maybe we should discuss again if this functionality is needed and if so, is it convenient to integrate it into save for web plug-in. Thanks. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
Hi, On 2/6/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > > BTW, does this plug-in use GimpPreview widgets? I would like to get some > feedback on features and API of GimpPreview and its derivatives. > It actually uses GtkDrawingArea. This is related to zoom & cropping functionality. If we dropped cropping, one of Gimp widgets could be used. Is there any widget which supports - zoom in & out - GIMP quick navigation widget in the corner of the scroll bars - access to cursor coordinates to give extra control with mouse? Thanks ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On Tuesday, February 6, 2007, 20:03:59, peter sikking wrote: > - that in-dialog cropping looks like a very uncomfortable way >to do that to me; > - simply display the Size in the fields that are now called >Resize now without the open/close triangle, and remove the >other size display; I actually find resize/crop controls redundant in the Save for Web dialog - I usually prepare the image beforehand while keeping it in a native (lossless) format, then just expect to use Save for Web to export the image for upload to a website without touching the original. Instead, I'd want to see the colour subsampling setting in the export plugin - some images just can't be made good looking with 2x2 colour subsampling. > - why can't the plug-in figure out which combination of >Optimise/Progressive/Baseline will produce the smallest >file size, and let me select that as Smallest? Except for Optimize, these settings aren't directly related to file size (although using Progressive encoding usually does lower the image size a bit). Progressive just changes the way image is stored, and how browser displays it over a slow link. However, with Internet Explorer browser, progressively encoded images load exactly the opposite way you'd expect - nothing will be displayed until whole image is downloaded, then the image appears all at once. Baseline makes the JPEG file more compatible while sacrificing quality/increasing file size. -- < Jernej Simončič ><><><><>< http://deepthought.ena.si/ > Look over your shoulder now and then to be sure someone's following you. -- Gilmer's Motto for Political Leadership ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
On 2/6/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > On Mon, 2007-02-05 at 22:38 +0100, Marco Ciampa wrote: > > I just noted this strange behaviour: when I see the the > > Image menu->View->Display filters->Color Deficient Vision options > > (Protanopia, Deuteranopia, Tritanopia) with the Italian locale, _all_ but > > these three options are translated. Is it my svn copy fault or does it have > > this > > behaviour in other languages too? > > Sorry, but I don't understand your question. What's translated and > what's not? And did you already check in the it.po files that the > strings have been translated at all? As of current po-libgimp/it.po #: ../modules/cdisplay_colorblind.c:67 msgid "Protanopia (insensitivity to red)" msgstr "Protanopia (insensibilità al rosso)" Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
Hi, On Wed, 2007-02-07 at 09:12 +0100, Marco Ciampa wrote: > In file included from /usr/include/dbus-1.0/dbus/dbus-glib-lowlevel.h:28, > from gui.c:27: > /usr/include/dbus-1.0/dbus/dbus.h:30:2: error: #error "Please define > DBUS_API_SUBJECT_TO_CHANGE to acknowledge your understanding that D-Bus > /hasn't reached 1.0 and is subject to protocol and API churn. See the README > for a full explanation." > make[3]: *** [gui.o] Error 1 > make[3]: Leaving directory `/home/marco/svn-gnome/gimp/trunk/app/gui' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/marco/svn-gnome/gimp/trunk/app' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/marco/svn-gnome/gimp/trunk' > make: *** [all] Error 2 > > I'm able to compile again inserting > > #define DBUS_API_SUBJECT_TO_CHANGE > > in app/gui/gui.c > > but I do not think this is the correct way I should follow to compile... That's another issue. The problem here is that your version of D-Bus is too old. But I think we should add the #define until we decide to depend on a newer version of D-Bus and add a configure check for it. > Resolving this error I get another error: > > Making all in po-libgimp > make[2]: Entering directory `/home/marco/svn-gnome/gimp/trunk/po-libgimp' > Makefile:159: *** target pattern contains no `%'. Stop. > make[2]: Leaving directory `/home/marco/svn-gnome/gimp/trunk/po-libgimp' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/marco/svn-gnome/gimp/trunk' > make: *** [all] Error 2 > > Exaclty on the po files where I see the problem, perhaps resolving this > fixes it all... Yes, that might very well fix the problem for you. I remember that I used to have this issue with the po-libgimp Makefiles myself. Now if only I could remember how I fixed it... Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
On Tue, Feb 06, 2007 at 08:38:31AM +0100, Sven Neumann wrote: > Hi, > > On Mon, 2007-02-05 at 22:38 +0100, Marco Ciampa wrote: > > I just noted this strange behaviour: when I see the the > > Image menu->View->Display filters->Color Deficient Vision options > > (Protanopia, Deuteranopia, Tritanopia) with the Italian locale, _all_ but > > these three options are translated. Is it my svn copy fault or does it have > > this > > behaviour in other languages too? > > Sorry, but I don't understand your question. Sorry for my bad english... > What's translated and what's not? The problem seems around the option pulldown menu... > And did you already check in the it.po files that the > strings have been translated at all? Of course, the it.po file is correctly translated. Maybe I have some problems in the configure procedure? running ./configure & make I get: make [...] Making all in gui make[3]: Entering directory `/home/marco/svn-gnome/gimp/trunk/app/gui' if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -I../../app -I../../app -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/local/include -DG_LOG_DOMAIN=\"Gimp-GUI\" -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DGIMP_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -g -O2 -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -MT gui.o -MD -MP -MF ".deps/gui.Tpo" -c -o gui.o gui.c; \ then mv -f ".deps/gui.Tpo" ".deps/gui.Po"; else rm -f ".deps/gui.Tpo"; exit 1; fi In file included from /usr/include/dbus-1.0/dbus/dbus-glib-lowlevel.h:28, from gui.c:27: /usr/include/dbus-1.0/dbus/dbus.h:30:2: error: #error "Please define DBUS_API_SUBJECT_TO_CHANGE to acknowledge your understanding that D-Bus /hasn't reached 1.0 and is subject to protocol and API churn. See the README for a full explanation." make[3]: *** [gui.o] Error 1 make[3]: Leaving directory `/home/marco/svn-gnome/gimp/trunk/app/gui' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/marco/svn-gnome/gimp/trunk/app' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/marco/svn-gnome/gimp/trunk' make: *** [all] Error 2 I'm able to compile again inserting #define DBUS_API_SUBJECT_TO_CHANGE in app/gui/gui.c but I do not think this is the correct way I should follow to compile... Resolving this error I get another error: Making all in po-libgimp make[2]: Entering directory `/home/marco/svn-gnome/gimp/trunk/po-libgimp' Makefile:159: *** target pattern contains no `%'. Stop. make[2]: Leaving directory `/home/marco/svn-gnome/gimp/trunk/po-libgimp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/marco/svn-gnome/gimp/trunk' make: *** [all] Error 2 Exaclty on the po files where I see the problem, perhaps resolving this fixes it all... -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
