On Thu, Jul 2, 2009 at 2:01 AM, Gottlob Frege<gottlobfrege@gmail.com> wrote:
(sorry for the bad non online reply Blame my iPhone)
Sorry for the delay, I am still trying to digest everything.
- eve layout engine can be used separately from the scripting language ie directly in code
You mean the Eve engine right? I'm still trying to put up a basic example of using eve with cppgui. But am having a really hard time finding enough information on how to do so. I couldn't find any example, and the only tutorial I found in adobe site is really strange. Even uses boost::ref(new X), where I have no idea how lifetime is dealt with. I'm feeling kinda stupid for not being able to navigate adobe site well. All I seem to find is overview and reference information.
- I helped write a DSEL that was as eve like as possible given the constraints of c++.
This is indeed cool!
Of course that didn't make it's way out of adobe but it is definitely doable. Boost proto would now make it that much easier.
Surely.
I'm not against a springs and struts system, but think about what your goals really are.
Maybe cppgui is not really a GUI library. But a widget system. I think even a minimum of autoresizing, and layout is needed with this. So that if someone wants to use it alone, he still can.
An interface needs to be properly aligned and logically grouped. The more that can be done automatically the better. The ultimate goal is to describe the data model and have the interface be automatic (and yet still aestetic).
But these should probably be decoupled from cppgui. Maybe more libraries should be written together, which could work decoupled from each other. Just like adobe does with adam and eve.
Eve is a step in that direction. We should strive to do as well or better.
Ok. I'm buying. How should we procede? I think cppgui should be only a widget system with signals, coordinate systems, etc. The layout and property systems should be decoupled. Cppgui should be be workable with eve, and with a new layout system as well.
We need to concentrate on properly describing the data first. A language (c++ or other) that says 'this data us a number (with min max etc)' or not only is this a string, but it is an email address (so that interfaces like the iPhone can adapt with @ symbols etc).
How do you intent this to work, without having to define all possible cases up-front, allowing extensibility?
Once we have the data description, we can build widgets that can 'advertise' what data types they can display/edit.
I think widgets should be very generic. A push_button displays strings, a image_button displays images. There should be no restriction if it is an email address or a number. The same goes for edit boxes. The restriction should come as a controller of these widgets. Connecting to signals. These should probably be part of a input/output system for these data types.
Then the layout engine can pick the best widget given the data model and the space constraints. For example, you might pick 3 radio buttons for clarity of choice or a dropdown list if little space is available. This should be decided at the layout level.
That would be really cool.
This is all doable. I've seen and/or built all the necessary building blocks to make it so.
Ok. Then there should be 3 libraries? Widget system, layout system and a data model system?
Tony
Thanks, -- Felipe Magno de Almeida