Re: [Gimp-developer] Bug 719435
On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote: I was asked by Michael Natterer to discuss this enhancement on the GIMP developer list. https://bugzilla.gnome.org/show_bug.cgi?id=719435 Basically, I'd like to see the line cue for the Pen tool colorized when either of the two X,Y axis offsets are 0, or when their absolute values are equal (or have it match the existing angles used for snapping, though I personally only use the 45 degree angle setting often). This colorization cue would be visible without activating snapping, and would simply change the line color when those conditions are met. I have no other reason for wanting it except that I think it is difficult to see when the line is at exactly 45 degrees since it uses such a smooth anti-aliasing algorithm, and that it would provide added value, be a nice helpful feature, and something that I've wanted in GIMP for quite some time. :-) How would that be better than the current constrained angles? ___ 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] Updating gimp-win.sourceforge.net and Sourceforge old page as deprecated.
Hi, 1) Today while browsing random pages, I saw references to the Sourceforge page: https://sourceforge.net/projects/gimp-win/ I clicked and I see no warning message or anything there saying this is not anymore the place to get newer versions of GIMP for Windows. So I assume anyone who come to this page would think this is still the page where GIMP for Windows happen. Could whoever has admin right on this Sourceforge project add like a big red message or something saying all these installers are old and this page deprecated and redirect them to the new installer page? 2) Also the page http://gimp-win.sourceforge.net has been updated with a link to gimp.org and a message. Nevertheless if you were to browse and go to the FAQ page, the Download button would be bad again and link to the old Sourceforge page, which is wrong: http://gimp-win.sourceforge.net/faq.html Could the maintainer of this page (Ender, isn't it?) update it? Thanks a lot all! 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] N-Point Image Deformation queries
Hello, thanks for the hints and sorry for the late answer. I will try to fix what I'm able to and then ask you for review. About the interpolation code - I was afraid that GEGL sampling functions could be slow for a preview of the deformation. I will try to use them and make some performance tests. Do you prefer me to use your branch (npd-squashed) for that work? Marek Hello, We somewhat assumed that you weren't here, because we couldn't easily get a hold of you. Apparently, we didn't try hard enough. Thanks for sticking around. Anyway, I began reviewing your code. I made some changes to it to try and make it a bit cleaner, so we could merge it into the main gegl tree. You can see all of my changes here: https://git.gnome.org/browse/gegl/log/?h=npd-squashed The main complaints we have about your code are: * The GEGL operation shouldn't contain any Cairo code in it. UI stuff like that should only be in either your library or your GIMP tool. Of course, you have it set up so that this should be easy to change. * Generally, when you write an API, you want to expose as little as possible. Only the bare minimum number of functions should be included in the public/installed header files, and typically no structures at all should appear there. I've begun fixing this by converting some of your functions to static functions where possible. * Some of the functions like add_point_to_suitable_cluster do bizarre things like convert floats to strings just so they can be used as hash table keys. A lot of this code wasn't actually used, so I commented it out for now. I would feel a lot better if the npd library didn't include its own interpolation code. You mentioned outputting float coordinates to an image and then using map-absolute, but I'd prefer if the gegl operation found the color values directly with a GeglSampler object. This gives you access to Gegl's built-in interpolation methods. I'm not sure if you want me to continue working on npd (I can find other stuff to do, if you'd prefer to make these changes yourself.) Anyway, these are the main things that are stopping us from merging the gegl npd branch right now. I haven't actually looked at the gimp npd branch, but mitch sounded generally happy with the code there. If you want to talk to me on irc, my nick is drawoc. Anyway, thanks for the hard work! ___ 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] Bug 719435
On 12/01/2013 12:15 PM, Ofnuts wrote: On 11/30/2013 10:53 PM, Hodgin, Rick C. wrote: I was asked by Michael Natterer to discuss this enhancement on the GIMP developer list. https://bugzilla.gnome.org/show_bug.cgi?id=719435 Basically, I'd like to see the line cue for the Pen tool colorized when either of the two X,Y axis offsets are 0, or when their absolute values are equal (or have it match the existing angles used for snapping, though I personally only use the 45 degree angle setting often). This colorization cue would be visible without activating snapping, and would simply change the line color when those conditions are met. I have no other reason for wanting it except that I think it is difficult to see when the line is at exactly 45 degrees since it uses such a smooth anti-aliasing algorithm, and that it would provide added value, be a nice helpful feature, and something that I've wanted in GIMP for quite some time. :-) How would that be better than the current constrained angles? It would cue automatically without constraining. As the cursor moves around, the colors would indicate alignments. It could be used to examine existing image content, or to help align new. Best regards, Rick C. Hodgin ___ 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] N-Point Image Deformation queries
Sure, starting from npd-squashed would be fine. I suppose the gegl sampling functions might be a bit slow for the preview. On the other hand, they have had a fair amount of optimization work done on them, so you might find that they're actually faster. Actually trying them out is probably a good idea. If nothing else, we should use GeglSamplers for the final rendering of the mesh. On Sun, Dec 1, 2013 at 7:07 PM, Marek Dvoroznak dvoro...@gmail.com wrote: Hello, thanks for the hints and sorry for the late answer. I will try to fix what I'm able to and then ask you for review. About the interpolation code - I was afraid that GEGL sampling functions could be slow for a preview of the deformation. I will try to use them and make some performance tests. Do you prefer me to use your branch (npd-squashed) for that work? Marek Hello, We somewhat assumed that you weren't here, because we couldn't easily get a hold of you. Apparently, we didn't try hard enough. Thanks for sticking around. Anyway, I began reviewing your code. I made some changes to it to try and make it a bit cleaner, so we could merge it into the main gegl tree. You can see all of my changes here: https://git.gnome.org/browse/gegl/log/?h=npd-squashed The main complaints we have about your code are: * The GEGL operation shouldn't contain any Cairo code in it. UI stuff like that should only be in either your library or your GIMP tool. Of course, you have it set up so that this should be easy to change. * Generally, when you write an API, you want to expose as little as possible. Only the bare minimum number of functions should be included in the public/installed header files, and typically no structures at all should appear there. I've begun fixing this by converting some of your functions to static functions where possible. * Some of the functions like add_point_to_suitable_cluster do bizarre things like convert floats to strings just so they can be used as hash table keys. A lot of this code wasn't actually used, so I commented it out for now. I would feel a lot better if the npd library didn't include its own interpolation code. You mentioned outputting float coordinates to an image and then using map-absolute, but I'd prefer if the gegl operation found the color values directly with a GeglSampler object. This gives you access to Gegl's built-in interpolation methods. I'm not sure if you want me to continue working on npd (I can find other stuff to do, if you'd prefer to make these changes yourself.) Anyway, these are the main things that are stopping us from merging the gegl npd branch right now. I haven't actually looked at the gimp npd branch, but mitch sounded generally happy with the code there. If you want to talk to me on irc, my nick is drawoc. Anyway, thanks for the hard work! ___ 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] Setting Up a Release Procedure
Hi, On Sun, Dec 1, 2013 at 12:44 PM, Jehan Pagès jehan.marmott...@gmail.com wrote: On Sun, Dec 1, 2013 at 2:50 AM, Simone Karin Lehmann sim...@lisanet.de wrote: Here’s the link to the current epository (not totally complete, I’ll update this if I find some time…. and I know, some code looks ugly …) https://sourceforge.net/p/gimponosx/code/HEAD/tree/ Thanks. I'll see what Clayton thinks about these. We had a quick look with Mitch on the patches for GIMP specifically. Many of them are obsolete now. For instance we already switched to the Cocoa platform since 2.8.10 (commit e56344294c90e1ba97de5c134b50c4c522f0808f which includes code from you already!). And some like the save/export, we obviously won't integrate, as you can guess. But the color display change for instance seems promising. :-) If you have other contributions you would like to see upstream, I would really suggest discussing them with us and providing us patches. This would really improve everyone's process! Thanks 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
