[rfc] cppgui

[Felipe Magno de Almeida]

On 06/07/2009, Gottlob Frege <gottlobfrege@...> wrote:
> On Fri, Jul 3, 2009 at 4:34 PM, Felipe Magno de
> Almeida<felipe.m.almeida@...> wrote:

Sorry for the long delay,

[snip]

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

Ok.I like the free functions idea. To use ADL and allow non-intrusive
interoperability.
But I didn't like the Eve approach. Creating the assemblage code
for Eve is just too hard. If the widget uses overload to use some
properties. Then using the parameters becomes a hell if/else code.
I think the only manageable way to create a assemblage code is using
some static information as well. To allow some metaprogramming and overload
to help.
I think this means a DSEL would be crucial. What do you think?

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

Ok.

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

Ok. So we must define what must be returned by widgets. These should be
defined for the layout, and the free functions required should mirror
this.
I don't understand why ':' position is required. Couldn't end of the
widget be used instead?

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

I would think a I/O layer for edition would fit here.
Where a string button would be a int button with a I/O controlling
the string editing.

> - As a widget-author, all you need to do is to "publish" your widget's
> abilities.  ie a single string that describes your widget.

string? I think we should do that by type_traits/concept_maps. As much
static information as possible the better.

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

I would expect very few multiple interfaces. I think a adaptor to use
multiple different I/O controls to the widget would make the system
more scalable.

> 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;
> };

I think using fusion here would be great.

> This struct needs to be described to the widget system:
> - the struct needs a descriptor string: "Date"  // I'll comment about
> the naming later

How about a tag?

> - the struct needs to be flagged as a 'struct' or 'aggregate' or
> 'record' - ie that it has members fields

Or everything that isn't a primitive as our terms (std::string
would be a primitve, for example) we could consider a fusion
sequence. Which means it is a aggregate of other aggregates
and primitives. Which would give more information to the widget
selector as the grouping of these primitives.

> - each item within needs a descriptor "Year", "Month", "Day"

I guess a date would have sub-elements year, month and day.
These descriptions could be derived from a date primitive.

> - 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",...] )

I have to think about this type duality, where something could be a
enumeration of strings or numbers.

> 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

Yes, but these should static information IMO.

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

Yes.

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

Or the widget could be reused with a adapter.
But different widgets could be written for the same thing.

> 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 think a adapter layer would be appropriate too.

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

Yes, I think non-intrusiveness is important.

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

I think that some adapter is necessary, so that we don't need to derive
a huge amount of widgets to different types.

> Tony

I do like where this is going.

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

[OvermindDL1]

I have not read this whole thread, but near the beginning someone
mentions that they like the Java Swing style, have any of you looked
at the Juce C++ GUI library?  It is GPL for free projects ($$$ for
non-GPL).  It does not use platform natural widgets, it draws
everything itself, but it is very 'pretty', very fast, and I like many
of the coding styles it uses (listener multiclassing and such,
although I would prefer boost::function pointers though in the more
simple cases).  Not something we would really want to use since it
does not blend into the native OS, but it might be a good design to
look at.

Also, what about binding wxWidgets instead, it is very platform based
so it blends perfectly, it also has the universal backend so it can
draw everything itself (best of both worlds?), the license is
lgpl'ish, and I would absolutely love a more pure C++ interface for it
and have finagled with the idea...
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Ross Levine]

On Tue, Jul 14, 2009 at 12:12 AM, OvermindDL1 <overminddl1@...> wrote:

> It is GPL for free projects ($$$ for non-GPL).


 Then it's not boost-compatible.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[OvermindDL1]

On Tue, Jul 14, 2009 at 11:50 AM, Ross Levine<ross.levine@...> wrote:
> On Tue, Jul 14, 2009 at 12:12 AM, OvermindDL1 <overminddl1@...> wrote:
>
>> It is GPL for free projects ($$$ for non-GPL).
>
>
>  Then it's not boost-compatible.


As stated, we would not want to use it anyway, it does not use native
widgets, just referencing to look at it for its style, it is very
clean, simple, and easy to use, a good basis to design a better C++
GUI framework design off of.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gottlob Frege]

