[rfc] cppgui

[Tomas Pecholt-2]

I think that couple of important topics were raised here. Things
like MVC, layout system and surface concept briefly described on
your website need to be thinked over in more detail because these
are going to affect how the library will be used. As Jarred
pointed out GUI library needs to learn from others strenghts and
weaknesses.

I think we should start by describing how these thigs work in
commonly used GUI libraries to get an inspiration. Then pick
up best solution as a candidate to implement in your library
(or come with new one). Of course care has to be taken to keep
everything consistent and fit to the library's interface. I think
we need some sort of wiki pages for that. My longest GUI expirience
comes from Qt and wxWidgets worlds so I can help with describing
how the things are doing there. What do you think?

Regards

Jarrad Waterloo napsal(a):

> I have experience creating GUI's in Win32, MFC, C++ Builder, Java and .NET!
> I hate to use the J word, Java, but of all of these Java's Swing had the
> best MVC architecture. I wish I tried QT but never got around to it also in
> part due to its commercial licensing. In general, I agree with Tomas and
> Felipe's comments. However there are a few extra things to keep in mind.
> Swing is easy to use in simple scenarios even with the MVC pattern. By
> default TreeView and TableView used the DefaultTreeModels and the
> DefaultTableModels. As such the only extra code was a single cast from the
> model interface to correct implementation. As such smart defaults are very
> important, as seen by the popularity of Ruby and other modern technologies.
> One major weakness on the Model side of Swing is that there is very little
> reuse on the interface specification between controls. I believe List and
> and drop down lists had separate models instead of sharing the same model.
> .NET Windows forms, which is just another Win32 wrapper, and while not MVC
> it did not make this one mistake by many but not all of there complex
> controls supporting IList.
>
> My Points:
> 1) The GUI library needs to learn from the strengths and weaknesses of
> earlier implementations.
> 2) The GUI library like any library needs to utilize smart defaults and
> implement all of the boilerplate code so that the thousands of end users
> don't have to keep writing it over and over again.
> 3) The MVC pattern should be used at the lowest level as possible to get the
> best benefits. It is easier to package Model, View, and Controller together
> into a thin wrapper than to write a complex control that has all of that
> built in and hidden; latter expecting it to be broken out. Doing the latter
> is more likely to give you the worse of both worlds rather than the better.
> There is also no need to code twice, both patterns, into a single control
> and provide the user with a switch to set the mode: bad .NET. Rather the
> contained items version should be defined in terms of the uncontained.
>
> ------------------------------------------------------------------------
>
> As far as layouts please remember:
> "A star is the delicate balance of its fusion forces trying to blow it apart
> and it gravitational mass trying to keep it together."
> Source unknown and likely not quoted exactly
>
> Most current frameworks, even web based stylesheets, gets this wrong
> resorting to the user have to resort to hard coded sizes and/or websites
> made for particular sized displays. [Gravity] Any control should be able say
> that it wants to be contracted to its smallest size, as in case of a label
> control, so as to be able to take the least amount of room thus leaving room
> for other controls. [Expansive] Any control should be able to take all
> available room so as not to waist room and thus getting rid of whitespace
> i.e. all of the remaining room. Further should layouts have any UI costs as
> it is all logic and parameterization? Let me elaborate, many libraries have
> layout controls which draw on the screen and soak up resources by creating
> windows that are never displayed because its children are likely taking up
> all available room and its not a graphically construct anyway. I can't
> remember exactly how Swing does this other than to say that layouts are not
> controls. Anyway, caution is needed as more past examples got it wrong
> rather than right.
>
>
> -----Original Message-----
> From: boost-bounces@... [mailto:boost-bounces@...]
> On Behalf Of Felipe Magno de Almeida
> Sent: Monday, June 22, 2009 8:22 AM
> To: boost@...
> Subject: Re: [boost] [rfc] cppgui
>
> On Mon, Jun 22, 2009 at 9:12 AM, Tomas<pecholt@...> wrote:
>> I also agree that using MVC pattern for more complex controls like tables
>> and trees is a good thing because of its flexibility. On the other hand
>> there are situations where you only need to fill the
>> control with data and present it to the user. In such case using MVC
>> would mean redundant typying. So I would take inspiration from Qt
>> here. For example for a tree widget, there are two options: QTreeView
>> which has MVC interface and then QTreeWidget which inherits from
>> QTreeView, plugs default model and adds some easy interface for adding
>> items etc.
>
> Yes, I think that is a good idea. The win32 has something like this
> with ListBox and ListView too.
>
>> +1 for the named parameter interface which you introduced
>
> Thanks :).
>
>> Another very important aspect is layouting the controls. I think this
>> is so important feature it should be thought over in the beginning (now).
> I
>> have seen your examples and I saw you simply set position
>> and size for each widget. This is nice but it simply doesn't work for
>> real applications from 2 reasons:
>> - it's much simpler to set size constraints for widgets like maximum
>>  size, stretching factor, borders and then let the layout system to
>>  position and size widgets automatically than do the calculations and
>>  repositioning yourself when something changes (like when user resizes
>>  the dialog)
>> - if I understand it correctly your gui can be used to write
>>  multiplatform code. Like one code for windows and linux
>>  version of the app. But on every platform the sizes of individual
>>  widgets are different, the default fonts are different and you
>>  certainly don't want to be bothered with this.
>> For the start something like vertical/horizontal layout would be
> sufficient
>
> Seems appropriate. I'll investigate it. Do you have a syntax you find
> appealing to work with named parameters in this?
>
>> It would be interesting to have an option to be be able to load GUI
>> definition from xml file. It would enable using GUI designers which
>> save time and also make code compile faster. But I understand it's
>> too early for such functionality.
>
> In win32 you can use resource files. I'll soon start support for QtDesigner
> too.
> I want every tool the platform supports to be usable by the user.
> This way the user can design its Gui with the look&feel most
> appropriate for the platform.
> I might later add some form of DSEL to create GUIs. But that won't be
> for some time.
>
> Regards,

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Jarrad Waterloo]

