Re: [boost] [rfc] cppgui

Subject: Re: [boost] [rfc] cppgui
From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2009-06-22 09:25:48

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_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Felipe Magno de Almeida
Sent: Monday, June 22, 2009 8:22 AM
To: boost_at_[hidden]
Subject: Re: [boost] [rfc] cppgui

On Mon, Jun 22, 2009 at 9:12 AM, Tomas<pecholt_at_[hidden]> 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,
-- 
Felipe Magno de Almeida
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost