Re: [boost] [rfc] cppgui

Subject: Re: [boost] [rfc] cppgui
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2009-07-16 08:46:38

On Thu, Jul 16, 2009 at 3:19 AM, Gottlob Frege<gottlobfrege_at_[hidden]> wrote:
> On Sat, Jul 11, 2009 at 2:33 PM, Felipe Magno de
> Almeida<felipe.m.almeida_at_[hidden]> wrote:

[snip]

> YES.  I was thinking code from Boost.Python/LangBinding but I see that
> fusion has struct-to-fusion adaptor stuff, which would work great.
>
>>
>> How about a tag?
>>
> ....
>> Yes, but these should static information IMO.
>
> Since the widgets are coded and compiled, then obviously their
> capabilities are static (until someone writes a widget that does
> nothing but load and execute Python code or something....)

That means the information would have to become static sometime anyway.
I think it is better in the layout (parser?) then.
This makes connecting widget system with the layout a lot easier.
And allows for direct use of static DSELs to generate the layout, reusing
the static information already there.

> But the 'build_ui_for_data(data)' tends to be more dynamic.  Or a
> combination of the 2.  ie the data is statically typed, but some of
> the UI decisions are dynamic (ie from RC file or script file etc).
>
> Lots to think about here.  I've written code where the data types and
> widgets are 'plug-ins' - ie from DLLs.  Think of video effects
> plugins, or 3rd party Photoshop image filters - Photoshop knows very
> little about the data params required by the plugin, nor what widgets
> the plugin needs to use. (Or look at something like the OpenFX API for
> an example.)  Traditionally the answer to this has been to see the
> data as a black-box and get the plugin to do all the UI itself.  But
> if the plugin could describe the data (or at least some of it) and/or
> describe the widgets it could supply, then you could mix the custom
> plugin UI with the standard Photoshop (or whatever 'host' app) UI.
> This is particularly important for apps like AfterEffects, that want
> to animate each x/y/z datum separately.

Then a generic layer woudl have to be written for these applications,
that's all.
With a more dynamic connection between these plug-ins.
It would have to write something that translates into that today's
assemblage code. Which should be pretty straightforward. More so than
writing the actual assemblage code.

> Anyhow, just saying there is a place for the dynamic side.
> but that doesn't mean we can't have both:

Dynamic can be written on top of static.
Think static polymorphism vs dynamic polymorphism.

> lower layer: static info:
>   <int_tag, etc>
>
> higher layer: dynamic info:
>   "int type", etc
>
> the higher level then needs to do (ugly) if/else code to convert high
> level to static level (and add checks, assertions, etc).

Kinda. Overloads and templates help mapping everything much more easier.

>> I do like where this is going.
>
> It might be going in many different directions - we need to be careful here.
> It is at least *coming from* many different directions.
> For me, I'm familiar with writing UI scripts, *which I can edit while
> the program is running* (ie as long as the dialog being edited isn't
> up) without changing my C++ code.  Very dynamic!  (I also want to let
> the end-user modify the UI)
>
> I suspect your cases are more static - possibly hard-coding all the UI
> in C++.  I DSEL would definitely be useful here.

There's no reason we can't have both.

> Lastly, just because the 'ideal' is some large (impossible?) goal, it
> doesn't mean you can't write something useful now.  Looking at the big
> goals just helps keep the small steps going in the right direction.
>
> Tony

Regards,
-- 
Felipe Magno de Almeida