Re: [Gimp-developer] Gimp UX: Paste
(Sorry for the top post. I was using gmail from my phone and it defaults to that and can't be turned off I don't even see what I am replying to but it sticks it there anyway...) -Rob A> ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] parasite usage
Parasites are a mechanism for attaching arbitrary binary data to an image or layer, so they will support just about anything you can imagine. The main thing to think about is compatibility: if you want your plug-in to generate persistent parasites and read them later, the process needs to work on every platform, and future versions of your plug-in should not break if they are applied to images that contain parasites generated by earlier versions. This "future backward compatibility" principle is what usually calls for the most thought. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
Yes more or less. The script pastes as a layer not a floating layer. That is the big difference. And it provides the same alignment behaviour to the new layer which is not the behaviour of the current “paste as layer” (which aligns the new layer at 0,0. -Rob A> On 6/3/10, Sven Neumann wrote: > On Thu, 2010-06-03 at 13:45 -0400, Rob Antonishen wrote: > >> I bound this to ctrl-v and played for a while and it feels pretty >> intuitive. One "feature" is that if you make a selection and go >> ctrl-x, ctrl-v it pastes the cut out bit exactly where it was cut out >> from, which makes sense. > > That is what GIMP has been doing all the time, right ? > > > Sven > > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
On Thu, 2010-06-03 at 21:01 +0100, Chris Mohler wrote: > On Thu, Jun 3, 2010 at 8:47 PM, Sven Neumann wrote: > >> I bound this to ctrl-v and played for a while and it feels pretty > >> intuitive. One "feature" is that if you make a selection and go > >> ctrl-x, ctrl-v it pastes the cut out bit exactly where it was cut out > >> from, which makes sense. > > > > That is what GIMP has been doing all the time, right ? > > Yes, as long as the selection remains. > > Selecting nothing and copy+paste also pastes the layer in place - > unless you select a layer with a different size before pasting. For > example, copying a 300px wide layer, selecting a 600px wide layer and > pasting centers the floating selection. I'd prefer it pasted in the > original position in this case - but this is only my opinion. Well, then we'd have to attach the original coordinates to the clipboard somehow. This information is not kept currently. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparison of enlargements produced with two GIMP methods, three GEGL methods, and three candidate GEGL methods
On Wed, 2010-06-02 at 23:49 -0400, Nicolas Robidoux wrote: > I have created 6.11x enlargements with two GIMP methods, three GEGL > methods, and three candidate GEGL methods for which patches are > provided in > > https://bugzilla.gnome.org/show_bug.cgi?id=619314 > > The enlargements, named a.png to h.png, are found in the 15M tar archive > > http://web.cs.laurentian.ca/nrobidoux/misc/catenlargementtests.tgz > > To know which method was used to produce each image, read the KEY text file. One thing I noticed when looking at these images is that the GEGL ops all create a black border at the bottom-right edges. Is that something you are aware of and expect to get "fixed" ? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
On Thu, Jun 3, 2010 at 8:47 PM, Sven Neumann wrote: >> I bound this to ctrl-v and played for a while and it feels pretty >> intuitive. One "feature" is that if you make a selection and go >> ctrl-x, ctrl-v it pastes the cut out bit exactly where it was cut out >> from, which makes sense. > > That is what GIMP has been doing all the time, right ? Yes, as long as the selection remains. Selecting nothing and copy+paste also pastes the layer in place - unless you select a layer with a different size before pasting. For example, copying a 300px wide layer, selecting a 600px wide layer and pasting centers the floating selection. I'd prefer it pasted in the original position in this case - but this is only my opinion. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
On Thu, 2010-06-03 at 13:45 -0400, Rob Antonishen wrote: > I bound this to ctrl-v and played for a while and it feels pretty > intuitive. One "feature" is that if you make a selection and go > ctrl-x, ctrl-v it pastes the cut out bit exactly where it was cut out > from, which makes sense. That is what GIMP has been doing all the time, right ? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
I've been following this with interest. To play with it, I created a script: http://ffaat.pointclark.net/incoming/scripts/paste-as-new-centered.scm It registers as Edit->Paste As->New Centered Layer This script will paste the contents of the buffer as follows: - If there is a selection, it will paste it as a new layer, centered on that selection. - If no selection, it will paste it as a new layer above the active layer, centered on the active layer. - If no active layer, it will paste it as a new layer at the top of the image stack, centered on the canvas. I bound this to ctrl-v and played for a while and it feels pretty intuitive. One "feature" is that if you make a selection and go ctrl-x, ctrl-v it pastes the cut out bit exactly where it was cut out from, which makes sense. Note that it will not do any clipping, and will always past the full contents of the clipboard buffer as a layer, regardles of selection , canvas, or active layer sizes. -Rob A> ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparison of enlargements produced with two GIMP methods, three GEGL methods, and three candidate GEGL methods
To illustrate the effect of the samplers on images from the opposite end of the spectrum (text as opposed to natural), I have put together a similar comparison with a text image created with GIMP. It shows 9.73x enlargements with two GIMP methods, three GEGL methods, and three candidate GEGL methods for which patches are provided in https://bugzilla.gnome.org/show_bug.cgi?id=619314 The enlargements, named A.png to H.png, are found in the tar archive http://web.cs.laurentian.ca/nrobidoux/misc/textenlargementtests.tgz To know which method was used to produce each image (and get runtimes for the GEGL methods), read the KEY text file. Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
On Thu, Jun 3, 2010 at 4:00 PM, Jason Simanek wrote: > It sounds > like you are saying it should be pasted to the exact location where it > was copied from. I agree. The pasted pixels should end up exactly > where I copied them from. >From my own (user) perspective, I wholeheartedly agree: if possible, paste the pixels exactly where they came from. That saves a lot of tedious nudging. 0.02, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
Jason Simanek wrote: >> but in the majority of cases it will be in the 'wrong' position >> and it needs to be moved to be 'right'. > > Paste to new layer currently pastes the copied pixels in the top-left. > I think Gino suggested that it be changed to 'centered'. It sounds > like you are saying it should be pasted to the exact location where it > was copied from. I agree. The pasted pixels should end up exactly > where I copied them from. moving it 'right' is a user thing, because GIMP cannot guess how the resulting art has to be. I have not made up my mind about the default but exact location (when available) sounds correct, else centred. >> sounds like the solution is actually to have the new layer appear >> with the >> paste anchored in the default position, but with a selection >> around it active (same shape as used for floating paste) and >> the upcoming combined transform tool as active tool for >> moving, sizing and deforming. > > Not sure about this. I actually think the selection should be removed. > When you copy/paste text in a text editor the pasted result is just > text, not 'selected' text. bad example, because there you set the cursor before the paste to control where the paste is inserted: total control. in GIMP there is no such thing. a paste is generally moved into position after pasting. > Besides, if the pasted result is on a new > layer there should be no need for a selection. The entire layer is > dedicated to the previously selected pixels, so you should be able to > manipulate the layer without the need for the initial selection. that's better. you are right about this. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
On Thu, Jun 3, 2010 at 8:21 AM, peter sikking wrote: > Gino D wrote: > as I said yesterday, this new-layer-from-clipboard workflow > needs attention too. user efficiency (speed!) and flexibility > are important here. one aspect (as Gino points out) is default > placement of the paste on the new layer. I've already switched my keyboard shortcut Ctrl+V to be associated with 'paste as new layer' rather than the 'pasted selection' that is default. This works almost right but... > but in the majority of cases it will be in the 'wrong' position > and it needs to be moved to be 'right'. Paste to new layer currently pastes the copied pixels in the top-left. I think Gino suggested that it be changed to 'centered'. It sounds like you are saying it should be pasted to the exact location where it was copied from. I agree. The pasted pixels should end up exactly where I copied them from. > sounds like the solution is actually to have the new layer appear with the > paste anchored in the default position, but with a selection > around it active (same shape as used for floating paste) and > the upcoming combined transform tool as active tool for > moving, sizing and deforming. Not sure about this. I actually think the selection should be removed. When you copy/paste text in a text editor the pasted result is just text, not 'selected' text. Besides, if the pasted result is on a new layer there should be no need for a selection. The entire layer is dedicated to the previously selected pixels, so you should be able to manipulate the layer without the need for the initial selection. -Jason Simanek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
Gino D wrote: > Having said that, if there is no need to merge layers together, but > you simply want to manage the pasted object as indipendent layer, then > the optimal solution is to use the "Paste as New Layer" command rather > than the "Paste" command, which actually generates floating > selections. According to me, the only small drawback of the former > choice consists in the fact that such new pasted layer doesn't come > centered on the target image (as it would be convenient), whereas, on > the contrary, every floating selection (when pasted) does. as I said yesterday, this new-layer-from-clipboard workflow needs attention too. user efficiency (speed!) and flexibility are important here. one aspect (as Gino points out) is default placement of the paste on the new layer. but in the majority of cases it will be in the 'wrong' position and it needs to be moved to be 'right'. so I think the new layer should appear with the paste floating on it in default position, ready to be moved and/or anchored. In this new layer scenario I think the controls for opacity and blend mode should not be there (on canvas) because the new layer will take care of that. hmmm, thinking about it a bit more, this sounds like the solution is actually to have the new layer appear with the paste anchored in the default position, but with a selection around it active (same shape as used for floating paste) and the upcoming combined transform tool as active tool for moving, sizing and deforming. but that is a thing for the future... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
Hi. 2010/6/2 Jason Simanek : > > Thanks for pointing out the usefulness of floating selections for > scripting/plugins. That makes a lot of sense. But if that is the only > usefulness for this special type of layer I think it should be a special > behavior that can be employed by script and plugin writers, not the default > in the GUI. > > What Gino just told me is that the floating selections are a special type of > layer whose special properties can only be perceived or employed by scripts. > How would a normal mouse-user derive any usefulness from the qualities of > this special layer? > > In this case it seems the interest in making Gimp scriptable has overridden > the interest in making Gimp's UI intuitive. > > -Jason Simanek > Though previously I myself have stressed the importance of the floating selections for scripting, nevertheless I think that even the GUI environment takes advantage of what these objects permit to do, that is the fusion of a pasted/created layer into another drawable without losing the initial characteristics of the latter. Having said that, if there is no need to merge layers together, but you simply want to manage the pasted object as indipendent layer, then the optimal solution is to use the "Paste as New Layer" command rather than the "Paste" command, which actually generates floating selections. According to me, the only small drawback of the former choice consists in the fact that such new pasted layer doesn't come centered on the target image (as it would be convenient), whereas, on the contrary, every floating selection (when pasted) does. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] parasite & dirty flag
Hi all... I have another question about parasites: I see that when I attach a parasite to an already saved XCF image, the image is not marked as dirty... so there is no warning at all when one close the image and/or gimp is this the correct behaviour ? I was expect gimp to ask me to save the image before closing. If this is ok, is there a way for a plug-in to mark an image as dirty ? thanks a lot Giampaolo ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] parasite usage
Hello saulgoode thanks a lot for your great explanation... I'm looking at the GIH plug-in right now. . BTW (for other novices) there are some useful info in the doc-devel/parasite.txt file I miss when I post the msg :-( best regards Giampaolo 2010/6/3 : > If I understand correctly, libgimpbase/gimpparasiteio.c does not > actually contain any functionality which your plug-in should be making > use of; instead it is the intended centralized location for the > parasite conversions to be placed for GIMP's "standardized" parasites, > i.e., the ones supported by GIMP core and its official plug-in. It > does not appear that this intended convention has always been followed > -- for example, the gfig plug-in processes its parasites within its > own source files -- though parasites in general aren't used as much as > they could be. > > The GIH plug-in (for image pipes) is apparently the only code which > currently processes its parasites in the gimpparasiteio.c file, and it > seems to me an excellent example of how you should handle your own > parasites. As you can see from the source, it is basically an > associated list of pairs of structmember:value each separate by spaces > (if you need to use colons or spaces in your data then you should > choose different delimiters). > > As a third-party plug-in, you will not be placing your parasite > handling in libgimpbase/gimpparasiteio.c; however, I would recommend > following the approach used for the GIH image pipe plug-in. As an > associated list, it will be trivial to later add or remove struct > members and maintain both forward and backward compatibility. If at > some point in the future your plug-in were to be accepted as an > official part of the GIMP distribution, then it might become > appropriate to move the parasite handling from your plug-in to the > libgimpbase/gimpparasiteio.c file. > > > > ___ > 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] parasite usage
Quoting Giampaolo Bellini : >I'm writing my first first plugin for gimp and I'm looking for more > info about parasite: expecially, I wonder if there is a standard way > to improve parasite's compatibility between different plugin > revisions... what if, for example, I add, change or remove a parameter > from my parasite struct ? > > is there a way, then, to access parasites saved with previous version > of the plug-in ? > > I see that there are some serialize/deserialize functions in > gimpparasiteio but missing usage info... are them for solve this kind > of problems or I'm looking at the wrong direction ? If I understand correctly, libgimpbase/gimpparasiteio.c does not actually contain any functionality which your plug-in should be making use of; instead it is the intended centralized location for the parasite conversions to be placed for GIMP's "standardized" parasites, i.e., the ones supported by GIMP core and its official plug-in. It does not appear that this intended convention has always been followed -- for example, the gfig plug-in processes its parasites within its own source files -- though parasites in general aren't used as much as they could be. The GIH plug-in (for image pipes) is apparently the only code which currently processes its parasites in the gimpparasiteio.c file, and it seems to me an excellent example of how you should handle your own parasites. As you can see from the source, it is basically an associated list of pairs of structmember:value each separate by spaces (if you need to use colons or spaces in your data then you should choose different delimiters). As a third-party plug-in, you will not be placing your parasite handling in libgimpbase/gimpparasiteio.c; however, I would recommend following the approach used for the GIH image pipe plug-in. As an associated list, it will be trivial to later add or remove struct members and maintain both forward and backward compatibility. If at some point in the future your plug-in were to be accepted as an official part of the GIMP distribution, then it might become appropriate to move the parasite handling from your plug-in to the libgimpbase/gimpparasiteio.c file. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
