Fl_Terminal selection_text() methods

[Albrecht Schlosser]

Hi, Greg and others,

should the methods Fl_Terminal::selection_text_len() and Fl_Terminal::selection_text() be public rather than protected?

Currently they are protected. Was this intentional?

My intention is to copy text from Fl_Terminal to the clipboard. In this special case (test/handle_keys.cxx) I disabled keyboard input for this instance of Fl_Terminal, hence users can't use ctrl/c to copy text although text selection with the mouse works.

Since it would generally make sense to copy only parts of the entire text I thought about the "simple" approach to let the user select text (with the mouse) and then let them click the "Copy" button.

Code:

void copy_cb(Fl_Widget *b, void *) {

Terminal *tty = ((app *)b->window())->tty;

int len = tty->selection_text_len();

if (len <= 0) {

fl_message("Please select text with the mouse and then click the copy button.");

tty->take_focus();

return;

}

const char *text = tty->selection_text();

Fl::copy(text, len, 1, Fl::clipboard_plain_text);

fl_message("The selected text has been copied to the clipboard.");

free((void *)text);

tty->take_focus();

}

However, this can't be compiled because both selection_text_len()  and selection_text() are protected. This code works well if I make these two methods public.

The docs state:
```
Return text selection (for copy()/paste() operations)

• Returns allocated NULL terminated string for entire selection.
• Caller must free() this memory when done.
• Unicode safe.

```

I wonder why these methods are protected. This doesn't seem to make sense to me. They are well documented and "read-only".

[Greg Ercolano]

On 3/12/24 06:28, 'Albrecht Schlosser' via fltk.coredev wrote:

should the methods Fl_Terminal::selection_text_len() and Fl_Terminal::selection_text() be public rather than protected?
Currently they are protected. Was this intentional?

    While intentional, I can see making it public, if for no other purpose to be consistent
    with the other widgets that allow access to selections publicly.

    My thinking was that manipulation of this kind of thing would be primarily in the
    context of a derived class (such as implementing a popup menu to provide Copy/Paste),
    and therefore protected. Also, I would think someone doing this might also want access
    to the color/attribute information, which starts getting into the internals, as there's no
    "standard" way to access color information that I'd think would be safe to be public.

    Anyway, I'll change it to be public, as these methods work with simple text,
    devoid of color/attribute information. Commit forthcoming.

[Albrecht Schlosser]

On 3/12/24 20:50 Greg Ercolano wrote:
>
> On 3/12/24 06:28, 'Albrecht Schlosser' via fltk.coredev wrote:
>
>> should the methods Fl_Terminal::selection_text_len() and
>> Fl_Terminal::selection_text() be public rather than protected?
>> Currently they are protected. Was this intentional?
>
>     While intentional, I can see making it public, if for no other
> purpose to be consistent
>     with the other widgets that allow access to selections publicly.

Yep, sounds good.

>     My thinking was that manipulation of this kind of thing would be
> primarily in the
>     context of a derived class (such as implementing a popup menu to
> provide Copy/Paste),
>     and therefore protected. Also, I would think someone doing this
> might also want access
>     to the color/attribute information, which starts getting into the
> internals, as there's no
>     "standard" way to access color information that I'd think would be
> safe to be public.

I agree, you can always want to access more, but having access to the
(selection) text seems sensible.

> Anyway, I'll change it to be public, as these methods work with simple
> text,
>     devoid of color/attribute information. Commit forthcoming.

Thanks.

[Albrecht Schlosser]

On 3/12/24 21:01 'Albrecht Schlosser' via fltk.coredev wrote:

Anyway, I'll change it to be public, as these methods work with simple
text,
    devoid of color/attribute information. Commit forthcoming.

Thanks.

... and while you're at it ...

I noticed two minor (?) issues with mouse selection:

(1) I can't select the full text of one line up to and including the newline. Whenever I drag the mouse to the beginning of a line the first character of that line gets included in the selection. This is different than e.g. the behavior in Fl_Text_Display/_Editor.

(2) The text(false) method outputs one additional line at the end. Since I fixed buffer trimming (commit aa02a0297be) this is "only" an additional LF character but it's still not correct. I looked into it but maybe you can find the culprit and fix it easier than me.

Thanks for this great widget, BTW. As you can see I'm now using it also in test/handle_keys.cxx for interactive output. I was looking for a better widget but its printf() and similar methods to output text made it unique.

[Greg Ercolano]

    Fixed in 13526f04a

    Had to commit blind because I can't seem to build FLTK right now due to
    an error in unrelated code (mentioned separately in another thread),

[Greg Ercolano]

On 3/12/24 13:18, 'Albrecht Schlosser' via fltk.coredev wrote:

... and while you're at it ...
I noticed two minor (?) issues with mouse selection:

(1) I can't select the full text of one line up to and including the newline. Whenever I drag the mouse to the beginning of a line the first character of that line gets included in the selection. This is different than e.g. the behavior in Fl_Text_Display/_Editor.

(2) The text(false) method outputs one additional line at the end. Since I fixed buffer trimming (commit aa02a0297be) this is "only" an additional LF character but it's still not correct. I looked into it but maybe you can find the culprit and fix it easier than me.

    Mmm, I'll take a look.

Thanks for this great widget, BTW. As you can see I'm now using it also in test/handle_keys.cxx for interactive output. I was looking for a better widget but its printf() and similar methods to output text made it unique.

    Ah, I noticed that (new?) test program while checking test programs that used Fl_Terminal.
    Looks interesting but I didn't give it a full try out to see what it did.

[Albrecht Schlosser]

On 3/12/24 22:03 Greg Ercolano wrote:
>
> On 3/12/24 13:18, 'Albrecht Schlosser' via fltk.coredev wrote:
>
>> ... and while you're at it ...
>> I noticed two minor (?) issues with mouse selection:
>>
>> (1) I can't select the full text of one line up to and including the
>> newline. Whenever I drag the mouse to the beginning of a line the
>> first character of that line gets included in the selection. This is
>> different than e.g. the behavior in Fl_Text_Display/_Editor.
>> (2) The text(false) method outputs one additional line at the end.
>> Since I fixed buffer trimming (commit aa02a0297be) this is "only" an
>> additional LF character but it's still not correct. I looked into it
>> but maybe you can find the culprit and fix it easier than me.
>
>     Mmm, I'll take a look.
>

>     Ah, I noticed that (new?) test program while checking test
> programs that used Fl_Terminal.
>     Looks interesting but I didn't give it a full try out to see what
> it did.

Yes, it's new, and its sole purpose is to test keyboard events. I found
the issues I reported above by using this test program, trying to select
text (with the mouse) and then copying the selected or the full text to
the clipboard.

You can test this yourself with the latest version (commit 9f4cea25b):

- Click the copy button w/o selecting text for full text output to the
clipboard.
- Select text and click the copy button to copy the selected portion to
the clipboard.


BTW, as I noticed, `git pull` should also solve the GTK plugin error on
Ubuntu 20, fixed by Manolo in commit 14d7218ac.