After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 111082 - Using clipboard as brush
Using clipboard as brush
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Data
1.x
Other All
: Normal enhancement
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2003-04-18 11:43 UTC by Fredrik Rambris
Modified: 2006-05-16 13:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Fredrik Rambris 2003-04-18 11:43:55 UTC
I used Personal Paint and Deluxe Paint (all versions) before that on my
Amiga. To this date I have not seen a "pixel painter" that have even come
close to these tools in ease of pixel painting. Other features that I miss
have been reported before but one thing I would like to see in GIMP is to
use the clipboard as brush. But not necesary a permanent named brush. In
PPaint I just hit 'b' selected an area. It then copied (or cut if I used
right mouse button) the area to the brush buffer. I could then paint with it.
Comment 1 Sven Neumann 2003-04-18 11:49:20 UTC
You are aware that you can create a brush from the selection, are you?
You may as well bind the 'b' key to this feature. It would however
create a named brush so it's not exactly what you are asking for.
Comment 2 Alan Horkan 2003-07-23 18:38:31 UTC
Changes at the request of Dave Neary on the developer mailing list.  
I am changing many of the bugzilla reports that have not specified a target
milestone to Future milestone.  Hope that is acceptable.  
Comment 3 Dave Neary 2003-07-29 06:58:30 UTC
 
I haven't seen anything on freedesktop. Perhaps we could propose a 
serialised/deserialised TempBuf? 
 
It seems to me that it would be a very basic "chunk of data with 
header" - I guess we would need some way to identify it as image data 
so that text apps didn't barf, but I don't see any problems with 
that. It might even become an OpenDesktop standard... 
 
Dave. 
Comment 4 Dave Neary 2003-07-29 07:48:11 UTC
Ooops, wrong bug report. And s/OpenDesktop/FreeDesktop.

Dave.
Comment 5 weskaggs 2004-12-29 17:20:44 UTC
I think the best thing would be if it did create a named brush, but always used
the same name, and ran without popping a dialog or asking any questions.  It
should be pretty simple to modify the "Selection to Brush" script to work this way.
Comment 6 Sven Neumann 2004-12-29 17:41:23 UTC
Why not add a virtual brush for the content of the clipboard (the global
buffer)? Similar to the FG/BG gradient in the gradients list.
Comment 7 weskaggs 2004-12-29 23:54:50 UTC
Well, it would be annoying to lose the brush anytime you need to copy something,
especially since it would be hard to make this undoable without doing tricky things.
Comment 8 Joao S. O. Bueno 2005-01-19 02:32:19 UTC
I like the idea in #6. 
And as for the possible problem mentioned in #7 - that's why that "copy brush" 
button is there eating screen real-state, aint'it?  
Comment 9 Raphaël Quinet 2005-01-19 15:52:42 UTC
I also like Sven's suggestion in comment #6.  I had a look at select-to-brush.scm
to see if I could modify it easily.  It should not be too hard to make it
non-interactive: just remove the parameters in the script-fu-register call, use
a sensible name for the brush and call file-gbr-save in non-interactive mode.
The default brush spacing could be left at 25, or maybe it could be set
according to the size of the selection.

What should the pre-configured name be?  I thought about "Converted Selection"
or simply "Automatic" (better suggestions are welcome), but should this string
be marked for translation?  An English name could be confusing for some users
(because this one has to be understandable, to show that it is "special") and a
translated name could be annoying for those who switch languages from time to
time.

Also, should this be an additional script (keeping the old one for those who
like to adjust some parameters before saving) or should it replace the existing
one?
Comment 10 weskaggs 2005-01-19 18:30:42 UTC
Re comment #8, the "duplicate brush" button only works on generated brushes.  
Re comment #8 and comment #9, please consider that under this scheme it would be
quite easy for the user to accidentally lose the brush that she is using, with
no way to get it back.
Comment 11 david gowers 2005-09-01 19:05:44 UTC
I was trying to script something similar..
The main obstacle is that it's SLOW to refresh everything. If there was a way to
say 'reload only the gimpdata with this filename', that would make the
sel-to-brush approach more feasible (this feature is very useful, also with
patterns -- I want a pattern which can be kept uptodate with FG/BG changes so i
can draw with dither-patterns. it is awkward currently.)
Although, it would be really useful to be able to set pixel data of brushes or
patterns directly.. This would be the ideal implementation from my point of
view, it could allow plugins to perform many interesting transformations on the
pixel values.
I could code most of that if that sounds okay ( The remainder would be adding it
to PDB, which i don't understand well.)
Comment 12 brianherman 2006-04-17 23:15:24 UTC
The windows clipboard has annoyances also!
Comment 13 Michael Natterer 2006-05-16 13:12:27 UTC
Fixed in CVS:

2006-05-16  Michael Natterer  <mitch@gimp.org>

	* app/paint-funcs/paint-funcs-generic.h
	* app/paint-funcs/paint-funcs.[ch]: implement copy_color() and
	copy_color_pixels() which copy only the color bytes into a dest
	that has one byte less than src. Renamed component_pixels() to
	copy_component_pixels().

	* app/core/Makefile.am
	* app/core/core-types.h
	* app/core/gimpbrushclipboard.[ch]: new GimpBrush subclass that
	auto-updates its contents from gimp->global_buffer.

	* app/core/gimp.c (gimp_real_initialize): add a clipboard brush to
	the brush factory. Fixes bug #111082.