RE: [boost] Re: GUI Library Proposal for a Proposal
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener
Brian Braatz wrote:
(was RE: [boost] Re: GUI library - something to think about)
Both http://www.torjo.com/win32gui/save_dlg.html
and
http://www.litwindow.com/Library/Documentation/documentation.html
are extremely interesting.
What I see (just after taking a peek at both):
Win32Gui Interesting design No macros Looks tied to Win32Gui
LitWindow Also interesting design Does have macros Also sits on top of WxWidgets, but it looks like the WxWidgets layer could be abstracted out.
I propose that BOTH authors collaborate (on this list) to achieve
the
following:
* Combination of the best of both frameworks * Can sit on WxWidgets OR can have a win32 and xwindows underlying implementation
No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go there, or have anything to do with supporting any other GUI implementation.
[Brian Braatz] PLEASE Re-Read my words. "> > * Combination of the best of both frameworks
* Can sit on WxWidgets OR can have a win32 and xwindows underlying implementation"
If you have a good abstraction - then the ability to "plug in" the underlying implementation (through various mechanisms) means you are not tied to WxWidgets. This also means that conversely, you CAN take advantage of something in WxWidgets (or qt, or win32 or whatever) if you so desire. Boost::gui should not be trying for a kitchen sink approach (like WxWidgets or Qt), but instead would provide a simple and clean abstraction for common functionality. I will always (or frequently) have to write WxWidgets specific code or os specific code, but having a abstraction available from boost would mean most of my code would be portable across framework. I suggest a "first cut" would have a xwindows "plug in" and a win32 plug in, and potentially a WxWidgets and or Qt It is more than practical to have the boost gui abstraction cover the most common concepts. This not only makes it small and easy to implement, but also allows me to write directly to WxWidgets where it makes sense. This is what I would call "having balance" between a standard approach and still allowing for a developer to have the choice to take advantage of specific OS or gui framework feature as they desire. The fact that WxWidgets does not have "modern techniques" is a plus for boost::gui. The fact that WxWidgets is huge and covers a lot of things (and has been around for awhile) is a plus for them. A well designed "gui abstraction layer" would have the following properties: * move the technology of binding forward * Not try to be everything for everybody * allow for the choice of being able to write "boost standard gui code" vs taking advantage of whatever specific thing you are working with These principles, also have the advantage of placing a combination of ltwindows and win32gui in a spot where a combination of the two would in fact meet those properties. AND it would be accomplishable in a short timeframe. And that, is my point :)
It is more than practical to have the boost gui abstraction cover the most common concepts. This not only makes it small and easy to
true. but...
implement, but also allows me to write directly to WxWidgets where it makes sense.
The only problem I see IMO is abstracting events (+ the event arguments). That said, I do plan to abstract away the win32 layer, but this will most likely happen in the distant future - since I have so many other things yet to implement.
A well designed "gui abstraction layer" would have the following properties:
* move the technology of binding forward
would you please be more specific?
* allow for the choice of being able to write "boost standard gui code" vs taking advantage of whatever specific thing you are working with
This IMO will most likely end up being pretty difficult. I'm quite curious how you can provide the right balance between offering some common features and allowing access to the underlying implementation.
These principles, also have the advantage of placing a combination of ltwindows and win32gui in a spot where a combination of the two would in fact meet those properties. AND it would be accomplishable in a short timeframe.
Unfortunately, I don't have the time to investigate. So, are you up for something like this (study both libs and find common ground)? Writing cross-platform GUI is far from easy. Also, you could work with Reece as well. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
If you have a good abstraction - then the ability to "plug in" the underlying implementation (through various mechanisms) means you are not tied to WxWidgets. This also means that conversely, you CAN take advantage of something in WxWidgets (or qt, or win32 or whatever) if you so desire.
Boost::gui should not be trying for a kitchen sink approach (like WxWidgets or Qt), but instead would provide a simple and clean abstraction for common functionality.
I will always (or frequently) have to write WxWidgets specific code or os specific code, but having a abstraction available from boost would mean most of my code would be portable across framework.
Agreed, but I'd like to add a few extra thoughts on how I'd want it to work. When I'm programming my apps, I want to think about actions that I want to expose to the GUI. I want to code in terms of PingServer() instead of OnPingServerButtonPress(), and then have an easy way to programmatically tie a button action (or some other control's action) to triggering my PingServer() functions. These actions are cross platform, but in most platforms, I have to write that tieing code, but its a highly repetitive, pattern based process, so I shouldn't have to (<http://developer.apple.com/documentation/Cocoa/Cocoa.html>see Cocoa docs). I also want to expose the data in my models to the GUI in such a way that I can bind them easily to the GUI. This is next to impossible to do cross platform since every GUI has their own concept of string, etc. So, I end up writing all the code to do that as well, which is also very repetitive and pattern based and should be abstractable (which the Lit Window library seems to do, though I haven't played with it yet). If done properly, the abstraction layer shouldn't require me to think about buttons, comboboxes, layout, etc. I'll do that in the platform specific GUI API that I choose to develop in. Instead, it should connect the platform specific GUI I've developed, to the cross-platform processing and data layer I've developed. It should really just focus on handling binding data between the two and tying user generated GUI actions to my own processing. I will always want to think platform specific code when I am thinking about form layout, new control development, etc, but I shouldn't have to think about it when I am tying my processing and data layers, because unlike the GUI, the processing and data layer do the same thing on each platform. Jared McIntyre
I also want to expose the data in my models to the GUI in such a way that I can bind them easily to the GUI. This is next to impossible to do cross platform since every GUI has their own concept of string, etc. So, I end up writing all the code to do that as well, which is also very repetitive and pattern based and should be abstractable (which the Lit Window library seems to do, though I haven't played with it yet).
I think the save_dlg concept could be cross-platform, but I really don't have the time to implement it (cross-platform, that is). Or have I misunderstood you? http://www.torjo.com/win32gui/save_dlg.html -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
I also want to expose the data in my models to the GUI in such a way that I can bind them easily to the GUI. This is next to impossible to do cross platform since every GUI has their own concept of string, etc. So, I end up writing all the code to do that as well, which is also very repetitive and pattern based and should be abstractable (which the Lit Window library seems to do, though I haven't played with it yet).
I think the save_dlg concept could be cross-platform, but I really don't have the time to implement it (cross-platform, that is).
Or have I misunderstood you?
There are certainly certain components like the save dialog that could be abstracted out in a cross platform manner. You just have to be very careful how you do it and take into account as many platforms as you can, since you would still want to use the native component. Jared McIntyre
There are certainly certain components like the save dialog that could be abstracted out in a cross platform manner. You just have to be very careful how you do it and take into account as many platforms as you can, since you would still want to use the native component.
Yes, you are correct. As I've said before, I'm abstracting events, so that porting win32gui to other platforms will be easier. IMO, events are one of the hardest parts to abstract, when it comes to multiple platforms. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
Hi all, I have only just now gotten back from a conference and am still catching up on this discussion. Jared McIntyre wrote:
When I'm programming my apps, I want to think about actions that I want to expose to the GUI. I want to code in terms of PingServer() instead
I also want to expose the data in my models to the GUI in such a way that I can bind them easily to the GUI. This is next to impossible to
I've added a third article describing pretty much both of your requirements at http://www.litwindow.com/Library/Articles/rapidui_article_3.htm
do cross platform since every GUI has their own concept of string, etc. So, I end up writing all the code to do that as well, which is also very repetitive and pattern based and should be abstractable (which the Lit Window library seems to do, though I haven't played with it yet).
It does precisely that and in a platform and even UI framework independent manner. It provides a layer above the UI framework, so your Lit Window Library would work with Qt, wxWindows, MFC, whatever framework is supported.
If done properly, the abstraction layer shouldn't require me to think about buttons, comboboxes, layout, etc. I'll do that in the platform
The Lit Window Library decouples the layout from the code. Layout is done with a designer and written into an XRC file. Code is written as C++ code and a simple rules language which can be seamlessly integrated into C++. I will be using the boost parser to parse the rules. Binding the layout, code and data is done using names/identifiers.
I will always want to think platform specific code when I am thinking about form layout, new control development, etc, but I shouldn't have to
I want to take this even a step further and research and implement UI patterns and distinguish between different implementations for the same pattern. Example: Two listboxes and four buttons <, <<, >, >> let a user choose m elements out of a list of n elements. Its a very common design pattern. Another implementation is the check list box, a list box with check boxes in front of each item. It implements the same UI design pattern, select m of n, but with completely different visuals. A good UI design tool would let you choose the pattern, "select m of n" and then offer you a variety of possible implementations for various platforms such as big screen (>1024x768 resolution), small screen (640x480) or even a phone. Hajo Lit Window Library: http://www.litwindow.com/library
participants (4)
-
Brian Braatz -
Hajo Kirchhoff -
Jared McIntyre -
John Torjo