[ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File ]

STR #855

Trouble Report Files:

No files

Trouble Report Comments:

	Name/Time/Date	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 ]