Re: [boost] [rfc] cppgui

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

On Thu, Jul 2, 2009 at 2:01 AM, Gottlob Frege<gottlobfrege_at_[hidden]> 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