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:
> 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,
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.
-- Felipe Magno de Almeida
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk