font property manipulation in FLTK label text

[Paul Hahn]

In many situations, I would like a way to change font properties for different sections of text in widget labels. Primarily, I would like to manipulate font size and weight, but color would be grea, too.

Has anyone created a custom label type supporting this? Or for example, support for (at least a limited subset of) markdown syntax?

[Paul Hahn]

By "change font properties" I do not mean dynamically. I mean using some sort of metasyntax like markdown or whatever embedded in the label text string.

[Greg Ercolano]

On 2020-10-10 10:01, Paul Hahn wrote:
> In many situations, I would like a way to change font properties for different sections of text in widget labels. Primarily, I would like to manipulate font size and weight, but color would be grea, too.
>
> Has anyone created a custom label type supporting this? Or for example, support for (at least a limited subset of) markdown syntax?

Might be overkill, but you could (ab)use Fl_Help_View for text labels
so that you can use HTML tags to control this.

Here I'm showing setting the attributes individually, but you could derive
a class from HtmlLabel that does this stuff so it's easier to use.

____________________________________________________________________________
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Help_View.H>

int main(int argc, char **argv) {
Fl_Window *window = new Fl_Window(340,180);
Fl_Help_View *label1 = new Fl_Help_View(10,10,200,30);

label1->color(label1->parent()->color());
label1->box(FL_FLAT_BOX);
label1->value("Test <font color=#f00>red</font> <font color=#0f0>green </font><font color=#00f>blue</font>");
label1->child(0)->hide(); // XXX: hacky way to hide private scrollbar

Fl_Help_View *label2 = new Fl_Help_View(10,40,200,30);
label2->color(label2->parent()->color());
label2->box(FL_FLAT_BOX);
label2->value("Test <b>bold </b><i>italic</i> normal.");
label2->child(0)->hide(); // XXX: hacky way to hide private scrollbar

window->end();
window->show(argc, argv);
return Fl::run();
}
____________________________________________________________________________

CAVEATS

BOX TYPE
--------
Seems Fl_Help_View won't let me set the box() type to FL_NO_BOX,
so I had to use FL_FLAT_BOX to hide the borders, which means the
bgcolor has to match the parent widget, which is why I had to use parent()->color()
to make the label "seamless".

The reason for this apparent requirement is probably because text can have
different bgcolors.

SCROLLBARS
----------
Sucks that there isn't a clean way to access the scrollbars through the API
to disable them (see XXX markers above), as they come on unconditionally.

Had to hack disabling the vertical scrollbar by using child(0).

The Fl_Help_View class should really allow access to the internal scrollbars,
either as public methods that return pointers (other widgets do this),
or at least make them protected so derived classes can access and manipulate them.

Maybe this can be done for 1.4 .. dev vote?

[Greg Ercolano]

On 2020-10-10 11:41, Greg Ercolano wrote:

On 2020-10-10 10:01, Paul Hahn wrote:

Has anyone created a custom label type [supporting, for example, markdown syntax?]

	Might be overkill, but you could (ab)use Fl_Help_View for text labels
	so that you can use HTML tags to control this.

	Here I'm showing setting the attributes individually, but you could derive
	a class from HtmlLabel that does this stuff so it's easier to use.

        [example code snipped]

   Here's a screenshot for when you compile and run that example (forgot to include it):

[Albrecht Schlosser]

On 10/10/20 8:41 PM Greg Ercolano wrote:
>
> Might be overkill, but you could (ab)use Fl_Help_View for text labels
> so that you can use HTML tags to control this.

> [...]

>
> SCROLLBARS
> ----------
> Sucks that there isn't a clean way to access the scrollbars through the API
> to disable them (see XXX markers above), as they come on unconditionally.
>
> Had to hack disabling the vertical scrollbar by using child(0).
>
> The Fl_Help_View class should really allow access to the internal scrollbars,
> either as public methods that return pointers (other widgets do this),
> or at least make them protected so derived classes can access and manipulate them.
>
> Maybe this can be done for 1.4 .. dev vote?

+1, why not?

We'd need to make the methods (as) consistent (as possible) with these
"other widgets". Further discussion should follow-up in fltk.coredev if
needed (which methods, naming, public, protected, anything else?).

[Greg Ercolano]

On 2020-10-10 13:13, Albrecht Schlosser wrote:
>> The Fl_Help_View class should really allow access to the internal scrollbars,
>> either as public methods that return pointers (other widgets do this),
>> or at least make them protected so derived classes can access and manipulate them.
>>
>> Maybe this can be done for 1.4 .. dev vote?
>
> +1, why not?
>
> We'd need to make the methods (as) consistent (as possible) with these
> "other widgets". Further discussion should follow-up in fltk.coredev if
> needed (which methods, naming, public, protected, anything else?).

It actually looks like we expose the scrollbars either as public or protected.
(I thought we had methods that did this too, but apparently not..!)

I've made a new issue #146 for voting and to hash out the options
for how to expose the names in the API.

[Paul Hahn]

Indeed this does address my use cases where I currently am just using an instance of Fl_Box. I can replace those with Fl_Help_View like you describe. However, I do need some kind of solution that can work with labels for certain other widget classes. Specifically, I have a button class (derived from Fl_Button) with its label text centered on it. What to do there?

[Paul Hahn]

As an alternative to a suitable label type, it would be nice if there were just a function fl_html_draw() that could be called from a sub-class's re-implemented draw() method!

[Greg Ercolano]

On 2020-10-10 15:40, Paul Hahn wrote:
> As an alternative to a suitable label type, it would be nice if there were just a function fl_html_draw() that could be called from a sub-class's re-implemented draw() method!

That'd be nice -- then you could just subclass Fl_Button and change draw().
Suggest it as an RFE!

It would have to parse the string on the fly, since it couldn't precompute
stuff the way Fl_Help_View can, but computers are fast these days, and limiting
the function to a subset of e.g. <font> <b> <i> etc tags might not be too hard.

[Paul Hahn]

OK. How do I submit an RFE for FLTK? Via the github repo?

[Greg Ercolano]

On 2020-10-10 18:44, Paul Hahn wrote:
> On Saturday, October 10, 2020 at 8:12:50 PM UTC-5, Greg Ercolano wrote:
>
>         That'd be nice -- then you could just subclass Fl_Button and change draw().
>         Suggest it as an RFE!
>

> OK. How do I submit an RFE for FLTK? Via the github repo?

I'd suggest starting at the main fltk.org website and using:

Bugs&Features -> Submit Bug or Feature Request

..as the instructions there give you some insight on the process of reporting.

Yes, you do end up on the github issue page, but the info on the fltk.org website
should give you some good info on how to report properly.