RE: [boost] Re: [gui] The Big Picture [and wxWidgets]
-----Original Message----- On Behalf Of Matt S Trentini Subject: [boost] Re: [gui] The Big Picture [and wxWidgets]
Heya Rene,
That all sounds great; perhaps we should be helping out the wx guys rather than come up with our own library...?
Does anyone else have any good reason why we should create a completely new library assuming that those issues are addressed? (License could be one problem quite aside from the technical issues.)
Keep in mind that starting a GUI library from scratch is going to take *significant* time.
And is wxWindows our "best bet"? It's certainly going to be easier
than
trying to convince the Qt folks to get rid of their preprocessor... ;)
It'd be fantastic if all the issues I brought up with wxWidgets were addressed and we ensured that it worked well with the other boost libraries.
Is there anything anyone else wants or needs that wxWidgets couldn't supply?
[Brian Braatz] I have been watching this whole thread closely, and just wanted to send out a mail in support of the idea of collaboration. I have written many UI Frameworks ON TOP of things like MFC and OWL, and even just writing something ON TOP Of one of those things is a huge task. In one case this was my primary job for several years. It is one of those things where to get something demo-able is easy. But "Completing" it is a different issue entirely. If you look at all the fundamental issues discussed in this thread, i.e. do we have our own point coordination system etc, you can see that there is more here than meets the eye. I will end my thoughts here with the (repeated) suggestion that making a thin layer above the current WxWindows will allow for a Boost.Gui in a short timeframe that has an incredible API interface. :) Brian
On Sat, Jan 01, 2005 at 01:50:28PM -0700, Brian Braatz wrote:
I will end my thoughts here with the (repeated) suggestion that making a thin layer above the current WxWindows will allow for a Boost.Gui in a short timeframe that has an incredible API interface.
Ugh... yet another layer. wxWidgets has enough of those already :-\ Just to understand you, what would be the purpose of such a layer? Marcelo
Brian Braatz wrote:
I will end my thoughts here with the (repeated) suggestion that making a thin layer above the current WxWindows will allow for a Boost.Gui in a short timeframe that has an incredible API interface.
I guess I'm suggesting something a little more exotic than developing a "thin layer". The folks at wxWindows have begun discussions on what the next major revision of their library will look like. They seem to recognise that their API and general design is about due for some serious rework. For example, they are considering relaxing the requirement that it works with old compilers (so templates, exceptions and standard library classes are candidates for native use) and overhauling their event system. These are areas that the boost community obviously has solid experience with. What I'm suggesting (though not very clearly!) is that we work together to make wxWidgets 3.x. Maybe we call it boost-gui. Or boost-wxgui. Whatever. We can leverage off the huge body of existing GUI code that they have while helping to redesign the API's/design to "modernise" the library. It's always hard trying to get two seperate groups of people working toward a common goal but in this case it seems that our interests are heading along similar paths... What do people think? Is it worth starting to open channels to see if such a collaboration is possible? Do we want a collaboration or do we want more stringent control? If we were to collaborate what would be the guidelines (license, decision making, ownership etc)? Do we think the wxWidgets devs are the right ones to be collaborating with? Personally, I think wxWidgets has some flaws but is still an excellent library - IMHO it's currently the best option for C++ GUI development. If we were able to seriously address those flaws with some boost know-how then I'd be in GUI-developer utopia. :) Cheers, Matt PS Another (less tasteful) alternative is that we could fork from their mainline and start hacking wxWidgets into what we believe it should be. I'd only be interested in this option if the collaboration option had been exhausted.
"Matt S Trentini" wrote:
What I'm suggesting (though not very clearly!) is that we work together to make wxWidgets 3.x. Maybe we call it boost-gui. Or boost-wxgui. Whatever.
We can leverage off the huge body of existing GUI code that they have while helping to redesign the API's/design to "modernise" the library.
LitWindow library from Hajo Kirchhoff looks as step in this direction. If sucessfull, maybe its API could be used to wrap other GUI toolkits as well.
It's always hard trying to get two seperate groups of people working toward a common goal but in this case it seems that our interests are heading along similar paths...
What do people think? Is it worth starting to open channels to see if such a collaboration is possible? Do we want a collaboration or do we want more stringent control? If we were to collaborate what would be the guidelines (license, decision making, ownership etc)? Do we think the wxWidgets devs are the right ones to be collaborating with?
I remember people suggested wxWidgets can reuse bind/function/signal, back when it was considered as CBX GUI. What problem is to take/rip these parts from Boost?
PS Another (less tasteful) alternative is that we could fork from their mainline and start hacking wxWidgets into what we believe it should be. I'd only be interested in this option if the collaboration option had been exhausted.
Pavel Vozenilek wrote:
LitWindow library from Hajo Kirchhoff looks as step in this direction. If sucessfull, maybe its API could be used to wrap other GUI toolkits as well.
Yes, I've started looking into Hajo's library, however I've been slightly put-off at the seemingly high usage of macros. However, the concepts are solid. I'll try and look into it some more.
What problem is to take/rip these parts from Boost?
I believe it's possible but I can't recall (or find) the tool that does the dependency analysis. Anyone know it off the top of their head?
Yeah, that list has been around for ages. It's pretty out of date, though it does list many libraries. Cheers, Matt
On Mon, Jan 03, 2005 at 02:14:48AM +1100, Matt S Trentini wrote:
What problem is to take/rip these parts from Boost?
I believe it's possible but I can't recall (or find) the tool that does the dependency analysis. Anyone know it off the top of their head?
Do you mean something like this: $ cat signals.cc #include <boost/signals.hpp> $ c++ -E signals.cc | perl -lne 'print $1 if m{^#\s+\d+\s+".*?/(boost/.*?)"}' | cut -d / -f 1-2 | sort -u boost/any.hpp boost/assert.hpp boost/bind boost/checked_delete.hpp boost/config boost/config.hpp boost/detail boost/enable_shared_from_this.hpp boost/function boost/function.hpp boost/get_pointer.hpp boost/intrusive_ptr.hpp boost/iterator boost/iterator.hpp boost/last_value.hpp boost/mem_fn.hpp boost/mpl boost/next_prior.hpp boost/noncopyable.hpp boost/operators.hpp boost/pending boost/preprocessor boost/ref.hpp boost/scoped_array.hpp boost/scoped_ptr.hpp boost/shared_array.hpp boost/shared_ptr.hpp boost/signal.hpp boost/signals boost/signals.hpp boost/smart_ptr.hpp boost/static_assert.hpp boost/throw_exception.hpp boost/type_traits boost/type_traits.hpp boost/utility boost/utility.hpp boost/utility_fwd.hpp boost/visit_each.hpp boost/weak_ptr.hpp Or did you have something else in mind? Marcelo
"Matt S Trentini" wrote:
What problem is to take/rip these parts from Boost?
I believe it's possible but I can't recall (or find) the tool that does the dependency analysis. Anyone know it off the top of their head?
http://www.boost.org/tools/bcp/bcp.html (I didn;t use, just know about it) /Pavel
At 08:06 PM 1/1/2005, Matt S Trentini wrote:
What I'm suggesting (though not very clearly!) is that we work together to make wxWidgets 3.x. Maybe we call it boost-gui. Or boost-wxgui. Whatever.
We can leverage off the huge body of existing GUI code that they have while helping to redesign the API's/design to "modernise" the library.
It's always hard trying to get two seperate groups of people working toward a common goal but in this case it seems that our interests are heading along similar paths...
What do people think? Is it worth starting to open channels to see if such a collaboration is possible? Do we want a collaboration or do we want more stringent control? If we were to collaborate what would be the guidelines (license, decision making, ownership etc)? Do we think the wxWidgets devs are the right ones to be collaborating with?
Since Boost is an effort of individuals without much formal organization, I don't think Boost and wxWidgets can or should collaborate in the way that two more formal organizations might collaborate, with written agreements, a budget, and that sort of thing. Collaboration can take place, however, if Boosters join the appropriate wxWidgets list, and contribute their expertise in C++ and Boost to the wxWidgets effort, and occasionally report back on the Boost list describing progress or requesting Boost features or fixes to help the wxWidgets effort. If it comes to pass that wxWidgets morphs into modern C++ with Boost compatible licensing, collaboration might increase and the WxWindows folks might decide to submit wxWidgets to Boost. But even if submission to Boost never happens, both the Boost and wxWidgets communities will benefit if wxWidgets is modernized. The above isn't meant to discourage those who would like to build a Boost GUI library from scratch. But that is an exceedingly difficult task, and in the meantime I think we need to stay open to solutions invented elsewhere. --Beman
Heya Beman, Beman Dawes wrote:
Since Boost is an effort of individuals without much formal organization, I don't think Boost and wxWidgets can or should collaborate in the way that two more formal organizations might collaborate, with written agreements, a budget, and that sort of thing.
Agreed. But I'm not suggesting any formal agreements or budget. What I'm trying to do is gauge whether there are others in the boost community that think a collaboration with the wx developers could work. If there is then I want to know what those people want out of the collaboration so we can get started on making it happen.
Collaboration can take place, however, if Boosters join the appropriate wxWidgets list, and contribute their expertise in C++ and Boost to the wxWidgets effort, and occasionally report back on the Boost list describing progress or requesting Boost features or fixes to help the wxWidgets effort.
Again, I agree that this is a likely scenario, but before I invest my time I want to know if there are others that are going to help. What I don't want is for me (and maybe a couple of others) helping the wx guys, Hajo to continue to work on Lit, David to work on his internal library, John to work solely on Win32Generics, Andy to do something else, Reece and Rene to start working on yet another library. Surely it'd be a waste of precious resources. The ideal situation, IMHO, would be for everyone to be working on one library. Obviously some people are going to want to do their own thing (I'm pretty sure John is dead-set on Win32Generics!) but as long as there's a significant number of people prepared to commit to the same solution I'd be keen. If that solution involves basing a GUI library on wxWidgets then I suggest that we as the boost community need to think about what the solution should look like - what do we want to change? Then we need to go to the wx gang and tell them what we want and ask if they're interested in helping... Incidently, I've taken your advice and joined the appropriate wx lists. I'll at least try and notify this list of any significant decisions going on over there! :) And I'll let them know how boost can help them.
If it comes to pass that wxWidgets morphs into modern C++ with Boost compatible licensing, collaboration might increase and the WxWindows folks might decide to submit wxWidgets to Boost. But even if submission to Boost never happens, both the Boost and wxWidgets communities will benefit if wxWidgets is modernized.
True, and that's all good. However I want us to combine our efforts if possible because, in my opinion, a terrible outcome would be for multiple competing libraries to be developed.
The above isn't meant to discourage those who would like to build a Boost GUI library from scratch. But that is an exceedingly difficult task, and in the meantime I think we need to stay open to solutions invented elsewhere.
It's going to be damn hard to develop a GUI library from scratch but agree that people shouldn't be discouraged. Especially in cases like Eugene's (Notus: http://notus.sourceforge.net/) where they're attempting something quite different. But my premise is that the boost GUI - if we decide to work on such a beast - should leverage from existing work as much as possible. Cheers, Matt
At 10:51 AM 1/2/2005, Matt S Trentini wrote: Hi Matt,
Beman Dawes wrote:
Since Boost is an effort of individuals without much formal organization, I don't think Boost and wxWidgets can or should collaborate in the way that two more formal organizations might collaborate, with written agreements, a budget, and that sort of thing.
Agreed. But I'm not suggesting any formal agreements or budget. What I'm trying to do is gauge whether there are others in the boost community that think a collaboration with the wx developers could work.
I think collaborations can work from the Boost side; I think we've proved that with the Spirit, Python, ublas, and similar libraries which have both a Boost component and their own resources and activities. I don't know anything about the WxWiget folks, but gather from what you say that they are at least somewhat interested.
If there is then I want to know what those people want out of the collaboration so we can get started on making it happen.
I think a prior posting already suggested the same things I want; modern C++, including full use of templates, exceptions, and the standard library, and use of Boost components where applicable and sensible. And the Boost license or something like it.
Collaboration can take place, however, if Boosters join the appropriate
wxWidgets list, and contribute their expertise in C++ and Boost to the wxWidgets effort, and occasionally report back on the Boost list describing progress or requesting Boost features or fixes to help the wxWidgets effort.
Again, I agree that this is a likely scenario, but before I invest my time I want to know if there are others that are going to help. What I don't want is for me (and maybe a couple of others) helping the wx guys, Hajo to continue to work on Lit, David to work on his internal library, John to work solely on Win32Generics, Andy to do something else, Reece and Rene to start working on yet another library. Surely it'd be a waste of precious resources. The ideal situation, IMHO, would be for everyone to be working on one library.
Well, I'd hate to see that many efforts running, but I think there is room for more than one. Particularly efforts which try distinctly different approaches.
Incidently, I've taken your advice and joined the appropriate wx lists. I'll at least try and notify this list of any significant decisions going on over there! :) And I'll let them know how boost can help them.
What is the URL for the best list for Boosters to join if they are interested in a next generation WxWigets? Thanks, --Beman
Heya Beman, Beman Dawes wrote:
I think collaborations can work from the Boost side; I think we've proved that with the Spirit, Python, ublas, and similar libraries which have both a Boost component and their own resources and activities. I don't know anything about the WxWiget folks, but gather from what you say that they are at least somewhat interested.
Yes, they do seem mildly interested, though there is some resistance. I'm also hopeful that a collaboration can work from our side. :)
I think a prior posting already suggested the same things I want; modern C++, including full use of templates, exceptions, and the standard library, and use of Boost components where applicable and sensible. And the Boost license or something like it.
Yep, that's more-or-less my wishlist too. Anyone else have anything to add? Threading, memory management of GUI objects and Unicode issues are some other TBD's.
Well, I'd hate to see that many efforts running, but I think there is room for more than one. Particularly efforts which try distinctly different approaches.
Sure. I guess I'm just a little wary because I've started to get involved with a couple of projects that people lost interest on - mostly because there were only a couple of core devs and the effort was just too great. A GUI library is a large undertaking so I'd like to see a few people involved so that it can maintain momentum.
What is the URL for the best list for Boosters to join if they are interested in a next generation WxWigets?
Subscribe here: http://www.wxwidgets.org/maillst2.htm#dev Their mailing rules are here: http://www.wxwidgets.org/mlhowto.htm Thanks, Matt
On Mon, Jan 03, 2005 at 11:28:23AM +1100, Matt S Trentini wrote:
I think a prior posting already suggested the same things I want; modern C++, including full use of templates, exceptions, and the standard library, and use of Boost components where applicable and sensible. And the Boost license or something like it.
Yep, that's more-or-less my wishlist too. Anyone else have anything to add?
I guess it doesn't hurt to say this... Clear-cut separation of the rendering backend from the rest of the library. I have no use for native widgets. Someone can argue that a portable native widgets library *has* to be designed that way, but if I take a look at the existing options, that's not the case. Marcelo
Hi
What I'm suggesting (though not very clearly!) is that we work together to make wxWidgets 3.x. Maybe we call it boost-gui. Or boost-wxgui. Whatever.
We share the same pain about many things in wx, we have listed many of the issues raised in our own wxTNG task list. I am trying to get a kind of common consensus amongst wxCore-Devs how to approach wxTNG. I don't think boost-gui could/should be a layer above wx as it is now, because we cannot provide basic guarantee for exceptions. Thanks, Stefan [wxMac]
participants (6)
-
Beman Dawes -
Brian Braatz -
Marcelo E. Magallon -
Matt S Trentini -
Pavel Vozenilek -
Stefan Csomor