Sounds good! Where will this be done: on this general boost list or on
another boost and GUI specific list? "Felipe Magno de Almeida", what do you
think about layout and MVC pattern being a first generation part of your GUI
library? Is it a good idea, overly ambitious or blasphemy? Is there anyone
else out there who would like to contribute?
 
 
 
-----Original Message-----
From: boost-bounces@... [mailto:boost-bounces@...]
On Behalf Of Tomas
Sent: Wednesday, June 24, 2009 6:18 PM
To: boost@...
Subject: Re: [boost] [rfc] cppgui

I think that couple of important topics were raised here. Things
like MVC, layout system and surface concept briefly described on
your website need to be thinked over in more detail because these
are going to affect how the library will be used. As Jarred
pointed out GUI library needs to learn from others strenghts and
weaknesses.

I think we should start by describing how these thigs work in
commonly used GUI libraries to get an inspiration. Then pick
up best solution as a candidate to implement in your library
(or come with new one). Of course care has to be taken to keep
everything consistent and fit to the library's interface. I think
we need some sort of wiki pages for that. My longest GUI expirience
comes from Qt and wxWidgets worlds so I can help with describing
how the things are doing there. What do you think?

Regards

Jarrad Waterloo napsal(a):
> I have experience creating GUI's in Win32, MFC, C++ Builder, Java and
.NET!
> I hate to use the J word, Java, but of all of these Java's Swing had the
> best MVC architecture. I wish I tried QT but never got around to it also
in
> part due to its commercial licensing. In general, I agree with Tomas and
> Felipe's comments. However there are a few extra things to keep in mind.
> Swing is easy to use in simple scenarios even with the MVC pattern. By
> default TreeView and TableView used the DefaultTreeModels and the
> DefaultTableModels. As such the only extra code was a single cast from the
> model interface to correct implementation. As such smart defaults are very
> important, as seen by the popularity of Ruby and other modern
technologies.

> One major weakness on the Model side of Swing is that there is very little
> reuse on the interface specification between controls. I believe List and
> and drop down lists had separate models instead of sharing the same model.
> .NET Windows forms, which is just another Win32 wrapper, and while not MVC
> it did not make this one mistake by many but not all of there complex
> controls supporting IList.
>
> My Points:
> 1) The GUI library needs to learn from the strengths and weaknesses of
> earlier implementations.
> 2) The GUI library like any library needs to utilize smart defaults and
> implement all of the boilerplate code so that the thousands of end users
> don't have to keep writing it over and over again.
> 3) The MVC pattern should be used at the lowest level as possible to get

the
> best benefits. It is easier to package Model, View, and Controller
together
> into a thin wrapper than to write a complex control that has all of that
> built in and hidden; latter expecting it to be broken out. Doing the
latter
> is more likely to give you the worse of both worlds rather than the
better.
> There is also no need to code twice, both patterns, into a single control
> and provide the user with a switch to set the mode: bad .NET. Rather the
> contained items version should be defined in terms of the uncontained.
>
> ------------------------------------------------------------------------
>
> As far as layouts please remember:
> "A star is the delicate balance of its fusion forces trying to blow it
apart
> and it gravitational mass trying to keep it together."
> Source unknown and likely not quoted exactly
>
> Most current frameworks, even web based stylesheets, gets this wrong
> resorting to the user have to resort to hard coded sizes and/or websites
> made for particular sized displays. [Gravity] Any control should be able
say
> that it wants to be contracted to its smallest size, as in case of a label
> control, so as to be able to take the least amount of room thus leaving
room
> for other controls. [Expansive] Any control should be able to take all
> available room so as not to waist room and thus getting rid of whitespace
> i.e. all of the remaining room. Further should layouts have any UI costs
as
> it is all logic and parameterization? Let me elaborate, many libraries
have
> layout controls which draw on the screen and soak up resources by creating
> windows that are never displayed because its children are likely taking up
> all available room and its not a graphically construct anyway. I can't
> remember exactly how Swing does this other than to say that layouts are
not

