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@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Raindog Sent: Saturday, June 13, 2009 1:57 AM To: boost@lists.boost.org 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

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

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@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Felipe Magno de Almeida Sent: Monday, June 15, 2009 9:33 AM To: boost@lists.boost.org Subject: Re: [boost] [rfc] cppgui On Mon, Jun 15, 2009 at 10:00 AM, Jarrad Waterloo<jwaterloo@dynamicquest.com> wrote: 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

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.

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@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Felipe Magno de Almeida Sent: Monday, June 22, 2009 8:22 AM To: boost@lists.boost.org Subject: Re: [boost] [rfc] cppgui On Mon, Jun 22, 2009 at 9:12 AM, Tomas<pecholt@centrum.cz> 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

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

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@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tomas Sent: Wednesday, June 24, 2009 6:18 PM To: boost@lists.boost.org 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): 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@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Felipe Magno de Almeida Sent: Monday, June 22, 2009 8:22 AM To: boost@lists.boost.org Subject: Re: [boost] [rfc] cppgui

On Mon, Jun 22, 2009 at 9:12 AM, Tomas<pecholt@centrum.cz> 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

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@gmail.com> wrote:

On Thu, Jun 25, 2009 at 9:35 AM, Jarrad Waterloo<jwaterloo@dynamicquest.com> 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

On Sun, Jun 28, 2009 at 12:04 PM, Felipe Magno de Almeida<felipe.m.almeida@gmail.com> wrote:

On Sun, Jun 28, 2009 at 12:36 PM, Gottlob Frege<gottlobfrege@gmail.com> 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

On Thu, Jun 25, 2009 at 11:26 AM, Felipe Magno de Almeida<felipe.m.almeida@gmail.com> wrote:

On Wed, Jun 24, 2009 at 7:18 PM, Tomas<pecholt@centrum.cz> 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

On Wed, Jul 1, 2009 at 4:41 PM, Stewart, Robert<Robert.Stewart@sig.com> 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@sig.com Software Engineer, Core Software      using std::disclaimer; Susquehanna International Group, LLP  http://www.sig.com

[snip] Thanks for your suggestion, -- Felipe Magno de Almeida

------- Original message -------

From: Stewart, Robert <Robert.Stewart@sig.com> To: boost@lists.boost.org 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@sig.com 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

On Mon, Jun 15, 2009 at 2:37 PM, Ross Levine<ross.levine@uky.edu> 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

On Mon, Jun 15, 2009 at 11:58 PM, Raindog<raindog@macrohmasheen.com> 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

On Mon, Jun 15, 2009 at 2:50 PM, Sohail Somani<sohail@taggedtype.net> 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

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.

On Wed, Jul 1, 2009 at 9:08 PM, David Abrahams<dave@boostpro.com> 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

(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@gmail.com> wrote:

On Wed, Jul 1, 2009 at 9:08 PM, David Abrahams<dave@boostpro.com> 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

On Thu, Jul 2, 2009 at 2:01 AM, Gottlob Frege<gottlobfrege@gmail.com> 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

...

...

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

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

On Tue, Jul 14, 2009 at 11:50 AM, Ross Levine<ross.levine@uky.edu> wrote:

On Tue, Jul 14, 2009 at 12:12 AM, OvermindDL1 <overminddl1@gmail.com> 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.

On Sat, Jul 11, 2009 at 2:33 PM, Felipe Magno de Almeida<felipe.m.almeida@gmail.com> 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