On Behalf Of Jesse Booher Sent: Thursday, 4 March 2004 8:05 AM To: boost@lists.boost.org Subject: [boost] Re: GUI library - another one
It is never a bad thing when someone is interested in donating their time to develop software to share with the world, and if there is a community of developers here with the time and motivation to develop a full featured GUI library that rises to the high standards of Boost that would be a wonderful thing. That said a GUI library is a *HUGE* undertaking and other cross platform libraries like wxWidgets have a big head start. Not that this is a race or anything but when it comes to GUI libraries, features nearly always trump form. After all an awkward interface is a developer annoyance, whereas a missing feature can be a show stopper.
There is a certain allure to clean slate designs and there may very well be no existing open source user interface projects that you would consider worthy of your time, but I wondered if you have considered any slightly less ambitious alternatives such as creating a framework employing components from an existing open source project? It seems to me that
the
promise of open source development is not served when wheels (or widgets) need to be reinvented over and over again.
I'd agree with this sentiment. The world is littered with limited cross platform gui libraries. I'd take a decent free one, such as wxWidgets (nee wxWindows), and look at wrapping its elements and leverage that experience. Add new controls/widget later. If it doesn't make boost maybe it could make wxWidgets... Building a RAD tool than generates C++ and resource files including itself in a self hosting way would be an excellent driver. I've never met a gui lib I've liked and I've met quite a few in the street. Ugly critters, they all need a big bath in some sheep drench. Lack of good GUI is a thorn in C++'s side. GUI in C++ is just too hard. Too messy. I want something RADically different. Some new, not just neat C++. The strength of a new approach in C++ could help improve the C++ community. Firstly, I'd like to see it driven by both a user requirement of building the gui and the developer requirement of elegant portable c++. I'd like to see a few things I'd like that are probably a little different to current approaches: 1. The ability to drap and drop complete panels in the builder where they are can be aware of their context and automagically hook up to their context if possible. This means "inheriting" a context where a property can hook up to a provider automagically if there is one that makes sense. E.g. you have a property stock_code, which goes up the structural context of the gui until it finds a match, or it is mapped. This way you can drag and drop components with a minimum of fuss. It is a bit like how events propagate on current windowing systems. This reminds me a little of spirits closure syntax. 1a. An extension to this is addressing properties where the scope of the property is found in the structural hierarchy automagically. Allowing automatic proprogation up and down the hierarchy would be neat. For example, I change my background colour and my parents do too until a parent is reached that doesn't with to. That kind of thing. Also being able to expose data / containers in a similar form so I can just get the stock_code that is relevant to my context by looking up my structural heirarchy... That kind of thing. 1c. Being able to address components and data by structure at run time where that structure may be constructed at run time in a similar way. 2. A natural MVC mechanism where changes flow by default but can have quality of service parameterisation added, like: stop it; all changes, but bundle them up; if there is a queue of changes cause I'm slow, just give me the latest, etc. That kind of thing. QoS is not so important to me but having the design there to support this is. A lot of systems I deal with need this feature as I often have torrents of data. Events would flow down the structural hierarchy similar to point 1. This flow is how gui toolkits already typically work for events. 3. A good sizing mechanism. Either swing or wxWidget sizer like (which often doesn't work out well for small devices) or something that is specifically laid out with pixel accuracy, perhaps with minimum size, with simple ratios of stretchiness. Julian Smart's DialogBlocks is going down this track with wxWidgets. 4. An annoyance of current approaches is that some things are fixed at widget creation time and some things are adaptable properties at run time. I'd like to see them all as run time properties. This could be approached wrapping current kits by buffering the display, deleting and re-creating the widget. Temporary messy implementation for a nice orthogonal concept. 5. Support Metalayout, with windows draggable to tool bars, tabs. Docking at the window edges and the like. wxWidgets frame layout toolkit does this for you. 99. It would be neat to have an abstraction layer where the gui detail was separated from the functional layer via a pipe which could be local or remote to support a fat, thin or chunky client approach. Eventually and approach where the code might migrate from server to client, and vice versa, to support execution where ever it is optimal... I call this the smart client approach :-) These have not much to do with c++, but such an approach in c++ could help c++. If I were to tackle this, I would take wxWindows as my implementation level so I get linux, win32 and mac with native controls and start building a gui composition thing that could generate the c++ and resource files I needed. Concurrently developing the c++ framework. A goal would be to self hosting where you can generate yourself. All the other neat c++ mentioned in this thread still holds true, but I think there needs to be more than just yet another gui toolkit for c++ and the focus needs to be on making a) a nice framework and b) something a little more innovative or added value than just yet another signal / slot or event routing thing. A neat way of simply composing the stuff by taking form of structural context and with a form of structural addressing (I just made that term up) might be the basis of such an innovative approach. A way I like to think of it is a workflow / graph / state machine that is hierarchically composed where each node can address it children and parents and some of the nodes / objects have i/o side affects which might include gui drawing stuff. Does this make sense or is it more of my typically worthless ramble? Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm@sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.