> controls. Anyway, caution is needed as more past examples got it wrong
> rather than right.
>
>
> -----Original Message-----
> From: boost-bounces@... [mailto:boost-bounces@...]
> On Behalf Of Felipe Magno de Almeida
> Sent: Monday, June 22, 2009 8:22 AM
> To: boost@...
> Subject: Re: [boost] [rfc] cppgui
>
> On Mon, Jun 22, 2009 at 9:12 AM, Tomas<pecholt@...> wrote:
>> I also agree that using MVC pattern for more complex controls like tables
>> and trees is a good thing because of its flexibility. On the other hand
>> there are situations where you only need to fill the
>> control with data and present it to the user. In such case using MVC
>> would mean redundant typying. So I would take inspiration from Qt
>> here. For example for a tree widget, there are two options: QTreeView
>> which has MVC interface and then QTreeWidget which inherits from
>> QTreeView, plugs default model and adds some easy interface for adding
>> items etc.
>
> Yes, I think that is a good idea. The win32 has something like this
> with ListBox and ListView too.
>
>> +1 for the named parameter interface which you introduced
>
> Thanks :).
>
>> Another very important aspect is layouting the controls. I think this
>> is so important feature it should be thought over in the beginning (now).
> I
>> have seen your examples and I saw you simply set position
>> and size for each widget. This is nice but it simply doesn't work for
>> real applications from 2 reasons:
>> - it's much simpler to set size constraints for widgets like maximum
>>  size, stretching factor, borders and then let the layout system to
>>  position and size widgets automatically than do the calculations and
>>  repositioning yourself when something changes (like when user resizes
>>  the dialog)
>> - if I understand it correctly your gui can be used to write
>>  multiplatform code. Like one code for windows and linux
>>  version of the app. But on every platform the sizes of individual
>>  widgets are different, the default fonts are different and you
>>  certainly don't want to be bothered with this.
>> For the start something like vertical/horizontal layout would be
> sufficient
>
> Seems appropriate. I'll investigate it. Do you have a syntax you find
> appealing to work with named parameters in this?
>
>> It would be interesting to have an option to be be able to load GUI
>> definition from xml file. It would enable using GUI designers which
>> save time and also make code compile faster. But I understand it's
>> too early for such functionality.
>
> In win32 you can use resource files. I'll soon start support for

QtDesigner
> too.
> I want every tool the platform supports to be usable by the user.
> This way the user can design its Gui with the look&feel most
> appropriate for the platform.
> I might later add some form of DSEL to create GUIs. But that won't be
> for some time.
>
> Regards,

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

On Wed, Jun 24, 2009 at 7:18 PM, Tomas<pecholt@...> wrote:
> I think that couple of important topics were raised here. Things
> like MVC, layout system and surface concept briefly described on
> your website need to be thinked over in more detail because these
> are going to affect how the library will be used.

I'll think over MVC and the layout system and will get back with a
minimal proposal which can be discussed over.
The surface concept I find it useful to deal with drawing in a generic manner.
If there's any flaw, I would like to know it, since I'm already implementing it.

> As Jarred pointed out GUI library needs to learn from others strenghts and
> weaknesses.

Surely.

> I think we should start by describing how these thigs work in
> commonly used GUI libraries to get an inspiration. Then pick
> up best solution as a candidate to implement in your library
> (or come with new one).

I'm keen to come with a new one, which can be implemented over the
other libraries.

> Of course care has to be taken to keep everything
> consistent and fit to the library's interface. I think
> we need some sort of wiki pages for that. My longest GUI expirience comes
> from Qt and wxWidgets worlds so I can help with describing
> how the things are doing there. What do you think?

Sure! I can add you to the project in assembla if you want.

> Regards
>

[snip]

--
Felipe Magno de Almeida
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

On Thu, Jun 25, 2009 at 9:35 AM, Jarrad
Waterloo<jwaterloo@...> wrote:
> Sounds good! Where will this be done: on this general boost list or on
> another boost and GUI specific list?

I don't know. We have a lot of experts watching here. If we make a
mistake it is easier for us to get warned. But we also pollute the
boost mailing list with a library that isn't yet finished nor is a
part of boost, though I do want it to be in the future. What others
think?

> "Felipe Magno de Almeida", what do you
> think about layout and MVC pattern being a first generation part of your GUI
> library?
> Is it a good idea, overly ambitious or blasphemy?

If it is done in a library-based design. I'm all for it. I'll try to
come up with something, and show here next week.


[snip]

Regards,
--
Felipe Magno de Almeida
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

for a layout engine, look at 'eve' from Sean Parent's ASL
stlab.adobe.com. If it is good enough for Photoshop, it is probably
good enough for your app as well.

You can use your own widgets or ones supplied by Adobe. Each widget
just needs to be able to return it's metrics.

Tony



On Thursday, June 25, 2009, Felipe Magno de Almeida
<felipe.m.almeida@...> wrote:

> On Thu, Jun 25, 2009 at 9:35 AM, Jarrad
> Waterloo<jwaterloo@...> wrote:
>> Sounds good! Where will this be done: on this general boost list or on
>> another boost and GUI specific list?
>
> I don't know. We have a lot of experts watching here. If we make a
> mistake it is easier for us to get warned. But we also pollute the
> boost mailing list with a library that isn't yet finished nor is a
> part of boost, though I do want it to be in the future. What others
> think?
>
>> "Felipe Magno de Almeida", what do you
>> think about layout and MVC pattern being a first generation part of your GUI
>> library?
>> Is it a good idea, overly ambitious or blasphemy?
>
> If it is done in a library-based design. I'm all for it. I'll try to
> come up with something, and show here next week.
>
>
> [snip]
>
> Regards,
> --
> Felipe Magno de Almeida
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

On Sun, Jun 28, 2009 at 12:36 PM, Gottlob Frege<gottlobfrege@...> wrote:
> for a layout engine, look at 'eve' from Sean Parent's ASL
> stlab.adobe.com. If it is good enough for Photoshop, it is probably
> good enough for your app as well.

I'm not developing a application, but a library. But I'll take a look.
I remember looking it before starting cppgui. Something didn't attract
me in eve, I don't remember anymore what. But it can be used to gather
experience.
Thanks for remembering eve.

> You can use your own widgets or ones supplied by Adobe. Each widget
> just needs to be able to return it's metrics.
>
> Tony

