Re: [Gimp-developer] Cropping border color
On Jun 1, 2015, at 11:07 PM, Brad Gibson bradgibson...@yahoo.com wrote:
It would be great if I could choose to see pure black around whatever I'm
cropping, because I make very meticulous crops of photos for artistic
purposes, and I often have to crop and go back multiple times because it
looks different in the final version with solid white/gray/black compared to
transparent while I'm cropping. Or else, if it's easier, make it so that I
can undo the finalization of the crop but go back to where I left the crop
at. Thanks.Brad G.
Are you willing to re-compile?
If you change the passe_partout color in app/display/gimpdisplayshell-style.c
[1] to be { 0.0, 0.0, 0.0, 1.0}, you should achieve the result you seek (though
I have not tested this).
[1]
https://git.gnome.org/browse/gimp/tree/app/display/gimpdisplayshell-style.c?h=gimp-2-8#n73
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/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
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
Simon Budig wrote: We need to make sure two things: a) upon import of an image the userRGB-format-descriptor within the images context needs to be set up to refer to the chromaticies of the source image. b) whenever a chromaticity dependent operation works on the images data the infrastructure needs to make sure that the pixel data gets fed into the operation using the chromaticies of the source image. We'll do this by having the operation request the image data in the userRGB format from the images context. With regard to b), it is conceivable that the chromaticity dependent operation itself could be transformed to take into account the userRGB format description, such that the resulting transformed operation could be applied directly to the unbounded RGB data. In cases where doing so is advantageous, the implementer should have that option. The requirement should only be thatthe infrastructure produce the same result as if the operation were working in the userRGB colorspace. ___ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list a) upon import of an image the userRGB-format-descriptor within the images context needs to be set up to refer to the chromaticies of the source image. b) whenever a chromaticity dependent operation works on the images data the infrastructure needs to make sure that the pixel data gets fed into the operation using the chromaticies of the source image. We'll do this by having the operation request the image data in the userRGB format from the images context. ___ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/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 List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Blend Tool UI
I like the idea of shaped gradients being handled in the Blend Tool. If the length of the stroke determines the maximum distance from the selection boundary, it would provide a quick means of stroking the selection or creating shadows and highlights with interactive control of the thickness. With regard to moving the blend stroke, I think that ALT+drag should be required, to be consistent with the behavior of the Vectors Tool. For further consistency with the Vectors Tool, CTRL-drag on the blend stroke should add a new stop and then repositioning all the stops while dragging. With no modifier key pressed while dragging along the blend stroke, no new stop should be created and the existing stops should repositioned based on the drag. Any mouse drags that are not on the blend stroke or its endpoints should result in the existing blend being committed and a new one commenced. However, a mouse click by itself that is not on the blend stroke or one of its endpoints should result in just the blend being committed. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
[Gimp-developer] Accessing Path in GEGL-based plug-in
What is the proper way for a GEGL-based plug-in to grab the path points from the image's active path? The examples that I've seen all seem to, for the most part, keep the GEGL operations separate from the GIMP interface (other than UI chants). Should a standalone GEGL operation be written separate from GIMP -- one that accepts path control points as parameters; and then a traditional GIMP plug-in be written which invokes the operation? If so, how should the two entities be packaged (should the GEGL op go in $HOME/.local/)? And how should the plug-in check for existence of the operation? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Script-fu] How to convert a path to a selection? (grafxuser)
The procedure returns a list containing a count and an array of path IDs. I would recommend converting this to a list using the R5RS function 'vector-list'. Mind that the vector in 'vector-list' is what Scheme chooses to call an array; it is completely unrelated to the GIMP concept of vectors/paths. To avoid confusion, I use the older path terminology for my user-defined functions and variables. (let ((paths (vector-list (cadr (gimp-vectors-import-from-file image filename FALSE scale-to-imagesize ) ; we now have a list of 'paths' that have been imported. ; To select from the first path in the list, use the 'car' function (gimp-vectors-to-selection (car paths) 2 TRUE FALSE 0 0) ) If more than one path has been imported, you could loop through the list of path IDs, adding each selection. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Request for 2.8 - treat images as items
It would be nice for plug-ins if the set of unique identifiers used for images did not intersect with those employed for items, thus permitting a 'gimp-image-is-valid' test to provide a correct response if passed the identifier of an item. The reasoning is that there is much similarity between the structure of a layer group and the structure of an image; at least with regard to the constituent of items. Or put another way, an image's drawable hierarchy is identical to that of a layer group (please correct me if I'm mistaken) and it may prove useful in the future to make use of this similarity (e.g., load image as group, save group as image). Currently, images and items can share the same unique identifier and my proposal is that the identifiers for both be generated from the same pool of available identifiers, guaranteeing that no overlap takes place. This fix would seem pretty trivial to make -- and I can't think of any downside (other than perhaps exhausting available unique identifiers in 8000 years instead of 9000) -- however, I was unable to find in GIMP's code where these identifiers are retrieved. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