On Tue, Jul 14, 2009 at 6:31 PM, OvermindDL1<overminddl1@...> wrote:

> On Tue, Jul 14, 2009 at 11:50 AM, Ross Levine<ross.levine@...> wrote:
>> On Tue, Jul 14, 2009 at 12:12 AM, OvermindDL1 <overminddl1@...> wrote:
>>
>>> It is GPL for free projects ($$$ for non-GPL).
>>
>>
>>  Then it's not boost-compatible.
>
>
> As stated, we would not want to use it anyway, it does not use native
> widgets, just referencing to look at it for its style, it is very
> clean, simple, and easy to use, a good basis to design a better C++
> GUI framework design off of.

- Learning from other examples is good.
- If done correctly, each user should be able to adapt other
frameworks (custom / OS native / non 'boost-compatible' / etc) into
the generic GUI framework for their projects.


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

[Gottlob Frege]

On Sat, Jul 11, 2009 at 2:33 PM, Felipe Magno de
Almeida<felipe.m.almeida@...> wrote:

>
>>>
>> 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
>
> Ok.I like the free functions idea. To use ADL and allow non-intrusive
> interoperability.
> But I didn't like the Eve approach. Creating the assemblage code
> for Eve is just too hard.

It is a bit to set up.  But once set up, it becomes easy to do UI.
Image a company like Adobe where 20 or even 200 developers (or maybe
one day all Adobe dev) are all using the same GUI system.  One where
you write some eve-script code, and the UI just pops up.  And think of
how much UI there is in each Adobe app!!  The cost of that one
developer to get eve connected to the GUI/widget system is nothing
compared to the savings.

That doesn't necessarily help the 'little guy', and it would be nice
if it was easier, but at least it helps see where it comes from.

The other place it 'comes from' is that is that it is another form of
an 'abstraction penalty'.  Not a speed penalty, but a speed of coding
and understanding penalty.  Highly abstract code (which is all Sean
Parent seems to write :-) often requires extra effort to bring it back
down to earth.  Often it requires a couple of levels of 'narrowing' to
bring it back to concrete items.


> If the widget uses overload to use some
> properties. Then using the parameters becomes a hell if/else code.

I've had a static lookup table/map { property -> boost::function } to
help with this.

> I think the only manageable way to create a assemblage code is using
> some static information as well. To allow some metaprogramming and overload
> to help.

I think static info is good.  I think there will also be cases that
need to be dynamic, but they can always uses switch or if/else to get
to the static info.  More about static vs dynamic later.


> I don't understand why ':' position is required. Couldn't end of the
> widget be used instead?
>

Well, eve (and Adobe UI 'police', I mean UI designers) tend to be
quite fussy, so eve aligns to the ':' (I think).  But forget about
that - alignment guides should be more generic and configurable.  For
the widget, it should just somehow expose what alignments it has and
what type/category/tag each one is (and where they are, of course :-).

>> 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.
>
> I would think a I/O layer for edition would fit here.
> Where a string button would be a int button with a I/O controlling
> the string editing.
>

Adaption:
-------------

Two different sides of the coin here.  Or levels of the problem, maybe.
eg: I need some data.  So I write:

   get_data_input(data);  // which calls
      present_ui_to_user(data); // which calls
          for each datum in data:
              show_widget(datum)

Somewhere in there, show_widget might find exactly the right widget,
or maybe it finds a more generic widget, and then uses an I/O layer to
customize it.
Or maybe it isn't so automatic, and the 'for each datum' isn't a loop but:
             create_custom_number_button(datum1)
                 which calls create_button, then sets some 'adapter' points

<snip>
> Or the widget could be reused with a adapter.
<snip>
> I think a adapter layer would be appropriate too.
<snip>
> Yes, I think non-intrusiveness is important.
<snip>
> I think that some adapter is necessary, so that we don't need to derive
> a huge amount of widgets to different types.
<snip>
>

Yep.  Overall, we make some widgets, describe (somehow) what they do,
and then leave it at that.  From there they can be adapted  to more
specific contexts (by the end coder, but with some common/useful
adaptions living in boost).

Overall, you want the client coder to be able to make adaptions that
fit in seemlessly with the boost:: widgets.
Sometimes the adaptions will be one-time cases (ie pass in a
boost::function for input validation),
other times the adaptions will be reused enough by the client that
they decide to wrap them into separate widget classes.



Static vs Dynamic...
---------------------------

>> - As a widget-author, all you need to do is to "publish" your widget's
>> abilities.  ie a single string that describes your widget.
>
> string? I think we should do that by type_traits/concept_maps. As much
> static information as possible the better.
>
>> Consider an example:
>>
>> struct Date  // a poor date struct
>> {
>>    int year;
>>    int month;
>>    string day;
>> };
>
> I think using fusion here would be great.
>

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

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.

Anyhow, just saying there is a place for the dynamic side.
but that doesn't mean we can't have both:

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



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

Each direction has its uses.  I've used both in a single interface
actually.  (Interestingly, the static (DSEL in fact) case, for me, was
when I could create the entire section of UI (something like a 'tool
palette' in my case) 'automatically'.  ie given the data to be
displayed, the widget selection and layout was automatically
determined.  My goal would be to have all the UI be created this
way...)


Either way, coming at it from different directions can be a great
thing if we can make it work for each direction!  It would be a good
sign of something useful.


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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

On Thu, Jul 16, 2009 at 3:19 AM, Gottlob Frege<gottlobfrege@...> wrote:
> On Sat, Jul 11, 2009 at 2:33 PM, Felipe Magno de
> Almeida<felipe.m.almeida@...> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Domagoj Saric-2]

"Felipe Magno de Almeida" <felipe.m.almeida@...> wrote in message
news:a2b17b60906121714g6d209b47sd77f6c2d1a7aece6@......
> 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.

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

hi, my first post here so an in-advance-apology if i "step on a 'house rule or
two'" ;)


> ...
> But I wanted some ideas on the controller interface and whatever might
> be useful too in improving the design before submitting.


i'm sorry i'm a bit late but...

..after a long, exhaustive, and frustrating, search for a 'proper'
cross-platform gui framework this post was a real sign of hope (finally, a
"booster" doing gui :)...your library is, with the exception of the
windows-only wtl, the only one (i found) using the crtp so an immediate
thumbs up for that one

as with any _c++_ library i expect/want it to be 'properly designed' in both
the 'effectivness' and the 'efficiency' fields (while i found no existing
library that would be even remotly satisfying...the worst 'offender' probably
being wx and qt with macros, 'exception-agnosticism',
"reinventing-the-universe" and binary sizes approaching/breaching the 10MB
mark)...

with that said i have a few wishes/suggestions:
 - make the library more configurable with a policy based design (oh the
buzzwords :)...some of the following points will give examples...

 - do not 'force'/'hard code' the use of boost::signals: i would argue that the
vast majority of guis "out there" are static in nature in the sense that
dynamic/runtime attachment/dettachment of possibly-multiple observers/handlers
is simply not necessary...making boost::signals an overkill for that 'majority
of cases' (if i remember correctly, adding a single boost::signal added ~50kB
to my binary, with all the optimizations available in msvc-9.0, and, as it was
previously mentioned, using the signals method can be overly verbose in cases
where it is not needed)...it would be ideal if it could be made to be a matter
of policy whether to use boost::signals, 'plain' boost::functions,
functors/function pointers as template parameters or, the 'old school',
deriving (static/crtp or dynamic polymorphism)

 - similar thing goes for child/parent "holding policy"...again i'd argue that
'most guis are static in nature' in the sense that their children or parent do
not change dynamically (their number and type, not that they themselves, as in
their internal state, do not change)...so it would be great if children could
be, for example, specified and/or held with mpl/fusion compiletime/static
containers as well as boost/stl runtime/dynamic containers/ranges

 - duplicating os provided functionality should be avoided as much as possible:
   - most (if not all) os gui implementations already use the handle/body idiom
