Re: [Gimp-developer] Fwd: GIMP Icons
Hi, On Mon, Nov 18, 2013 at 1:06 AM, Jehan Pagès jehan.marmott...@gmail.com wrote: Hi again, On Mon, Nov 18, 2013 at 12:25 AM, Jehan Pagès jehan.marmott...@gmail.com wrote: Hi, On Fri, Nov 15, 2013 at 9:41 AM, Michael Henning dra...@darkrefraction.com wrote: This was replied to just me, so I'm forwarding it to the entire list. Thanks Michael. -- Forwarded message -- From: Andrew Pullins android2...@gmail.com Date: Thu, Nov 14, 2013 at 2:15 AM Subject: Re: [Gimp-developer] GIMP Icons To: Michael Henning dra...@darkrefraction.com You have not answered to the question. What version is it *exactly*? The last is 2.8.8. Just 2.8 is not enough, there has been 4 minor versions in 2.8. Please check the About of the program. here are some comments form my DeviantArt Linux Works fine on Debian Wheezy / Gimp 2.8.x Dark theme crashes on Ubuntu 12.04, but Light works fine. I just tested on my Linux Mint. The dark theme crashes too. So I tracked the bug. As I thought, the issue is in GTK+. I have fixed it on my locale development and will upload the patch tomorrow on Bugzilla (I want first to do a few more tests and see if it affects GTK+ 3 as well. But for now, I must sleep). Well in the end, I did not want to push it to tomorrow. So I just tested and made the ticket now. See https://bugzilla.gnome.org/show_bug.cgi?id=712536 With this patch, we will handle better broken themes. Just for your information, the patch has made it upstream and new stables releases of GTK+ are planned for this week. Not sure when it would make it to your distribution but when it will, the particular crashes you experienced will be fixed (unless there were other issues I could not discover) with GTK+ 2.24.23. This being said, even though GTK+ will be now robuster on a faulty theme, I would still suggest you to fix your theme with the indications I gave you earlier. Then you don't have to ask your users to wait for an updated GTK+. :-) Bye! Jehan In the meantime, you should fix your theme if you want it to work with current GTK+. In particular, just remove all the gap_file, gap_start_file and gap_end_file in your gtkrc which do not correspond to an existing image. These were the pieces of the gtkrc which was making GTK+ crash. Regards, Jehan [...] There seems to be a lot of missing icons in your set, and more problematic, several errors in the gtkrc. So that may explain why it does not work well (or at all) for some people (maybe it depends on the version of GTK+ installed). The best on your side would be to fix at least the gtkrc. well I can see how I messed some icons, there are a lot. as for the gtkrc I kinda just took a bunch of different themes mashed them together and ctrl found colors till switching them out got the look I wanted. I honestly have no idea what I'm doing with these themes. I did not know there was anything wrong with the gtkrc and have no idea where to start. I really wanted this to be a GMIP only theme, there seems to be a lot of GIMIP themes out there that can be used for many applications and there for have a lot of extra stuff that GIMP dose not need. I see. Well if you just follow all the warning output in a terminal, you can at least track all the non-existent images and get rid of the references in the gtkrc. That would be already a good start. :-) In any case, if really GIMP crashes because of this, that's not normal. It should not crash on wrong input. Could you please open a bug report: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP Then a developer (maybe me) will look into it when we have some time, and we'll try to reproduce the crash. I will do so. Well, now that I have fixed the bug, I may as well take care of the bug ticket too, I guess. Thanks for the report anyway. Jehan ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues
On 12/03/2013 02:10 PM, Teo Mazars wrote: The way GEGL currently exposes each numerical parameters is as follow: 1) A nominal range, say [a, b], which represents the range where the operation is expected to work 2) An UI range, [a', b'] included in [a, b], representing the area of interest of the parameter. 3) An exponent, (like a gamma correction), to make the slider not behave linearly on the [a', b'] range. Currently, GIMP's sliders show only [a', b'], but allows values in [a, b]. The exponent is the way GEGL handles the mutli-scale problem and it allows to have more precision on small value. Those values are all in GEGL, look for eg gegl_chant_double_ui in /operations/common/*.c I will let others comment on what is the optimal UI range for those two operations. But changing [a', b'] would be really easy, and it should change the unit as well. I am not sure about making that range user configurable, it makes sense imho. In the GEGL Gaussian blur, parameters are the std_dev along x and y, describing mathematically the Gaussian curve used as kernel. Though, I have to read the code to know where the infinite curve is clipped to have a only-one-pixel actual radius. Which is not obvious... I experimented a bit and settled on the following values: In operations/common/gaussian-blur.c: gegl_chant_double_ui (std_dev_x, _(Size X), 0.0, 250.0, 4.0, 0.0, 100.0, 1.5, /* was: 0.0, 1.0, 4.0, 0.0, 1000.0, 1.5, */ _(Standard deviation for the horizontal axis (multiply by ~2 to get radius))) gegl_chant_double_ui (std_dev_y, _(Size Y), 0.0, 250.0, 4.0, 0.0, 100.0, 1.5, /* was: 0.0, 1.0, 4.0, 0.0, 1000.0, 1.5, */ _(Standard deviation for the vertical axi. (multiply by ~2 to get radius))) This Gaussian blur slider range doesn't really allow slider selection of small, precise values less than 1, so typing in values is still necessary. A logarithm-type scale might be better than a linear scale as the useful range for blur necessarily is large, and the larger the image, the larger the useful range. In operations/common/unsharp-mask.c: gegl_chant_double_ui (std_dev, _(Std. Dev.), 0.0, 10.0, 1.0, 0.0, 10.0, 1.5, /* was: 0.0, 500.0, 1.0, 0.0, 200.0, 1.5, */ _(Standard deviation (spatial scale factor))) gegl_chant_double_ui (scale, _(Scale), 0.0, 10.0, 1.0, 0.0, 10.0, 1.5, /* was: 0.0, 500.0, 1.0, 0.0, 200.0, 1.5, */ _(Scale, strength of effect)) These USM slider values work well for me. I don't need to type in little more/little less values as I can move the slider precisely enough to set a value within 0.01 of what I want. The other gegl_chant_double_ui values are pretty obvious. What does the value 1.5 do? A way to type in values without risking accidentally causing a very large radius operation would be very welcome. But the revised slider ranges make typing necessary a lot less often, for me anyway. I wonder what values other people might find useful for Gaussian blur and USM? I have a 10MP camera. Someone with a 30 or 40MP camera probably would need a larger range, which is one reason why user-settable ranges might be a nice feature. Different styles of processing would be another. Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp from git Gegl Gaussian Blur and Unsharp Mask useability issues
This Gaussian blur slider range doesn't really allow slider selection of small, precise values less than 1, so typing in values is still necessary. A logarithm-type scale might be better than a linear scale as the useful range for blur necessarily is large, and the larger the image, the larger the useful range. [...] The other gegl_chant_double_ui values are pretty obvious. What does the value 1.5 do? The 1.5 is the UI exponent you were asking for in Gaussian Blur, 1.0 is linear. If 1.5 is not enough, you may try 2.0 or larger. For the slider step problem, I don't know much about that sorry... I think the new UI values you suggest are good. So please, try some more by tweaking the exponent and you can commit directly to GEGL master those changes, if you want. A way to type in values without risking accidentally causing a very large radius operation would be very welcome. Agreed, I am not sure how to solve that though... I wonder what values other people might find useful for Gaussian blur and USM? I have a 10MP camera. Someone with a 30 or 40MP camera probably would need a larger range, which is one reason why user-settable ranges might be a nice feature. Different styles of processing would be another. I agree too, but this is also an UI problem and I am really not an expert. A reasonable arbitrary UI range + exponent is already a step forward. Thank you, Téo ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP release: 2.8.10 request, OS X
Hi, On Thu, Dec 5, 2013 at 11:50 AM, Partha Bagchi parth...@gmail.com wrote: Hi Sven, Have been away for the Thanksgiving holidays.:) On Sun, Nov 24, 2013 at 4:59 AM, scl scl.gp...@gmail.com wrote: Hi, today there was [bugreport] about outdated builds for OSX. One reason for not being able to provide an official GIMP 2.8.8. on OS X build were serious issues on OS X Mavericks, for instance the [showstopper in the Text tool]. These have been solved in the meantime (thanks especially to Simone Karin Lehmann, Michael Natterer and Daniel Sabo). Therefore I think we should bring out GIMP 2.8.10 soon, including an official OS X build (preferably also for some older OS X versions). As far as I know Claytons build is at the ready. All we need is a 2.8.10 bump, don't we? This situation shows us another weakness again: there are at least four people working on an OS X release: Clayton Walker, Simone Karin Lehmann, Partha Bagchi and David Evans (Macports), not to mention the (still active?) maintainer of the outdated Fink build and the various people building GIMP on their own Macs. All of them do it in their rare spare time. All of them struggle alone with the special build issues of GIMP on OS X, its dependencies and the API incompatibilities between the various OS X versions. Can you guys and girls please find a way to work together? What makes it so hard to speak to another at the mailing list or IRC and unite your forces? Come on, we don't bite ;-) Thanks for mentioning me. :) I am happy to collaborate with anyone on my builds. Note that I build Gimp and all dependencies from scratch using OSX gcc version 4.2.1; that is, I build gtk+, glib, pango, cairo etc. etc. etc. and then I build Gimp. I also include plugins that I believe are useful to photographers, well at least useful to me. This would be very nice. I have a few questions: 1/ Do you patch GIMP? Is it the reason why you make your own GIMP build? If so, would you please contribute us all your patches? We would be happy to check them and see what can be merged in our own source. We are already working on merging some of Simone Karin Lehmann's patches to improve our OSX code. 2/ Do you patch some of the third parties? GTK+, glib, etc. If so, have you tried to contributing upstream to these various projects? 3/ What is exactly the list of plugins you include in your build? 3/ Is there anything else which would prevent you to work with us on delivering a robust upstream OSX build (faster than currently after a source release!) instead of duplicating the work? Note that we have obviously nothing about third party builds. If you really wish to, you can still make your own builds (maybe slightly different), even though you would help us making the upstream one. But even so, this could profit to all of us, for instance by sharing build systems, thus improving the procedure. Ideally we could automatize all builds for very easy and early release! The way I see it, if we find a way to automatize builds, then we could generate them on a server with no further human input, and available for testers, which would make releases very easy to test (and regenerate in case of issue) before any release. Finally, it's not really feasible for me to come to IRC and hence I loose out on some of those discussion. Why is that? As I said to Simone too, I am not fond of IRC myself and probably don't connect as much as the other contributors, but I make some time to hang around there. If this is the price of collaboration, it is not too high. Or is that a technical impossibility? (behind some port-blocking firewall in a company or something?) Thanks! Jehan Thanks in advance, Sven Thanks again, Partha [bugreport]: https://bugzilla.gnome.org/show_bug.cgi?id=715094 [showstopper in the Text tool]: https://bugzilla.gnome.org/show_bug.cgi?id=711281 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp- developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP release: 2.8.10 request, OS X
Hi again! On Thu, Dec 5, 2013 at 12:42 PM, Jehan Pagès jehan.marmott...@gmail.com wrote: Hi, On Thu, Dec 5, 2013 at 11:50 AM, Partha Bagchi parth...@gmail.com wrote: Hi Sven, Have been away for the Thanksgiving holidays.:) On Sun, Nov 24, 2013 at 4:59 AM, scl scl.gp...@gmail.com wrote: Hi, today there was [bugreport] about outdated builds for OSX. One reason for not being able to provide an official GIMP 2.8.8. on OS X build were serious issues on OS X Mavericks, for instance the [showstopper in the Text tool]. These have been solved in the meantime (thanks especially to Simone Karin Lehmann, Michael Natterer and Daniel Sabo). Therefore I think we should bring out GIMP 2.8.10 soon, including an official OS X build (preferably also for some older OS X versions). As far as I know Claytons build is at the ready. All we need is a 2.8.10 bump, don't we? This situation shows us another weakness again: there are at least four people working on an OS X release: Clayton Walker, Simone Karin Lehmann, Partha Bagchi and David Evans (Macports), not to mention the (still active?) maintainer of the outdated Fink build and the various people building GIMP on their own Macs. All of them do it in their rare spare time. All of them struggle alone with the special build issues of GIMP on OS X, its dependencies and the API incompatibilities between the various OS X versions. Can you guys and girls please find a way to work together? What makes it so hard to speak to another at the mailing list or IRC and unite your forces? Come on, we don't bite ;-) Thanks for mentioning me. :) I am happy to collaborate with anyone on my builds. Note that I build Gimp and all dependencies from scratch using OSX gcc version 4.2.1; that is, I build gtk+, glib, pango, cairo etc. etc. etc. and then I build Gimp. I also include plugins that I believe are useful to photographers, well at least useful to me. This would be very nice. I have a few questions: 1/ Do you patch GIMP? Is it the reason why you make your own GIMP build? If so, would you please contribute us all your patches? We would be happy to check them and see what can be merged in our own source. We are already working on merging some of Simone Karin Lehmann's patches to improve our OSX code. 2/ Do you patch some of the third parties? GTK+, glib, etc. If so, have you tried to contributing upstream to these various projects? 3/ What is exactly the list of plugins you include in your build? 3/ Is there anything else which would prevent you to work with us on delivering a robust upstream OSX build (faster than currently after a source release!) instead of duplicating the work? Note that we have obviously nothing about third party builds. If you really wish to, you can still make your own builds (maybe slightly different), even though you would help us making the upstream one. But even so, this could profit to all of us, for instance by sharing build systems, thus improving the procedure. Ideally we could automatize all builds for very easy and early release! The way I see it, if we find a way to automatize builds, then we could generate them on a server with no further human input, and available for testers, which would make releases very easy to test (and regenerate in case of issue) before any release. By the way! Since you also maintain a Windows build, all above questions would also pertain to your Windows build! Jehan Finally, it's not really feasible for me to come to IRC and hence I loose out on some of those discussion. Why is that? As I said to Simone too, I am not fond of IRC myself and probably don't connect as much as the other contributors, but I make some time to hang around there. If this is the price of collaboration, it is not too high. Or is that a technical impossibility? (behind some port-blocking firewall in a company or something?) Thanks! Jehan Thanks in advance, Sven Thanks again, Partha [bugreport]: https://bugzilla.gnome.org/show_bug.cgi?id=715094 [showstopper in the Text tool]: https://bugzilla.gnome.org/show_bug.cgi?id=711281 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp- developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
