Re: [boost] [rfc] cppgui

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

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_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Tomas
Sent: Wednesday, June 24, 2009 6:18 PM
To: boost_at_[hidden]
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_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,

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