Proposal: Fluid's Flex, can we store the initial sizes in size_set

[Mo_Al_]

Hello

With the new addition of Fl_Flex into Fluid, the generated fluid code contains indices of the children whose size is set:

      Fl_Flex {} {open
          xywh {5 5 390 30} type HORIZONTAL gap 5 size_set {3  0  1  3 }
        } {
          Fl_Menu_Button {} {
            label menu open
            xywh {5 5 80 30}
          } {}
          Fl_Box {} {
            label {https://}
            xywh {90 5 60 30}
          }
          Fl_Input {} {
            xywh {155 5 205 30}
          }
          Fl_Button {} {
            label I
            xywh {365 5 30 30}
          }
        }

size_set {3  0  1  3 } appears to mean 3 widgets, child(0), child(1) and child(3). Now it seems the call to set_size depends on the size in xywh, (w for HORIZONTAL and h for VERTICAL).

The problem I'm facing when trying to add support in fl2rust, which generates Rust files from fluid files is that by the time set_size() is called, the sizes have automatically been changed by the Flex. It would either require major re-architecting the fl2rust code, or more simply storing the initial sizes in the fluid file. So something like:

size_set {3  0 80  1 60 3 30}

[melcher....@googlemail.com]

Thanks for your post. Just adding the children should not yet call the relayout, so the sizes should still be the original ones. But I can see how a wrapper may not have that option. I will take a look at my Fluid code this weekend and check if adding the size is the best way (it probably is).

If you like, we can add Rust code generation into Fluid in the FLTK master. I have a private version that generates Lua code, and I would really love to support pyFLTK out of the box.

[melcher....@googlemail.com]

I made this into a pull request, so we can merge that tomorrow. Older Fluid files that used the feature already will give a warning and may not read correctly.

https://github.com/fltk/fltk/pull/529

[Mohammed]

Thank you for this. 

Generating Rust code from fluid would be ideal as I’m not especially good at writing parsers, and I’ve had some difficulty parsing fluid files. But fl2rust is already seeing use out in the wild. The parsing it does is on a best effort basis and assumes correct fluid files. It doesn’t offer any diagnositcs unfortunately. Also Rust has many limitations with global scoped code so many features aren’t supported by fl2rust. 

Sent from my iPhone

On 4 Nov 2022, at 15:03, 'melcher....@googlemail.com' via fltk.coredev <fltkc...@googlegroups.com> wrote:

I made this into a pull request, so we can merge that tomorrow. Older Fluid files that used the feature already will give a warning and may not read correctly.

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.coredev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkcoredev/2JA-CcTbrX4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/47cd6773-d2ad-4266-a0a4-49aae60ce525n%40googlegroups.com.

[melcher....@googlemail.com]

may64...@gmail.com schrieb am Freitag, 4. November 2022 um 13:18:56 UTC+1:

Generating Rust code from fluid would be ideal as I’m not especially good at writing parsers, and I’ve had some difficulty parsing fluid files.

Fluid files are a bit inconsistent. The format is very old.

 

But fl2rust is already seeing use out in the wild. The parsing it does is on a best effort basis and assumes correct fluid files. It doesn’t offer any diagnositcs unfortunately. Also Rust has many limitations with global scoped code so many features aren’t supported by fl2rust. 

I looked at your pages. This is really great! I like the command line/library approach.

I don't know enough about Rust, but as for Lua, Fluid generates the code while designing the UI, it supports Lua callbacks already in Fluid, and you can even launch the app from within Fluid, as Lua ist just an interpreter. Calling the command line Fluid with a Lua .fd file will also simply generate a Lua file.

The Fluid UI could deactivate options that are not available in Rust that would otherwise generate a parsing error in fl2rust.

I should probably learn some Rust before I get into more details here. Sorry that Fluid is such a mess, but I'd be happy to help if you think that porting your tool is worth a try.

 

[Albrecht Schlosser]

On 11/4/22 11:46 'melcher....@googlemail.com' via fltk.coredev wrote:
> If you like, we can add Rust code generation into Fluid in the FLTK
> master. I have a private version that generates Lua code, and I would
> really love to support pyFLTK out of the box.

Sorry, I'm not keen on adding output for other languages (rust, lua,
python, ...) to fluid. Before you try doing so in the official FLTK repo
we should really discuss this in fltk.coredev where this discussion belongs.

In fact I am against adding support for other programming languages in
fluid because it would create logical dependencies between FLTK (fluid)
and those other languages and it would become another maintenance
nightmare like maintaining VS and Xcode IDE files which we fortunately
dropped in 1.4. I'm afraid that our small team wouldn't be able to
maintain all this and it would slow down FLTK maintenance even more.

These are only a few first thoughts. Please let's discuss this further
in fltk.coredev...

[Mohammed]

Maybe an easy to deserialize format like json can be used for the output of fluid, in addition to the fl format, which could eventually be phased out if necessary in a future version of FLTK/Fluid to reduce the burden of maintenance. This way it would be easy to consume ui files from lua/python/haskell/rust or any other language with FLTK bindings.

Sent from my iPhone

> On 4 Nov 2022, at 17:50, Albrecht Schlosser <Albrech...@online.de> wrote:

> --
> You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/b66d1fdc-fda2-8265-747b-dd2ad19e63f9%40online.de.

[imacarthur]

So, I get that Albrecht is not keen to add multiple languages to fluid, and I see his point: Would it not be better if we had, for example, a "contrib" folder that alternate "standalone" .fl  parsers might live in. such as Mo's flRust parser etc., then folks could add support for any other languages they like without having to get inside fluid itself...

If needs be, fluid could perhaps be extended to (optionally) output some more "modern" parser format, since the current .fl syntax evolved over deep time and harks back to a the FL days and so on.

That might go some way to resolving several recent queries, like Paul's query here: https://groups.google.com/g/fltkgeneral/c/M9YD5Oz5Rhk/m/d0ytLFIAAgAJ for example...

But I do not think fluid itself needs to be able to generate Lua, Python, Rust, etc..., these all feel like things separate parsers would do better, frankly. If we have some "well known" input...

[melcher....@googlemail.com]

Since we are now having two very similar discussion, I want to mention some attempt at documenting the .fd format here too:

Please check out this file: .fd File Format, and let me know if this is of any use. Feel free to reformat and I will try to adapt.

See also: fltk.general