On Thu, Jul 16, 2009 at 3:19 AM, Gottlob Frege<gottlobfrege@gmail.com> wrote:
On Sat, Jul 11, 2009 at 2:33 PM, Felipe Magno de Almeida<felipe.m.almeida@gmail.com> 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