| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3058
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Add support for graphical copy-to-clipboard operations |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | manolo |
|---|
| Assigned To: | manolo |
|---|
| Fix Version: | 1.3-current (SVN: v10177) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
| |
| #1 | manolo
08:24 Feb 23, 2014 |
| Fl_Copy_Surface.patch
10k | |
| |
| #2 | manolo
07:18 Feb 25, 2014 |
| Fl_Copy_Surface_v2.patch
11k | |
| |
| #3 | guyben
17:53 Feb 25, 2014 |
| Fl_Copy_Surface_Linux.patch
12k | |
| |
| #4 | manolo
07:22 Feb 27, 2014 |
| Fl_Copy_Surface_Linux_v2.patch
21k | |
| |
| #5 | manolo
06:19 Mar 01, 2014 |
| Fl_Copy_Surface_v3.patch
24k | |
| |
| #6 | manolo
05:14 Mar 05, 2014 |
| Fl_Copy-Image_Surface.patch
40k | |
| |
| #7 | manolo
10:52 Mar 11, 2014 |
| Fl_Copy-Image-Paste.patch
56k | |
| |
| #8 | manolo
11:07 Mar 19, 2014 |
| Fl_Copy-Paste.patch
68k | |
| |
| #9 | manolo
01:23 Mar 20, 2014 |
| Fl_Copy-Paste_v2.patch
85k | |
| |
| #10 | manolo
09:44 Mar 27, 2014 |
| Fl_Copy-Paste_v3.patch
74k | |
Trouble Report Comments:
| |
| #1 | manolo
08:24 Feb 23, 2014 |
| I attach a patch that allows FLTK to perform graphical copy-to-clipboard operations.
It's done via a new class in the Fl_Device hierarchy called
Fl_Copy_Surface, that exploits the existing device abstraction.
A small amount of highly OS-specific code opens
this new possibility to FLTK users, that would require specialized
OS knowledge otherwise.
This class is only implemented for MSWindows and Mac OS, because
there's no unified way on the unix/Linux platform to exchange
graphical data among applications. | |
| |
| #2 | manolo
07:19 Feb 25, 2014 |
| The patch has been updated so make compiles the new
Fl_Copy_Surface.cxx file | |
| |
| #3 | guyben
10:43 Feb 25, 2014 |
| I'm working on the linux variant. I believe I'm close :)
Just wanted to say that the Makefile still isn't fixed - it doesn't recompile if Fl_Copy_Surface.H has changed. | |
| |
| #4 | guyben
10:43 Feb 25, 2014 |
| I'm working on the linux variant. I believe I'm close :)
Just wanted to say that the Makefile still isn't fixed - it doesn't recompile if Fl_Copy_Surface.H has changed. | |
| |
| #5 | AlbrechtS
15:15 Feb 25, 2014 |
| WRT Makefile: Does it work after you executed 'make depend' ? This is necessary after new files have been added. | |
| |
| #6 | guyben
18:17 Feb 25, 2014 |
| @AlbrechtS Duh!
Anyway - I've created a patch (incremental in regard to the V2 file) that implements the Fl_Copy_Surface to Linux. There's quite a bit of change, mostly to src/Fl_x.cxx as I reimplemented the entire copy protocol for images - so you can now do Fl::copy_image.
I also added BMP encoding function - in Fl_x.cxx for now - as I don't like the idea of linking with -lfltk_images just for copy operations.
Here are some thoughts (maybe I should create STRs for them):
* Fl::copy_image right now accepts raw RGB data, and only exists on Linux. I think it would be better if it accepted an Fl_Image and would be cross platform.
* In general, I think an Fl_Paged_Device that returns an Fl_Image would be fantastic. This would allow people to create their own buffering and would make Fl_Image much more useful. | |
| |
| #7 | guyben
18:20 Feb 25, 2014 |
| @AlbrechtS I meant to write "D'oh!". Apparently, it's the complete opposite of "Duh!". Or in other words - yea, that was the problem... | |
| |
| #8 | manolo
07:39 Feb 27, 2014 |
| @guyben: Great, the copy function seems to be running quite fine
on linux. I've tested it on 32-bit Debian linux doing Copy in the
device test program and
"File/Create from clipboard" in GIMP to paste the copied data.
I've found that the red and blue colors were swapped, so I
modified lines 932-934 of Fl_x.cxx exchanging the R and B lines.
Is there an endian issue here?
Also, the present code fails when Fl_Copy_Surface::print_widget()
is applied to a widget inside a window. It requires to implement
Fl_Copy_Surface::translate() and Fl_Copy_Surface::untranslate().
The implementation of these two functions is the reason why
Fl_Copy_Surface is a derived class of Fl_System_Printer.
But this implementation is not present in FLTK for Xlib drawing.
I have uploaded as Fl_Copy_Surface_Linux_v2.patch a new patch that
mainly merges Fl_Copy_Surface_Linux.patch with a few other changes
in the Mac OS-related part. | |
| |
| #9 | manolo
06:21 Mar 01, 2014 |
| With Fl_Copy_Surface_v3.patch the implementation of the proposed
new Fl_Copy_Surface class is completed and documented. | |
| |
| #10 | manolo
05:16 Mar 05, 2014 |
| The attached Fl_Copy-Image_Surface.patch adds one more new class,
Fl_Image_Surface that allows to redirect all graphics requests
to an Fl_Image object, and to draw any FLLTK widget therein. | |
| |
| #11 | manolo
11:02 Mar 11, 2014 |
| The new attached file Fl_Copy_Image-Paste.patch adds an implementation
of graphical paste to FLTK. Image (and also vectorial) clipboard data
can be pasted to FLTK that receives it as an Fl_Image*.
This is implemented for MSWindows and Mac OS only.
@guyben: do you think you can implement image-paste for Xlib?
There are 2 functions to expand/implement:
- void Fl::paste(Fl_Widget &receiver, int clipboard,
const char *mime_type = Fl::clipboard_plain_text)
should process the new case where image data is asked for
- int Fl::clipboard_contains(const char *mime_type)
should report whether the clipboard contains data of the requested type
The patch also contains a new test program, clipboard.cxx,
a clipboard viewer displaying the current textual or image
content of the clipboard. | |
| |
| #12 | manolo
11:17 Mar 19, 2014 |
| The attached file Fl_Copy-Paste.patch adds a cross-platform
implementation of pasting of graphical data to FLTK.
The Xlib implementation also supports incremental transfer
of large images.
The new Fl_Copy_Surface and Fl_Image_Surface classes are also
in the patch.
All new classes and functions are fully Doxygen-documented.
Two test programs allow exercizing the new functions:
- "device" exercizes Fl_Copy_Surface and Fl_Image_Surface.
- "clipboard" (new program) is a clipboard viewer app
which displays the textual/graphical content of the clipboard.
It exercizes the new graphical paste feature, in combination
with "device" that copies graphical data to the clipboard, or
activating "copy" in other non-FLTK apps. | |
| |
| #13 | manolo
01:25 Mar 20, 2014 |
| Please, use Fl_Copy-Paste_v2.patch because changes to file
Fl_cocoa.mm are missing from the other patches. | |
| |
| #14 | chris
04:01 May 29, 2014 |
| With the patch as it is now integrated in current SVN I observe a minor behaviour oddity (in Ubuntu 12.04) with the clipboard example program:
When there is *no clipboard data* available, pushing the "Refresh from clipboard" button makes the button selected and it stays so until the mouse is moved a few pixels.
Seems it is hanging in Fl::clipbaord_contains() during this time.
It this intentional? | |
| |
| #15 | manolo
08:31 May 29, 2014 |
| Correct: Fl::clipboard_contains() was slighted bugged when the clipboard is empty. Should be fixed with r. 10176.
Thanks Chris. | |
| |
| #16 | chris
10:29 May 29, 2014 |
| Confirming the fix!
Btw. - unrelated: got a warning compiling fl_font_xft.cxx:
fl_font_xft.cxx:276:24: Warning: »the_font« might be used uninitialized in this function [-Wuninitialized]
(message translated from german) | |
| |
| #17 | greg.ercolano
10:40 May 31, 2014 |
| > fl_font_xft.cxx:276:24: Warning: "the_font" might be used uninitialized..
Good point; looks like Manolo fixed it in r10177 | |
| |
| #18 | manolo
04:59 Jun 07, 2014 |
| Committed to the SVN repository. | |
[ Return to Bugs & Features ]
|
| |