Regards,
--
Felipe Magno de Almeida
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

On Sun, Jun 28, 2009 at 12:04 PM, Felipe Magno de
Almeida<felipe.m.almeida@...> wrote:
> On Sun, Jun 28, 2009 at 12:36 PM, Gottlob Frege<gottlobfrege@...> wrote:
>> for a layout engine, look at 'eve' from Sean Parent's ASL
>> stlab.adobe.com. If it is good enough for Photoshop, it is probably
>> good enough for your app as well.
>
> I'm not developing a application, but a library.

I understand.  My 'good enough for Photoshop...' was meant more in
general, as in for any apps someone might want to build from your
library.

> But I'll take a look.
> I remember looking it before starting cppgui. Something didn't attract
> me in eve, I don't remember anymore what. But it can be used to gather
> experience.
> Thanks for remembering eve.
>

If you need/want help with eve, let me know.  If nothing else, it
would be good to separate layout from other library concerns, and eve
could be a good example layout engine - particularly since it has some
requirements that other layout engines might not have considered (like
having widgets expose measurements such as text baselines, etc).

Tony
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

On Thu, Jun 25, 2009 at 11:26 AM, Felipe Magno de
Almeida<felipe.m.almeida@...> wrote:
> On Wed, Jun 24, 2009 at 7:18 PM, Tomas<pecholt@...> wrote:
>> I think that couple of important topics were raised here. Things
>> like MVC, layout system and surface concept briefly described on
>> your website need to be thinked over in more detail because these
>> are going to affect how the library will be used.

I've started with a layout system implementation.
It is still more than shy. I've implemented a ruler (still only for qt, going to
port it to win32 very soon).
This can be used like this (layout1 example shows):

my_window::my_window()
{
  layout::horizontal_ruler ruler(wnd_from_this(), 50);

  wnd<> btn = create<controls::button>( _parent = wnd_from_this()
    , _pos = (20, ruler));

  ruler.move(100);

  assert(btn->position().y() == 100);
}

The ruler can be saved and used later. It most not live more than the
window used to create it though. I'm not sure if this is a problem. Is
it?

[snip]

I'm still researching other layout systems, with grids, auto-resize,
proportionality factors, etc.
As I get more implemented I'll be reporting here. I've researched a
listbox/tree with MVC, and it seems straightforward to implement. I'll
do that as soon as I finish the layout system.
I have myself a project that will use these MVC widgets with database
data very soon.

Thanks,
--
Felipe Magno de Almeida
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

Felipe Magno de Almeida wrote:
> On Thu, Jun 25, 2009 at 11:26 AM, Felipe Magno de
> Almeida<felipe.m.almeida@...> wrote:
> > On Wed, Jun 24, 2009 at 7:18 PM, Tomas<pecholt@...> wrote:
> >> I think that couple of important topics were raised here. Things
> >> like MVC, layout system and surface concept briefly described on
> >> your website need to be thinked over in more detail because these
> >> are going to affect how the library will be used.
>
> I've started with a layout system implementation.

