Boost logo

Boost :

Subject: Re: [boost] [gui] Help with a little experiment.
From: Giorgio Zoppi (giorgio.zoppi_at_[hidden])
Date: 2011-06-22 12:25:05


2011/6/21 Germán Diago <germandiago_at_[hidden]>:
> El 21/06/11 14:03, Giorgio Zoppi escribió:
>>
>> It should make little sense to me having to code all the GUI in C++.
>> We are in 2011,
>> processors with CMP and parallel graphics processors, even in embedded
>> world (Cortex A9).
>>
>> +i would aspect a language easy for non programmers gui (ie. qml, xml).
>> This will move the focus from programmers to graphic designers doing a
>> gui. This could be a
>> straightforward step to give them more work and free smart programmers
>> for hard stuff.
>
> The point for me is the same. I don't want to have a DSEL exclusively.
> I want to have a runtime language as well (resembling the DSEL probably).
>
> If the DSEL is declarative, I don't see much difficulty for a non-programmer
> to
> learn it. And of course, I agree with all you say.
>
> My use case for embedding a GUI is that I can use a gui file in C++ as a
> resource
> without a precompilation step. But it's not a substitute for a C++ file. On
> top of
> the dsel you could make a gui designer easily, but if you want to generate
> that one
> at runtime, it should be possible as well. So the thing is to be able to do
> both things
> and use the more convenient for the use case. I think that having the gui
> embedded
> in c++ at compile time is bad as long as it's easy to use. Even you could
> make
> a designer use the "runtime" DSEL which would be identical to the
> compile-time api
> and later, when deploying, replace that with the embedded dsel. But as I
> said before,
> this proof of concept still requires a lot of thought.

So something like VRML, and engine that interprets directives. Do i catch it?

Giorgio.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk