#272 improved CLIPBOARD and PRIMARY per X conventions
OK, here's a redone version of that patch. I think it
works now. There should be anymore uncertainty about
the appearance of the plot or text.
However, it might be difficult to understand without
explanation. We can change the behavior.
This demo is meant for OpenWriter (or anything that has
Paste Special...). The commands are
<double click> - make coordinate the "selection"
's' - make the graphic Pixmap the "selection"
't' - put some sample text into "clipboard"
'c' - put the graphic Pixmap into "clipboard"
The selections *overwrite* one another. The clipboard
keys *do not overwrite*, currently. (Watch the number
of target Atoms to get a feel for what is going on
internally.)
Another "spliff" factor is to watch the gnuplot X11
title. When something is selected in the window, the
title indicates so. Watching this will give you an
idea why you can only use the center mouse button to
copy a window once into OpenWriter. As soon as you
paste, OpenWriter selects the graphic you pasted so
that the Gnuplot window graphic is de-selected.
(Oddly, it doesn't do that for selected mouse coordinates.)
The clipboard buffer remembers the Pixmap contents.
The selection does not.
Dan
patch for gplt_x11.c and mouse.c
Logged In: YES
user_id=704782
I forgot. If after you copy both Pixmap and text (i.e., 'c'
and 't') you are wondering how in OpenWriter to choose, go
to "Paste Special...". I know, a lot of apps might not have
that; so yes, changes may be necessary... but I think X11
term options is the way to deal with that.
Dan
Logged In: YES
user_id=235620
In preparation for a code freeze and the run-up to a release of
version 4.2, existing bugs and patchsets are being prioritized.
This patchset is not on my (sfeam) list for inclusion in 4.2 and
is therefore being marked as priority 2.
Note that this does not mean it is a bad patch, or that it won't
be incorporated into cvs after 4.2 is released. We can
re-evaluate priorities after 4.2 is out.
If you want to argue for immediate reconsideration - go right
ahead; but do so quickly!
Ethan Merritt
patch for gplt_x11.c and mouse.c, option for XPM library
Logged In: YES
user_id=704782
Ready to go, as far as a prototype is concerned. All this
would need is a fixup for term->set_clipboard().
This now also has highlighting. Recall:
<double click> - "select" mouse coords
't' - "clipboard" some sample text
's' - "select" the pixel map
'c' - "clipboard" the pixel map.
Also, if you are adventurous, you can comment out the line:
/*#define USE_X11_XPM*/
and add -lXpm to the list of libraries in the Makefile to
have gnuplot_x11 support image/x-xpixmap, i.e., can import
into programs like Abiword.
Dan
Logged In: YES
user_id=704782
May have the core issue with the no-transfer bug solved.
Properly handling MULTIPLE seems to have fixed operation in
OpenWriter.
Dan
made MULTIPLE handle properly
ready for review
Logged In: YES
user_id=704782
Attached is the completed patch. All reference to
EXPORT_SELECTION for X11 terminal has been removed in code
and documentation.
I've modified the term function to:
set_clipboard(int, char *)
That gives some flexibility of char * being "string", ""
(null string), or NULL to control behavior. (E.g., for the
X11 terminal, "string" means store that text, "" means store
the plot titlestring, and NULL means store the bitmap.) The
int is the buffer number and also is terminal specific,
e.g., some terminals may map all buffer numbers to the same
buffer.
The one thing there really still isn't control for is
clearing a buffer. That would probably need another
variable unless one wants to have such information encoded
in the buffer number variable. E.g., 0 store to buffer, 1
erase buffer.
The code is set up for:
<double click> - "select" mouse coords
't' - "clipboard" the plot title
's' - "select" the pixel map
'c' - "clipboard" the pixel map
I've left in some fprintf commands to assist understanding
by the reviewer. These should be easy to spot as I've left
them formatted all the way to the left inside the file.
Oh, and don't forget that image/x-xpixmap MIME is supported
if the -lXpm library is included and /*#define USE_X11_XPM*/
is uncommented. Currently there is no configuration for XPM
in the build process that I'm aware of. (Maybe should be as
wxWidgets may also make use of it.)
Dan
update to CVS, ready for testing
Logged In: YES
user_id=704782
Originator: YES
File Added: selection-djs-7feb2007.patch
update of the key bindings
Logged In: YES
user_id=704782
Originator: YES
Changed to these bindings
'ctrl-c' - "clipboard" the pixel map
'alt-s' - "select" the pixel map
'ctrl-t' - "clipboard" the plot title
File Added: selection-djs-30may2007.patch
Logged In: YES
user_id=704782
Originator: YES
I don't have KDE, but I assume Klipper is more versatile than anything Gnome has. However, the patch works so much better than CVS under Gnome. Supposedly the CVS version will automatically place x11 term plots into a clipboard, but I don't see any way of retrieving them if they are there. I try pasting into OpenOffice Draw, KolourPaint, OOWriter, nothing. But with the patch, I type Ctrl-c and KolourPaint's little clipboard icon lights up and I can Ctrl-v an image into the canvas.
I think what this patch has that CVS doesn't (it's been a while) is the proper convention of sending Atoms about the X system.
As for the issue about Ctrl-c being a recent convention and wanting to have some other key be "copy-to-clipboard", in some sense that is another issue. The code in gplt_x11.c regarding Atom send/receive would probably be the same, but recall that gnuplot x11 term was programmed to interpret key presses. Perhaps that isn't the proper way of dealing with x11 key press. Maybe there is a more sophisticated interface that allows the remapping of keys (just like the readline interface allows remapping of keys) at a lower level than gplt_x11.c. That is, rather than Ctrl-c making all its way to the mouse.c code, maybe it should be stopped before reaching gnuplot_x11 and the lower level code sends the atom to gnuplot_x11 requesting something for the clipboard. In that case, it would probably be something similar to the gnu-readline/builtin-readline compiler switch.
Anyway, I added a version of the patch (21jun2007) in which the comments about the atom traffic are removed. If you want to see the traffic taking place, look to the previous patch (30may2007).
File Added: selection-djs-21jun2007.patch
removed atom traffic messages