One layout mechanism that I've found very easy to use and easy enough to implement is a "spring tab" which I first saw in Borland's Sprint word processor eons ago.  (I realize I'm crossing domains, but I think the idea applies readily.)  The notion of a spring tab is that it exerts equal force on each side to separate things.

Put a spring tab against the left side and a widget on its right and the widget is right aligned.  Reverse the two and the widget is left aligned.  Surround a widget with spring tabs to center it.

If you juxtapose spring tabs, they act as though there is a zero space, invisible widget between them.  Thus, <ST><ST>widget<ST> puts the widget 2/3 of the way across the horizontal extent.

Anyway, the idea is that they are relatively trivial widgets that can be assembled together quickly to get a reasonable arrangement that adapts as a window is resized.  Perhaps that's a tool to include in your library.

_____
Rob Stewart                           robert.stewart@...
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

On Wed, Jul 1, 2009 at 4:41 PM, Stewart, Robert<Robert.Stewart@...> wrote:
> Felipe Magno de Almeida wrote:

[snip]

>> I've started with a layout system implementation.
>
> One layout mechanism that I've found very easy to use and easy enough to implement is a "spring tab" which I first saw in Borland's Sprint word processor eons ago.  (I realize I'm crossing domains, but I think the idea applies readily.)  The notion of a spring tab is that it exerts equal force on each side to separate things.
>
> Put a spring tab against the left side and a widget on its right and the widget is right aligned.  Reverse the two and the widget is left aligned.  Surround a widget with spring tabs to center it.

I liked. I wanted something like this for spacing. I kinda liked the
spring name. But I'm not sure spring tabs as-is are generic enough. I
wanted to create the minimum features required, and as generic (or
primitive) as possible, which could attend almost all people.

> If you juxtapose spring tabs, they act as though there is a zero space, invisible widget between them.  Thus, <ST><ST>widget<ST> puts the widget 2/3 of the way across the horizontal extent.

Why 2/3 if there's four widgets?

> Anyway, the idea is that they are relatively trivial widgets that can be assembled together quickly to get a reasonable arrangement that adapts as a window is resized.  Perhaps that's a tool to include in your library.

Probably. But I wanted something more generic. Maybe the proportion
can be assigned. Also vertical springs are needed. And I'm not sure I
want it to be a widget. It doesn't have most operations a window has.
It only occupies space. And what happens if two widgets are
side-by-side to a spring. Should it press both? Do we link springs
with widgets?
I see a window as having a depth dimension, should springs press work
on a layer, or all depths of a window?

> _____
> Rob Stewart                           robert.stewart@...
> Software Engineer, Core Software      using std::disclaimer;
> Susquehanna International Group, LLP  http://www.sig.com

[snip]

Thanks for your suggestion,
--
Felipe Magno de Almeida
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

Felipe Magno de Almeida

> On Wed, Jul 1, 2009 at 4:41 PM, Stewart,
>
> > One layout mechanism that I've found very easy to use and
> > easy enough to implement is a "spring tab" which I first saw
> > in Borland's Sprint word processor eons ago.  (I realize I'm
> > crossing domains, but I think the idea applies readily.)  The
> > notion of a spring tab is that it exerts equal force on each
> > side to separate things.
>
> > If you juxtapose spring tabs, they act as though there is a
> > zero space, invisible widget between them.  Thus,
> > <ST><ST>widget<ST> puts the widget 2/3 of the way across the
> > horizontal extent.
>
> Why 2/3 if there's four widgets?

I never said a spring tab was a widget.  Call it and treat it how you like.  It merely consumes space, though in a layout mode, were there a GUI editor, they would be visible.

Why 2/3?

   |<oooooooooooo><oooooooooooo><widget><oooooooooooo>|

All spring tabs exert the same space-consuming force, so they divide the available space evenly among them.  Thus, each spring tab consumes (width - widget.width)/N of the space.  (Extend accordingly when there are more widgets in the "line.")

The center of the widget is, thus, 2/3 of the way across the available width.

> > Anyway, the idea is that they are relatively trivial widgets
> > that can be assembled together quickly to get a reasonable
> > arrangement that adapts as a window is resized.  Perhaps
> > that's a tool to include in your library.
>
> Probably. But I wanted something more generic. Maybe the
> proportion can be assigned.

You could do that, but the simplicity of a spring tab is expressed in the formula shown above.  There's no need to indicate the relative strength of any; just add more where needed to effect the needed alignment.

> Also vertical springs are needed.

Undoubtedly.

> And I'm not sure I want it to be a widget. It doesn't have most
> operations a window has. It only occupies space.

I never called it a widget.  As you say, it only occupies space.

> And what happens if two widgets are side-by-side to a spring.
> Should it press both?

Yes:

   |<ooooooooooooooo><widget><widget><ooooooooooooooo>|

The pair is centered by surrounding the pair with spring tabs.

> Do we link springs with widgets?

I don't understand the question, but I'm hoping you understand the idea better now.

> I see a window as having a depth dimension, should springs
> press work on a layer, or all depths of a window?

I don't know, but I guess it would be layer specific.

_____
Rob Stewart                           robert.stewart@...
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

------- Original message -------
> From: Stewart, Robert <Robert.Stewart@...>
> To: boost@...
> Sent: 1.7.'09,  17:09
>
> Felipe Magno de Almeida
>> On Wed, Jul 1, 2009 at 4:41 PM, Stewart,

[snip]

>> > If you juxtapose spring tabs, they act as though there is a
>> > zero space, invisible widget between them.  Thus,
>> > <ST><ST>widget<ST> puts the widget 2/3 of the way across the
>> > horizontal extent.
>>
>> Why 2/3 if there's four widgets?
>
> I never said a spring tab was a widget.

I was confused because you mentioned the behavior as if there were
invisible widgets. So I wrongly assumed they were themselves widgets.

> Call it and treat it how you like.  It merely consumes space, though in a
> layout mode, were there a GUI editor, they would be visible.

I get it now.

> Why 2/3?
>
>   |<oooooooooooo><oooooooooooo><widget><oooooooooooo>|
>
> All spring tabs exert the same space-consuming force, so they divide the
> available space evenly among them.  Thus, each spring tab consumes (width
> - widget.width)/N of the space.  (Extend accordingly when there are more
> widgets in the "line.")
>
> The center of the widget is, thus, 2/3 of the way across the available
> width.

Now I get it. It is 2/3 of the available empty space.

[snip]

>> Probably. But I wanted something more generic. Maybe the
>> proportion can be assigned.
>
> You could do that, but the simplicity of a spring tab is expressed in the
> formula shown above.  There's no need to indicate the relative strength of
> any; just add more where needed to effect the needed alignment.

That excludes any resizing behavior. I'm not sure it would be too simple to
be usable? What if you have a huge space in some platform. The widget might
get too small. I guess it would be okay for automatically resized widgets,
like labels.

[snip]

>> And what happens if two widgets are side-by-side to a spring.
>> Should it press both?
>
> Yes:
>
>   |<ooooooooooooooo><widget><widget><ooooooooooooooo>|

I meant:

|<oooooooo><widget><ooooooo>|
|<oooooooo><widget><ooooooo>|

Where both first springs would actually be the same. I'm not sure this
question of mine is not because of a misunderstand of spring tabs. Are they
two-dimensional?

What do you think of this use-case be added to rulers instead? Where you
could attach it proportionally to the rule size? So you could add exactly
in 2/3 without creating extra objects to represent this rational. If spring
tabs are unidimensional, then they aren't much different from rulers.

>> I see a window as having a depth dimension, should springs
>> press work on a layer, or all depths of a window?
>
> I don't know, but I guess it would be layer specific.

Each time I like more the idea of creating a layer concept. Where all
widgets are in the same layer. Without overlapping. And the layer could
then have some layout, which would manage the widgets size and position to
avoid overlap. I have to grow this idea yet though.

> _____
> Rob Stewart                           robert.stewart@...
> Software Engineer, Core Software      using std::disclaimer;
> Susquehanna International Group, LLP  http://www.sig.com

--
Felipe Magno de Almeida
Consultor C++
Sent from my E71

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams-3]

