[rfc] cppgui

[Felipe Magno de Almeida]

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.

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

[Raindog]

Felipe Magno de Almeida 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.
>
> Thanks in advance,
>  

Hello,

I'm finding the build instructions on the wiki are not working.

    You must edit the file boost-build.jam in cppgui root directory, or
some of its parents, so that bjam can find boost.build.
    boost-build ../boost_1_39_0/tools/build/v2 ;



First, I am unable to find a file named boost-build.jam in any of the
cppgui files.
Secondly, I am unable to determine which directory is considered cppgui
root as there is a folder 'trunk' which contains docs, etc, and then
there is the projects folder which contains a lot of stuff.


Also, with this instruction:

    My CppGui <http://www.assembla.com/wiki/show/cppgui/CppGui> root
directory contains the Jamfile.v2 with the following content:
    use-project boost : ../boost_1_39_0 ;

Which directory is the root directory, and there is no Jamfile.v2 in
anything but the projects sub folders.

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

[Felipe Magno de Almeida]

On Sat, Jun 13, 2009 at 2:56 AM, Raindog<raindog@...> wrote:
> Felipe Magno de Almeida wrote:
>>

[snip]

> Hello,

Hi Raindog,

> I'm finding the build instructions on the wiki are not working.
>
>   You must edit the file boost-build.jam in cppgui root directory, or some
> of its parents, so that bjam can find boost.build.
>   boost-build ../boost_1_39_0/tools/build/v2 ;

You must create it. I'll fix the documentation.

> First, I am unable to find a file named boost-build.jam in any of the cppgui
> files.
> Secondly, I am unable to determine which directory is considered cppgui root
> as there is a folder 'trunk' which contains docs, etc, and then there is the
> projects folder which contains a lot of stuff.

The root is the trunk directory. The one that contains project-root.jam

> Also, with this instruction:
>
>   My CppGui <http://www.assembla.com/wiki/show/cppgui/CppGui> root directory
> contains the Jamfile.v2 with the following content:
>   use-project boost : ../boost_1_39_0 ;
>
> Which directory is the root directory, and there is no Jamfile.v2 in
> anything but the projects sub folders.

You must create the Jamfile.v2 file too in the cppgui root directory (trunk).

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

[Jarrad Waterloo]

Are you considering using the MVC pattern especially with respect to more
complex controls such as list, trees and grids? Comparing it to Java, I like
the architecture of Swing and SWT over the simple OS wrapper based
architecture of GWT. Even the recent version of QT, I believe is using the
MVC pattern. In a nut shell, data mapping and binding is preferable to
adding data to a particular control and trying to keep the data in sync with
the original source!
 
 
 
-----Original Message-----
From: boost-bounces@... [mailto:boost-bounces@...]
On Behalf Of Raindog
Sent: Saturday, June 13, 2009 1:57 AM
To: boost@...
Subject: Re: [boost] [rfc] cppgui

Felipe Magno de Almeida 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.
>
> Thanks in advance,
>  

Hello,

I'm finding the build instructions on the wiki are not working.

    You must edit the file boost-build.jam in cppgui root directory, or
some of its parents, so that bjam can find boost.build.
    boost-build ../boost_1_39_0/tools/build/v2 ;



First, I am unable to find a file named boost-build.jam in any of the
cppgui files.
Secondly, I am unable to determine which directory is considered cppgui
root as there is a folder 'trunk' which contains docs, etc, and then
there is the projects folder which contains a lot of stuff.


Also, with this instruction:

    My CppGui <http://www.assembla.com/wiki/show/cppgui/CppGui> root
directory contains the Jamfile.v2 with the following content:
    use-project boost : ../boost_1_39_0 ;

Which directory is the root directory, and there is no Jamfile.v2 in
anything but the projects sub folders.

_______________________________________________
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 Mon, Jun 15, 2009 at 10:00 AM, Jarrad
Waterloo<jwaterloo@...> wrote:
> Are you considering using the MVC pattern especially with respect to more
> complex controls such as list, trees and grids? Comparing it to Java, I like
> the architecture of Swing and SWT over the simple OS wrapper based
> architecture of GWT. Even the recent version of QT, I believe is using the
> MVC pattern. In a nut shell, data mapping and binding is preferable to
> adding data to a particular control and trying to keep the data in sync with
> the original source!

I'm not sure I follow your question.
Do you mean with regard to the items contained in these controls?
I'm working with an iterator-like interface. You can add and remove,
the signals from user input return the iterator the item used. You
just need to dereference it to see what it was.
The MVC is implemented in cppgui as responses from signals. The
signals would then be executed in another object, which implements the
controller.

[snip]

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

[Ross Levine]

I'm curious about licensing issues. I believe Qt is available under the
LGPL, however, is the LGPL compatible with the Boost License?

