| | [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File | SVN ⇄ GIT ]
STR #855
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Unassigned |
|---|
| Summary: | Text selection feature for Fl_Help_View widget. |
|---|
| Version: | 2.0-feature |
|---|
| Created By: | Sadysta |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| #1 | Sadysta
13:16 May 14, 2005 |
| I need to select the text in Fl_Help_View widget and copy it to the clipboard. Text-only copy would be just fine. | |
| |
| #2 | mike
09:48 May 15, 2005 |
| Reassigned to 2.0-feature... | |
| |
| #3 | Sadysta
12:00 May 15, 2005 |
| That's a pity. Thanks anyway. | |
| |
| #4 | Sadysta
11:35 Aug 09, 2005 |
| This issue is turning quite problematic in my app, so I'd like to suggest an easier but still useful fix. You could add _block_ selection functionality for now and then expand it to full text selection functionality in 2.0. AFAIK block is easy to select as it already possesses such attributes as its location (x, y, w, h) inside Fl_Help_View. So a simple check inside Fl_Help_View's handle() method and marking appropriate blocks as selected and then redrawing them with a different background colour would do the trick. | |
| |
| #5 | mike
11:42 Aug 09, 2005 |
| ... except that we have nowhere we can store the "current selection" state... | |
| |
| #6 | Sadysta
12:45 Aug 09, 2005 |
| Well, it could be copied to the clipboard instantly... or (preferably) blocks could be marked as selected permanently (i.e. additional data field in Fl_Help_Block) and a public method could be provided to retrieve the text from selected blocks. | |
| |
| #7 | Sadysta
01:32 Jun 02, 2006 |
| Frankly, I don't want to be importunate but I HAVE to ask you once more, PLEASE do something about this selection feature. It's really making my application look unprofessional and makes me unable to say "it's based on FLTK" with the pride it otherwise deserves. | |
| |
| #8 | greg.ercolano
12:38 Jun 11, 2006 |
| My situation is similar, but I've been realizing that the correct solution for me was to invoke a regular file browser from my FLTK program, and migrate away from using the HTML viewer for all but
the simplest HTML viewing purposes.
There's apparently 'standard' ways to open browsers on all platforms these days:
Mac: system("open 'http://google.com/'");
Linux: system("htmlview 'http://google.com' &");
Windows: ShellExecute(NULL, "open", "http://google.com/", NULL, NULL, SW_SHOWNORMAL);
Irix: system("( firefox '<url>' || netscape '<url>' ) &");
One possible workaround for your FLTK based help viewer is to include a "View In Web Browser" button; when the user pushes it, it opens the docs
in one of the above browsers, so the user can highlight the text.
I suppose one thing the FLTK help viewer could have is a right-click menu with a "View Source" option that opens the HTML raw text into an Fl_Text_Display viewer, so they can at least cut+paste from that.
Just some thoughts.
My guess is it's unlikely the 1.1.x FLTK Html viewer is ever going to be much better than it is, because the problem of an HTML viewing gets complex fast. Tables, for instance, makes text selection non-trivial.. but you're right, block text selection might be "easy". | |
| |
| #9 | Sadysta
13:23 Oct 05, 2006 |
| Well, I'm using Help_View for an instant messaging program. Using "View Source" option to copy some text from the chat doesn't exactly come in handy ;) | |
| |
| #10 | Sadysta
13:26 Oct 05, 2006 |
| I've read that the next version of dillo (small HTML browser) will be based on FLTK2. Maybe this is a chance to learn how a decent HTML text selection is implemented. | |
| |
| #11 | matt
05:19 Oct 06, 2006 |
| Fl_Help_Browser in FLTK1 *does* have text selection in the current SVN. I implemented that about three months ago. I am sure it can be ported relatively easily to FLTK2 - if anyone feels inclined.
The Help Browser never claimed to support HTML at any level. It is limited to what we beleive is used in simple help pages (hence the name). For more complex applications, I would suggest to embed a "serious" browser. Dillo in its next incarnation sound perfect for this task ;-) | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