on Fri Jun 12 2009, Felipe Magno de Almeida <felipe.m.almeida-AT-gmail.com> wrote:

> I've been working the past two years, on and off, unfortunately more
> often not, in a GUI library. But I have gotten back to it. And I
> wanted to make it usable. I believe there are some great things in it.
> This library has a  named parameter interface which is extensible by
> the backend implementation.
>
> I've been working on a QT port, which have been fairly easy so far.
> My intention is to rework some parts of it, finish most widgets and
> the surface concept I've been working on and submit to review to
> boost.
>
> But I wanted some ideas on the controller interface and whatever might
> be useful too in improving the design before submitting.
> The library is in http://www.assembla.com/wiki/show/cppgui
>
> There's a svn and trac there that I use.
>
> The library requires the boost/funcitonal/factory.hpp library reviewed
> and accepted (?), which is not yet part of any boost distribution to
> compile.
>
> You will also need fusion to compile.
>
> I've tested with GCC 4.4.0/4.3.3 with QT and win32 with visual C++
> 9.0.  But should be pretty portable, including qt in visual C++.  The
> gtk code does not compile :(.
>
> There are some very primitive documentation in the site, and some
> examples in the svn.

Have you looked at Adam and Eve from Adobe, and the associated research
papers?  I think these guys have gone a long way down the road to
figuring out how to do things "right" in that domain.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

On Wed, Jul 1, 2009 at 9:08 PM, David Abrahams<dave@...> wrote:
>

[snip]

> Have you looked at Adam and Eve from Adobe,

Yes.

> and the associated research papers?

No. Do you know where can I find it?

>  I think these guys have gone a long way down the road to
> figuring out how to do things "right" in that domain.

They did. But they took a very different approach. With another
language and all.
Though I understand it can help a lot using a more specific language
for GUI, I'm not still convinced it is the best approach. I think a
C++-only, with RAII, exceptions, library can be very easy to use as
well.
It is easier to extend with implementation-specific code too. Though
eve can be used separately.
When I started creating cppgui, I had to create GUIs for Microsoft
Management Console, which had to allow me to create windows from
already constructed windows (with already registered window_procedures
in win32) and resource files. One of the most important goals of
cppgui library is to be usable almost everywhere.
Though I do have plans for creating a DSEL to model windows in the
very far future. It would still be C++. No parsers, nor
highly-dynamic-scripted languages involved.
I just hope there's space for cppgui's goals after adam and eve.

> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com

Regards,
--
Felipe Magno de Almeida
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Iain K. Hanson]

Hi,

On Wed, 2009-07-01 at 23:32 -0300, Felipe Magno de Almeida wrote:

> On Wed, Jul 1, 2009 at 9:08 PM, David Abrahams<dave@...> wrote:
> >
>
> [snip]
>
> > Have you looked at Adam and Eve from Adobe,
>
> Yes.
>
> > and the associated research papers?
>
> No. Do you know where can I find it?

They are linked at Adobe's web site.

>
> >  I think these guys have gone a long way down the road to
> > figuring out how to do things "right" in that domain.
>
> They did. But they took a very different approach. With another
> language and all.
> Though I understand it can help a lot using a more specific language
> for GUI, I'm not still convinced it is the best approach. I think a
> C++-only, with RAII, exceptions, library can be very easy to use as
> well.

[ snip ]

DSL's are a design concept. Embedding one is a implementation choice
that is not required to learn the lessons of Adam and Eve.

> Though I do have plans for creating a DSEL to model windows in the
> very far future. It would still be C++. No parsers, nor
> highly-dynamic-scripted languages involved.
> I just hope there's space for cppgui's goals after adam and eve.

You might want to look at Interviews first ( www.ivtools.org ) . It also
has papers explaining layout and I *believe* use some of these concepts.
It also had hglue and vglue ( h & V = horizontal and vertical ) which is
where spring tabs comes from ( I think ). This work was later expanded
by Mark Linton in FRESCO ( the original if it is still available on the
net was distributed with a project called TargetJr ) - Not the FRESCO
that morphed into Berlin. It extended Interviews idea of Object linking
and Embedding.

Unidraw ( built on top of Interviews ) extended layout concepts greatly
by using QOCA which is a linear equations and inequalities solver that
could make a reasonable attempt at graph layout ( a very non-trivial
problem not normally associated with GUI's ).

hth

/ikh

--
"I disapprove of what you say, but I will defend to the death your right
to say it,"
Evelyn Beatrice Hall who wrote under the pseudonym S.G. Tallentyre in
a biography of Voltaire.

#include <std_disclaimer>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

(sorry for the bad non online reply
Blame my iPhone)

- eve layout engine can be used separately from the scripting language
ie directly in code

- I helped write a DSEL that was as eve like as possible given the
constraints of c++. 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.

I'm not against a springs and struts system, but think about what your
goals really are. 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). Eve is a step in that
direction. We should strive to do as well or better.

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).

Once we have the data description, we can build widgets that can
'advertise' what data types they can display/edit. 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.

This is all doable. I've seen and/or built all the necessary building
blocks to make it so.

Tony



On Wednesday, July 1, 2009, Felipe Magno de Almeida
<felipe.m.almeida@...> wrote:

