Fl_Help_Dialog

[Rob McDonald]

Is Fl_Help_Dialog.cxx intentionally omitted from the library?

Around src/CMakeLists.txt:60

Fl_Group.cxx
Fl_Help_View.cxx
Fl_Image.cxx

But no Fl_Help_Dialog.cxx.

Further searching reveals

Around src/CMakeLists.txt:499

Fl_Help_Dialog.cxx is included as a part of IMGCPPFILES -- which implies a dependence on the built-in image libraries (which I do not build).  Which would explain why I'm not seeing it in my build.

However, if the issue is displaying images as part of the help text, shouldn't Fl_Help_View be down in IMGCPPFILES too?

I guess I don't understand why one would work and not the other.  If Fl_Help_Dialog has a dependence on the built-in image libraries that Fl_Help_View does not, would it be possible to remove that dependence?

Rob

[Manolo]

It's true that class Fl_Help_Dialog could easily be moved to libfltk and out of libfltk_images.

Its only dependency to the image class is that Fl_Help_Dialog's constructor calls

fl_register_images() which belongs to libftlk_images and which prepares class

Fl_Help_View to correctly process images found in any input html document.

Then, it would be enough for a client app to be instructed to call fl_register_images() itself

if it expects to encounter images in future html files. A client using Fl_Help_View that doesn't call

fl_register_images() would no longer require libfltk_images at link-time.

The problem is API compatibility with FLTK before 1.4.0. FLTK 1.3 clients that use image-containing

html files and that don't call fl_register_images() themselves would stop displaying

image-containing documents correctly ,whereas they would work correctly with FLTK 1.3.x.

It's also true that class Fl_Help_Dialog is explicitly documented to belong to libfltk_images

only in 1.4. Thus, removing the call to fl_register_images() from the Fl_Help_Dialog c'tor

would not break a documented FLTK feature, but would break a de facto FLTK property.

How would other developers weigh such a hypothetical change?

[Gonzalo Garramuño]

On 5/25/2024 2:58 AM, Manolo wrote:
>
> How would other developers weigh such a hypothetical change?

Personally, I would not care.  I think Fl_Help_Dialog should be
documented ad being obsolete, as FLTK 1.4's fl_open_uri() is a much
better way of showing HTML documentation with the OS' browsers.

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

[pvrose]

On 25 May 2024, at 10:21, Gonzalo Garramuño <ggar...@gmail.com> wrote:

>
>On 5/25/2024 2:58 AM, Manolo wrote:
>>
>> How would other developers weigh such a hypothetical change?
>Personally, I would not care.  I think Fl_Help_Dialog should be
>documented ad being obsolete, as FLTK 1.4's fl_open_uri() is a much
>better way of showing HTML documentation with the OS' browsers.

I've have a, maybe singular, use case where I have a form described in HTML, and fill in fields from fields in my database. The HTML only exists as a string in memory and no URI. I then use Fl_Help_Dialog to help me print the form. And yes it may include an image.
>--
>Gonzalo Garramuño
>ggar...@gmail.com

Phil
>--
>You received this message because you are subscribed to the Google Groups "fltk.general" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
>To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/acece295-7f59-4a30-9131-d5f549375c48%40gmail.com.

[Albrecht Schlosser]

On 5/25/24 07:58 Manolo wrote:
> It's true that class Fl_Help_Dialog could easily be moved to libfltk
> and out of libfltk_images.
> Its only dependency to the image class is that Fl_Help_Dialog's
> constructor calls
> fl_register_images() which belongs to libftlk_images and which
> prepares class
> Fl_Help_View to correctly process images found in any input html document.

> ...

>
> The problem is API compatibility with FLTK before 1.4.0. FLTK 1.3
> clients that use image-containing
> html files and that don't call fl_register_images() themselves would
> stop displaying
> image-containing documents correctly ,whereas they would work
> correctly with FLTK 1.3.x.

That would seem to be a regression.

> It's also true that class Fl_Help_Dialog is explicitly documented to
> belong to libfltk_images
> only in 1.4. Thus, removing the call to fl_register_images() from the
> Fl_Help_Dialog c'tor
> would not break a documented FLTK feature, but would break a de facto
> FLTK property.
>
> How would other developers weigh such a hypothetical change?

I would leave it as-is for FLTK 1.4 for backwards compatibility, even if
this dependency was not explicitly documented in 1.3. A missing
statement in the docs would not justify to remove this implicit
functionality.

My main goal is that FLTK 1.4 enables users to migrate from 1.3 with
little or no effort at all. This includes *users* (not software
developers) to "port" existing apps from 1.3 to 1.4.

[Gonzalo Garramuño]

El 25/5/24 a las 06:38, 'pvrose' via fltk.general escribió:

I've have a, maybe singular, use case where I have a form described in HTML, and fill in fields from fields in my database. The HTML only exists as a string in memory and no URI. I then use Fl_Help_Dialog to help me print the form. And yes it may include an image.

I see.  Any reason why did not create the UI with FLTK widgets directly instead of HTML?  Or, if too complex, you went with something like pyFLTK?

[pvrose]

I didn't want to hard-code the form design. HTML gave me a bit more flexibilty.

Phil.

>
>--
>You received this message because you are subscribed to the Google Groups "fltk.general" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

>To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/83e166b2-66d1-4a30-9106-55d4dfcc1dbe%40gmail.com.