(the C variant of the interface/implementation idiom) coupled with a messaging
system and/or a system of global functions that 'do' something on a handle (the
C variant of virtual functions, e.g. the SetWindowPos() win32 call that
sizes/moves any window, regardless of its 'type'/'class')...that makes the
typical/'traditional' 'c++' gui library approach of duplicating all that by
(always/'as a rule') 'newing' all widgets and accessing them through pointers
and virtual functions ('mostly') unnecessary and ('very') inefficient (if
anything stops/kills a compiler's and linker's optimization oportunities then
those are surely function pointers/virtual functions/collections of those like
signals and heap allocated 'forests of pointers').....with that said, even if a
particual ui requires access to widgets through a base class interface it still
does not imply that the interface must (always) be virtual (because the
underlying os api already made it that way)...in any case it would be nice if
it could, again, be a matter of policy whether to use an abstract
base/interface for a widget/widget set/hierarchy of widgets or not...
   - child/parent lists should not be separately maintained (like in member
containers) when that housekeeping information is already being maintained by
the os (e.g. win32 EnumChildWindows() )
   - thunks (like wtl) and extra 'user memory' for window classes (win32
WNDCLASS.cbWndExtra) can be used to avoid dual memory allocation (one by the
os when it creates the window and the other by the 'framework' for its os
window handle wrapper class)

 - stack allocated/local/temporary windows/widgets should be possible...for
those that must always be, from a design perspective, heap based/non local
intrusive_ptr should be used instead of shared_ptr when shared semantics is
also a must-by-design (making the design both more obvious and light(er)weight)

 - related to the above point is the welcome existence of both
'proper'/full/implementation window classes as well as 'attachable/hwnd
wrapper' classes (like in wtl) that have most of the same interface but
different usage scenarios

 - issues with basic types and structs (like Point and Rect) differing between
different OSs could perhaps be solved by using a wrapper class (for example
class boost::gui::rect : private RECT {..} on win32) which use the native
type(s) for storage and thus a no-op conversion to the native type when calling
os functions while providing member getters and setters for different types
(rect.size<int>(), rect.size<float>, rect.size<native_type> or something along
those lines)...

 - along with native implementations there could also be a universal opengl
implementation...and/but opengl windows/widgets/functionality 'should' also be
available when using a native implementation (for mixing/embedding opengl
windows in/with 'normal' ones)...

 - the library and/or its widgets should be able to work in plugin like
applications where you get a native handle for your (parent) window from the
host application and have to work from/with that...

- a knob/dial widget please ;)

 - (std::)streams, as a horrible horrible example of bloat and inefficency (i
dare anyone to step through a simple declaration/default construction of a
std::xstream object in release mode looking at the asm output), should be
avoided at all cost...if they are used somewhere care should be taken that the
compiler and linker can freely remove std::xstream crt code from the binary if
that particular (gui) library functionality is not used (not using them in
virtual functions and avoiding 'spaghetti' code is usually enough)

 - xml/layout/designer files and dynamic runtime ui construction functionality
is by all means very welcome as a powerfull feature but, as in the previous
remark, it should be implemented so that if one does not use it one also does
not end up with xml&co. code in one's binary

 - it would be welcome if the library's error handling/sensitivity/paranoia
could be configured. for example that the paranoid/'defensive programmers' can
say 'throw on even the least sign of trouble' while other can say
throw/check-for-and-report-an-error only when it is reasonable to expect that
it can actually happen (e.g. getting the string contents of a list box item
with a known valid index and a known valid list box handle into a preallocated
buffer 'cannot'/has no reason to fail even though the functions used to perform
the said action can return an error code...such cases should be 'handled' with
an assert imho)
   - furthermore it would be very welcome if the library could also properly
work with BOOST_NO_EXCEPTIONS (and use error codes for error reporting)...for
example if i'm writing a small utility and just want to bring up a simple
dialog i do not want to be forced to link with the crt, and double my binary
size, only to get exception handling...

 - ...as always..."you do not pay for what you do not use" ;)


--
 "That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
 Aldous Huxley






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