> On Wed, Jul 1, 2009 at 9:08 PM, David Abrahams<dave@...> wrote:
>>
>
> [snip]
>
>> Have you looked at Adam and Eve from Adobe,
>
> Yes.
>
>> and the associated research papers?
>
> No. Do you know where can I find it?
>
>>  I think these guys have gone a long way down the road to
>> figuring out how to do things "right" in that domain.
>
> They did. But they took a very different approach. With another
> language and all.
> Though I understand it can help a lot using a more specific language
> for GUI, I'm not still convinced it is the best approach. I think a
> C++-only, with RAII, exceptions, library can be very easy to use as
> well.
> It is easier to extend with implementation-specific code too. Though
> eve can be used separately.
> When I started creating cppgui, I had to create GUIs for Microsoft
> Management Console, which had to allow me to create windows from
> already constructed windows (with already registered window_procedures
> in win32) and resource files. One of the most important goals of
> cppgui library is to be usable almost everywhere.
> Though I do have plans for creating a DSEL to model windows in the
> very far future. It would still be C++. No parsers, nor
> highly-dynamic-scripted languages involved.
> I just hope there's space for cppgui's goals after adam and eve.
>
>> --
>> Dave Abrahams
>> BoostPro Computing
>> http://www.boostpro.com
>
> Regards,
> --
> Felipe Magno de Almeida
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

On Thursday, July 2, 2009, Gottlob Frege <gottlobfrege@...> wrote:
> (sorry for the bad non online reply
> Blame my iPhone)
>

!  For example, 'inline' not 'online'. Stupid phone.

Anyhow my main point was really just keep the layout separate from the
rest. Use a data type system and a widget metrics system to describe
the widgets then let the user pick the layout system.

Tony
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

On Thu, Jul 2, 2009 at 2:01 AM, Gottlob Frege<gottlobfrege@...> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

On Fri, Jul 3, 2009 at 4:34 PM, Felipe Magno de
Almeida<felipe.m.almeida@...> wrote:

>> - eve layout engine can be used separately from the scripting language
>> ie directly in code
>
> You mean the Eve engine right?

yep

> 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.
>

It is not you - it is the site - it IS hard to find what you are
looking for.  For now, let's assume that 'layout' will be decoupled
from 'widget library' and maybe you won't have to worry about Eve too
much (yet).

>> 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.
>

