Fl_Text_Display regression? Or API change?

[Gonzalo Garramulo]

FLTK git hash:

a1d3bf182e6c085779b6e7e7315bf15f384f7112

Fl_Text_Display when its wrap_mode is set to WRAP_NONE or WRAP_AT_COLUMN
will not display a vertical scrollbar.

Also, it seems now it is needed to call redraw() to see the contents
update, at least on Linux.

--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 3/19/24 15:27 Gonzalo Garramulo wrote:
> FLTK git hash:
>
> a1d3bf182e6c085779b6e7e7315bf15f384f7112
>
> Fl_Text_Display when its wrap_mode is set to WRAP_NONE or
> WRAP_AT_COLUMN will not display a vertical scrollbar.
>
> Also, it seems now it is needed to call redraw() to see the contents
> update, at least on Linux.

Can you reproduce the issue with test/editor?

[Gonzalo Garramulo]

El 19/3/24 a las 11:37, 'Albrecht Schlosser' via fltk.coredev escribió:

>
> Can you reproduce the issue with test/editor?

No, and neither with my own python editor.  Fl_Text_Editor seems not to
suffer from this.  Only Fl_Text_Display.

--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 3/19/24 15:46 Gonzalo Garramulo wrote:
>
> El 19/3/24 a las 11:37, 'Albrecht Schlosser' via fltk.coredev escribió:
>>
>> Can you reproduce the issue with test/editor?
>
> No, and neither with my own python editor.  Fl_Text_Editor seems not
> to suffer from this.  Only Fl_Text_Display.

The reason why I asked was because Fl_Text_Editor is a subclass of
Fl_Text_Display. If this works it's very likely that the Fl_Text_Display
alone works as well. I tested particularly that the scrollbars appear as
required.

This makes me think that it is something with your usage that makes it
fail. I'm not aware of any recent changes that would obviously change
the scrollbar behavior (but that may be wrong).

Can you either use `git bisect` to find the commit that caused it (if
this was the case) or provide a small test case that shows the issue?

[Gonzalo Garramulo]

El 19/3/24 a las 12:20, 'Albrecht Schlosser' via fltk.coredev escribió:

> On 3/19/24 15:46 Gonzalo Garramulo wrote:
>>
>> El 19/3/24 a las 11:37, 'Albrecht Schlosser' via fltk.coredev escribió:
>>>
>>> Can you reproduce the issue with test/editor?
>>
>> No, and neither with my own python editor.  Fl_Text_Editor seems not
>> to suffer from this.  Only Fl_Text_Display.

Okay.  After digging, I found what it was.  I was subclassing
Fl_Text_Display and initializing its Fl_Text_Buffer in the constructor like:

    mBuffer = new Fl_Text_Buffer();

instead of calling the textdisplay->buffer() function.  It turns out
textdisplay->buffer() sets a callback that counts lines when wrap_mode()
is not set to WRAP_AT_BOUNDS.  Changing my code to:

     Fl_Text_Buffer* buf = new Fl_Text_Buffer();
     buffer(buf);

Find attached a sample program for testing.

--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 3/20/24 17:53 Gonzalo Garramulo wrote:
> Okay.  After digging, I found what it was.  I was subclassing
> Fl_Text_Display and initializing its Fl_Text_Buffer in the constructor
> like:
>
>     mBuffer = new Fl_Text_Buffer();
>
> instead of calling the textdisplay->buffer() function.  It turns out
> textdisplay->buffer() sets a callback that counts lines when
> wrap_mode() is not set to WRAP_AT_BOUNDS.  Changing my code to:
>
>      Fl_Text_Buffer* buf = new Fl_Text_Buffer();
>      buffer(buf);
>
> Find attached a sample program for testing.

I'm glad you found the issue.

FTR: The only thing we could do in FLTK to prevent such kinds of errors
would be to make some of the protected members private but
Fl_Text_Display is such a "beast" that I wouldn't want to open that can
of worms.

And we need to take backwards compatibility into account: reducing
visibilty from protected to private is not only an ABI breaking issue
(which we could do in 1.4.0) but it's also an API issue (breaking
contracts). Nothing we'd want to do.

[Gonzalo Garramuño]

On 3/20/2024 2:26 PM, 'Albrecht Schlosser' via fltk.coredev wrote:
> On 3/20/24 17:53 Gonzalo Garramulo wrote:
>> Okay.  After digging, I found what it was.  I was subclassing
>> Fl_Text_Display and initializing its Fl_Text_Buffer in the constructor
>> like:
>>
>>     mBuffer = new Fl_Text_Buffer();
>>
>> instead of calling the textdisplay->buffer() function.  It turns out
>> textdisplay->buffer() sets a callback that counts lines when
>> wrap_mode() is not set to WRAP_AT_BOUNDS.  Changing my code to:
>>
>>      Fl_Text_Buffer* buf = new Fl_Text_Buffer();
>>      buffer(buf);
>>
>> Find attached a sample program for testing.
>
> I'm glad you found the issue.
>
> FTR: The only thing we could do in FLTK to prevent such kinds of errors
> would be to make some of the protected members private but
> Fl_Text_Display is such a "beast" that I wouldn't want to open that can
> of worms.
>

I thought the same, and was about to suggest it.  But... you can have
multiple shared Fl_Text_Buffers or a single one used in one
Fl_Text_Display and you might want to delete them in the destructor like
I do.  Making the variables private would prevent you from deleting them.

I think the best solution would be to document this with a note in the
buffer() function.

[Albrecht Schlosser]

On 3/20/24 18:59 Gonzalo Garramuño wrote:
> On 3/20/2024 2:26 PM, 'Albrecht Schlosser' via fltk.coredev wrote:
>> I'm glad you found the issue.
>>
>> FTR: The only thing we could do in FLTK to prevent such kinds of errors
>> would be to make some of the protected members private but
>> Fl_Text_Display is such a "beast" that I wouldn't want to open that can
>> of worms.
>>
> I thought the same, and was about to suggest it.  But... you can have
> multiple shared Fl_Text_Buffers or a single one used in one
> Fl_Text_Display and you might want to delete them in the destructor
> like I do.

I may misunderstand what you wrote above but I'd say it's the opposite:
you can have one (shared) Fl_Text_Buffer attached to multiple
Fl_Text_Displays at the same time.

> Making the variables private would prevent you from deleting them.

Making the variables private would only prevent direct access to them.
If we did that we'd obviously have to provide read-only accessor methods
for whatever users might need and the existing methods to attach a text
buffer to and remove it from an Fl_Text_Display. Of course you could
still delete the Fl_Text_Buffer object but you'd have to maintain a kind
of reference counting yourself.

> I think the best solution would be to document this with a note in the
> buffer() function.

I agree.