Other than that, I think this is a good idea, provided there's no need for a
MOC or something like that. And, Boost has a signals and slots library which
can be used already!

On Fri, Jun 12, 2009 at 8:14 PM, Felipe Magno de Almeida <
felipe.m.almeida@...> 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.
>
> Thanks in advance,
> --
> 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

[Sohail Somani-2]

Felipe Magno de Almeida 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.

How do you handle exceptions in Qt?

--
Sohail Somani
http://uint32t.blogspot.com

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

[Felipe Magno de Almeida]

On Mon, Jun 15, 2009 at 2:37 PM, Ross Levine<ross.levine@...> wrote:
> I'm curious about licensing issues. I believe Qt is available under the
> LGPL, however, is the LGPL compatible with the Boost License?

I've been worried about that too. I'm not sure how it is solvable.
I believe the cppgui can be Boost License even using Qt. Since I only
distribute the source code. But I'm not sure how it is solved when
compiled.

> Other than that, I think this is a good idea, provided there's no need for a
> MOC or something like that. And, Boost has a signals and slots library which
> can be used already!

The cppgui must be compiled with moc, though that is handled
automatically by the boost.build.
But the client code doesn't. And cppgui uses boost.signals library,
which you can use to connect with your handlers.
This requires QT 4.x though to work. Because of the QT_NO_KEYWORDS
define that's needed to compile cppgui.

[snip]

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

[Felipe Magno de Almeida]

On Mon, Jun 15, 2009 at 2:50 PM, Sohail Somani<sohail@...> wrote:

> Felipe Magno de Almeida 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.
>
> How do you handle exceptions in Qt?

I don't. Cppgui is exception neutral. Do you foresee a problem? I must
be honest, I haven't considered this at all.

> --
> Sohail Somani
> http://uint32t.blogspot.com


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

[Sohail Somani-2]

Felipe Magno de Almeida wrote:

> On Mon, Jun 15, 2009 at 2:50 PM, Sohail Somani<sohail@...> wrote:
>> Felipe Magno de Almeida 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.
>> How do you handle exceptions in Qt?
>
> I don't. Cppgui is exception neutral. Do you foresee a problem? I must
> be honest, I haven't considered this at all.

In general you can't throw exceptions from functions that Qt calls
directly or indirectly (which is basically all your code.) You can get
it 99.34% correct if you override QApplication::notify and catch them in
there. I have not had a problem doing it this way, though that doesn't
mean it is right.

I think the latest versions of Qt can deal with exceptions in the sense
that no resources are leaked. But you can't do stuff like throw in the
middle of a paint operation unless you can restore the painter and undo
the operations until then. I'm sure there is more stuff that won't work
properly with exceptions.

--
Sohail Somani
http://uint32t.blogspot.com

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

[Mathias Gaunard-2]

Felipe Magno de Almeida wrote:

>> How do you handle exceptions in Qt?
>
> I don't. Cppgui is exception neutral. Do you foresee a problem? I must
> be honest, I haven't considered this at all.

Exceptions are a serious matter.

Qt uses exceptions alright (most notably from usage of new), but is not
aware of it and does as if it doesn't.

It is perfectly fine not to use exceptions, but if you do you have to
stick to specific coding standards that are in contradiction with the
recommended practice of using exceptions and RAII.

Qt lives in the no-exceptions make-believe land, which is really the
worst of both worlds.

I am personally quite against a library that would have the same
deficiencies.

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

[Felipe Magno de Almeida]

On Mon, Jun 15, 2009 at 3:59 PM, Mathias
Gaunard<mathias.gaunard@...> wrote:
> Felipe Magno de Almeida wrote:
>
>>> How do you handle exceptions in Qt?
>>
>> I don't. Cppgui is exception neutral. Do you foresee a problem? I must
>> be honest, I haven't considered this at all.
>
> Exceptions are a serious matter.

They sure are. I just never considered that cppgui would have to catch anything.
It is strongly RAII-based, even all windows are handled with specific
smart pointers that explicit the shared ownership of the windows.

> Qt uses exceptions alright (most notably from usage of new), but is not
> aware of it and does as if it doesn't.

I didn't know that.

> It is perfectly fine not to use exceptions, but if you do you have to stick
> to specific coding standards that are in contradiction with the recommended
> practice of using exceptions and RAII.

Sure, I understand. I don't want that too.

> Qt lives in the no-exceptions make-believe land, which is really the worst
> of both worlds.

I agree. I want my programs to be robust in case of failures, and I
want maintenence to be the easiest possible, so exceptions are to me
the obvious answer.

> I am personally quite against a library that would have the same
> deficiencies.

Me too. But I'm a bit lost how to handle this with Qt.
I'll do some research and see what I can actually do to help this situation.
Maybe moving exceptions with boost.exception library might be a
possible solution (?).

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

[Jarrad Waterloo]

Yes the items contained in those controls. Think virtual mode where the
control doesn't store items but requests the data as it is needed. That can
save memory, load faster and be able to handle large number of items.
Further, I was considering when the data changes in the model the view, ie.
the control, is notified and when the control edits data than the model is
notified. The MVC pattern encourages good OOP practices and the creation of
reusable data sources. The following are good references. Java's Swing is a
personal preference as it encourages the creation of reusable classes.

Win32 C++
ListView: LVS_OWNERDATA, LVN_GETDISPINFO

Java's Swing
Trees: TreeModel, TreeModelListener
Tables: TableModel, TableModelListener

C#
ListView: VirtualListSize, VirtualMode, RetrieveVirtualItem
 
 

-----Original Message-----
From: boost-bounces@... [mailto:boost-bounces@...]
On Behalf Of Felipe Magno de Almeida
Sent: Monday, June 15, 2009 9:33 AM
To: boost@...
Subject: Re: [boost] [rfc] cppgui

On Mon, Jun 15, 2009 at 10:00 AM, Jarrad
Waterloo<jwaterloo@...> wrote:
> Are you considering using the MVC pattern especially with respect to more
> complex controls such as list, trees and grids? Comparing it to Java, I
like
> the architecture of Swing and SWT over the simple OS wrapper based
> architecture of GWT. Even the recent version of QT, I believe is using the
> MVC pattern. In a nut shell, data mapping and binding is preferable to
> adding data to a particular control and trying to keep the data in sync
with
> the original source!

I'm not sure I follow your question.
Do you mean with regard to the items contained in these controls?
I'm working with an iterator-like interface. You can add and remove,
the signals from user input return the iterator the item used. You
just need to dereference it to see what it was.
The MVC is implemented in cppgui as responses from signals. The
signals would then be executed in another object, which implements the
controller.

[snip]

--
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 Mon, Jun 15, 2009 at 4:11 PM, Jarrad
Waterloo<jwaterloo@...> wrote:
> Yes the items contained in those controls. Think virtual mode where the
> control doesn't store items but requests the data as it is needed. That can
> save memory, load faster and be able to handle large number of items.
> Further, I was considering when the data changes in the model the view, ie.
> the control, is notified and when the control edits data than the model is
> notified. The MVC pattern encourages good OOP practices and the creation of
> reusable data sources. The following are good references. Java's Swing is a
> personal preference as it encourages the creation of reusable classes.

I see.

>
> Win32 C++
> ListView: LVS_OWNERDATA, LVN_GETDISPINFO

If there's broad native/toolkit support, creating a specific widget
for this wouldn't be a problem.

[snip]

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

[Raindog]

Felipe Magno de Almeida wrote:

> On Mon, Jun 15, 2009 at 2:37 PM, Ross Levine<ross.levine@...> wrote:
> > I'm curious about licensing issues. I believe Qt is available under the
> > LGPL, however, is the LGPL compatible with the Boost License?
>
> I've been worried about that too. I'm not sure how it is solvable.
> I believe the cppgui can be Boost License even using Qt. Since I only
> distribute the source code. But I'm not sure how it is solved when
> compiled.
>
> > Other than that, I think this is a good idea, provided there's no need for a
> > MOC or something like that. And, Boost has a signals and slots library which
> > can be used already!
>
> The cppgui must be compiled with moc, though that is handled
> automatically by the boost.build.
> But the client code doesn't. And cppgui uses boost.signals library,
> which you can use to connect with your handlers.
> This requires QT 4.x though to work. Because of the QT_NO_KEYWORDS
> define that's needed to compile cppgui.
>
> [snip]
>
>  

Also, from what I can gather, the QT driver is optional.

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

[Kai Schroeder-3]

On Sat, Jun 13, 2009 at 2:14 AM, Felipe Magno de Almeida <
felipe.m.almeida@...> 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.


Sounds interesting! Do you know this sandbox project?
https://svn.boost.org/svn/boost/sandbox/guigl/
Perhaps you can cooperate?

Regards,
Kai Schroeder
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Felipe Magno de Almeida]

On Mon, Jun 15, 2009 at 11:58 PM, Raindog<raindog@...> wrote:
> Felipe Magno de Almeida wrote:
>>

[snip]

> Also, from what I can gather, the QT driver is optional.

Yes. I will write a extension interface tutorial, where the
driver/backend can be written by the user. There's also a win32
driver, which doesn't use Qt, and is default on windows.
There's a broken gtk driver too. Which used to work a long time ago.

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

[Tomas Pecholt-2]

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.

+1 for the named parameter interface which you introduced

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

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.

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

[Felipe Magno de Almeida]

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

[Jarrad Waterloo]

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