Yep, decoupled.  So for any layout system, widgets just need to
describe their measurements.  width, height, etc.  A few things to
learn from Eve and other experiences:
- widgets (or static/free functions related to the widget) should be
able to calculate their sizes based on inputs - ie a text label widget
should be able to return its size for a given text string
- note that X, Y isn't really the widget's problem.  The widget can
calculate its size, but something else will tell it where to be.
- measurements need to include more than just size - it is also
worthwhile to know what the text *baseline* is, and where the ':' is
(if any) in a text label (ie think of a label like "File Name:").
This is so we can align by ':' and by baseline.  In general, widgets
should be able to return a set of 'guidelines' (probably *named*
guidelines like "baseline", etc), that a layout system can choose (or
not) to align widgets to.
Some example measurements can be found at
http://stlab.adobe.com/wiki/index.php/Layout_Terminology#Widget_Extents,
although I notice that there really isn't any descriptions offered
there. :-(
In ASL docs/code, 'measurements' are usually referred to as 'metrics' (IIRC).


>> We need to concentrate on properly describing the data first. A
>> language (c++ or other) that says 'this data is 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?
>

A few thoughts:
- Start at the bottom - with known data types (int, float, string).
- use a capabilities hierarchy.  ie a generic string-editing-widget
can be used as a number-editing-widget, just not the best one.
Similarly it can be a date-editing-widget, etc.
- As a widget-author, all you need to do is to "publish" your widget's
abilities.  ie a single string that describes your widget.
"NumberEditor".  Eventually we build up a standard set of
descriptions, similar to standard 'concepts' in STL, type-traits, etc.
 ie, we can have 3 different widgets that all advertise as
"NumberEditor", and that would mean they all implement the concept
(and interface) of NumberEditor.  I suppose a widget might need to
advertise multiple interfaces that it implements, we would need to
support that as well.

That's it for the widgets.  The hard part is the 'widget selector'
that matches the required widget to the data model.  Currently, the
'widget selector' is usually the coder (via hand-written code, or RC
files, or Eve, etc), or maybe the UI designer if you can teach them
Eve (which I recommend you do!).
But with descriptions, the 'widget selector' can be automated code.
Consider an example:

struct Date  // a poor date struct
{
   int year;
   int month;
   string day;
};

This struct needs to be described to the widget system:
- the struct needs a descriptor string: "Date"  // I'll comment about
the naming later
- the struct needs to be flagged as a 'struct' or 'aggregate' or
'record' - ie that it has members fields
- each item within needs a descriptor "Year", "Month", "Day"
- each item needs to be described by type - int, int, string
- each item optionally gets min/max/default and/or an
array/enumeration of possible values (ie [ "Monday", "Tuesday",...] )

Now, the point is that the 'widget-selector' system can look at this
struct and do:
1. do I have a "Date" widget?  if yes, use that and be done (or if I
have more than one to choose from, check other constraints to decide
the best one)
2. if I don't have a "Date" widget, I need to make a group of widgets,
one for each member of "Date". ie:
   2.1 Do I have a "Year" widget?
   2.2 If not, do I have an "int" widget? (should, it is a base type)
etc

Note that the widget-selector can decide on the proper selector not
only by the descriptor tag "Day" or just type "string", but also be
the optional criteria - if the string has an enumeration ("Monday",
"Tuesday",...) then the choice might be a pop-up list box (or even a
group of radio buttons if the list is short), or it could just default
to an edit box (and force the validation to happen later).

** As for naming - obviously, if I named my struct up there "Date" and
your widget advertises that it can edit a "Date", then we had better
be talking about the same structure.  So maybe it would need
"namespacing" like "MyApp.Date", and then an appropriate widget is
unlikely to be found.  - But think about "Boost.DateTime".  You can
write a widget that understands "Boost.DateTime" (and maybe a few
people will write competing widgets) and my code will use the boost
DateTime library, and we'll understand each other.

The important part is that, for the widgets, it isn't really more work
- it is just communicating (in some agreed upon way) what it is that
the widget is already doing.

>> 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.
>

>From a coding perspective, I agree with you.  Write a generic edit
box, and allow hooks for input-validation.  From there you can get
postal-code specific editing, or whatever you want - we obviously
can't predict all the possible things someone might want to edit.

But whenever we find things recurring, we specialize the widget (even
if that means wrapping the generic edit box and some validation
together).
Obviously we do this all the time - if we didn't specialize widgets,
all UIs would be full of edit boxes, and almost nothing else.  ie no
need for a drop-down list, just type in a edit box; no need for a
file-browser, just type in the file name;  no special number control
with increment/decrement handling; etc etc etc.

>> 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?
>

Yep.  With the widget system being the easiest and first.  Once the
widget system describes itself enough, we can move on to layout and
data model.  (In fact, for a given widget set, layout info and data
info can actually be completely separate.  ie given a widget system
that I can't modify (eg Win32 widget set), I could write complimentary
functions to return metrics and data descriptions, and then hook all
the pieces together independently.)
I guess the real interesting (first?) step is agreeing what the
model/interface for a particular widget is or should be.  ie why write
a number-editing-widget before we can figure out how it should work.
Once we figure out the interface and behaviour, then not only can we
go and write it, but we can also label it "Boost.Number" and then away
we go...

Tony
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

>
>>> We need to concentrate on properly describing the data first. A
>>> language (c++ or other) that says 'this data is 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?
>>
>
> A few thoughts:
> - Start at the bottom - with known data types (int, float, string).
> - use a capabilities hierarchy.  ie a generic string-editing-widget
> can be used as a number-editing-widget, just not the best one.
> Similarly it can be a date-editing-widget, etc.
> - As a widget-author, all you need to do is to "publish" your widget's
> abilities.  ie a single string that describes your widget.
> "NumberEditor".  Eventually we build up a standard set of
> descriptions, similar to standard 'concepts' in STL, type-traits, etc.
>  ie, we can have 3 different widgets that all advertise as
> "NumberEditor", and that would mean they all implement the concept
> (and interface) of NumberEditor.  I suppose a widget might need to
> advertise multiple interfaces that it implements, we would need to
> support that as well.
>
> That's it for the widgets.  The hard part is the 'widget selector'
> that matches the required widget to the data model.  Currently, the
> 'widget selector' is usually the coder (via hand-written code, or RC
> files, or Eve, etc), or maybe the UI designer if you can teach them
> Eve (which I recommend you do!).
> But with descriptions, the 'widget selector' can be automated code.
> Consider an example:
>
> struct Date  // a poor date struct
> {
>   int year;
>   int month;
>   string day;
> };
>
> This struct needs to be described to the widget system:
> - the struct needs a descriptor string: "Date"  // I'll comment about
> the naming later
> - the struct needs to be flagged as a 'struct' or 'aggregate' or
> 'record' - ie that it has members fields
> - each item within needs a descriptor "Year", "Month", "Day"
> - each item needs to be described by type - int, int, string
> - each item optionally gets min/max/default and/or an
> array/enumeration of possible values (ie [ "Monday", "Tuesday",...] )
>
> Now, the point is that the 'widget-selector' system can look at this
> struct and do:
> 1. do I have a "Date" widget?  if yes, use that and be done (or if I
> have more than one to choose from, check other constraints to decide
> the best one)
> 2. if I don't have a "Date" widget, I need to make a group of widgets,
> one for each member of "Date". ie:
>   2.1 Do I have a "Year" widget?
>   2.2 If not, do I have an "int" widget? (should, it is a base type)
> etc
>
> Note that the widget-selector can decide on the proper selector not
> only by the descriptor tag "Day" or just type "string", but also be
> the optional criteria - if the string has an enumeration ("Monday",
> "Tuesday",...) then the choice might be a pop-up list box (or even a
> group of radio buttons if the list is short), or it could just default
> to an edit box (and force the validation to happen later).
>
> ** As for naming - obviously, if I named my struct up there "Date" and
> your widget advertises that it can edit a "Date", then we had better
> be talking about the same structure.  So maybe it would need
> "namespacing" like "MyApp.Date", and then an appropriate widget is
> unlikely to be found.  - But think about "Boost.DateTime".  You can
> write a widget that understands "Boost.DateTime" (and maybe a few
> people will write competing widgets) and my code will use the boost
> DateTime library, and we'll understand each other.
>
> The important part is that, for the widgets, it isn't really more work
> - it is just communicating (in some agreed upon way) what it is that
> the widget is already doing.
>

I forgot to add - much of the structure description work might be the
same as what is done for Boost.Python and Boost.LangBinding.

Tony
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost