cxxgui-devel Mailing List for Boosted C++ GUI toolkit (Page 2)
Brought to you by:
davidturner
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
(20) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
|
---|
From: Daniel J. <dan...@em...> - 2004-03-09 17:37:43
|
On Tue, 2004-03-09 at 15:44, David Turner wrote: > Please send a mail to the list when you start working on something; > there's nothing worse than a project where nobody knows what anyone else > is doing :-). I better tell you what I've been up to then. As I mentioned on the boost list, I've been writing some jamfiles for boost build. I've got it working on linux with GTK, and almost working on windows. At the moment the code doesn't work on cygwin or visual c++ 6. Which probably isn't that surprising. I don't know if its worth bothering with visual c++ 6, since it looks like many of the boost libraries are going to give up on it over the next year or two. My sourceforge id is danieljames. Daniel |
From: David T. <Da...@fi...> - 2004-03-09 16:09:59
|
Hi Matt > I'd like to offer a hand in helping you with you C++ GUI=20 > library. I've been > lurking in the Boost newsgroups for a long time now and have=20 > been debating > when to step in and offer help. Seeing as I'm a GUI developer at work > (using an in-house GUI library wrapped around Win32 calls) I=20 > figure I may > actually be of some use for your baby... :) Thank you for your offer :-). I think the first think to do is join the mailing list (http://lists.sourceforge.net/lists/listinfo/cxxgui-devel). Then post your sourceforge user id to the list, and I'll add you as a developer, which should automatically give you commit privileges. At the moment I'm puzzling over the design of the list/tree widget. I'll forward to you an earlier post I made outlining my current plan. I suspect that the menu widget will be of a similar level of complexity, so the design of that needs to be kicked around too. However, if you want to get started writing actual widgets, there's plenty to do there, too. There is also scope to improve the level of detail provided by the existing widgets, although I definitely don't want to throw in everything and the kitchen sink. Please send a mail to the list when you start working on something; there's nothing worse than a project where nobody knows what anyone else is doing :-). > I've had a quick scan of the code and it doesn't look too difficult to > follow, though more comments would have helped! ;) Ah, yes :-). If you see anything particularly confusing, please either comment it or tell me about it. I think it's all pretty straightforward, though. Regards David Turner |
From: David T. <dkt...@te...> - 2004-03-09 12:03:18
|
Hi, everyone This is my preliminary design for the list widget. I'm concerned that it might be too complicated. Let me know what you think. The data ("Data") is stored in an unspecified container. The user must provide an adaptor class, called the Model. Canned models for various STL container types will be provided. The model also supplies metadata, such as column names. The Model derived from an ABC called gui::data_model. The list widget itself is a view, called gui::data_view. The user specifies the model to the view by passing it a pointer to a data_model. The view automatically tracks the data. One problem I have with this design is the following: std::vector<std::string> my_data; gui::linear_model<std::vector<std::string> > my_model; gui::data_view view(my_model); std::sort(my_data.begin(), my_data.end()); // view not updated my_model.range_reordered(my_data.begin(), my_data.end()); // view updated view.update(); // view updated std::sort(my_model.begin(), my_model.end()); // view updated I dislike having to work explicitly through the model if the view is to be updated. Regards David Turner |
From: David T. <dkt...@te...> - 2004-03-07 15:00:22
|
Hello everybody. I've just checked-in a changeset that introduces free widgets. This breaks the GTK build for the moment; I'm going to reboot shortly and fix that. If anybody would like commit privileges, just send me your SourceForge username. I'm quite relaxed about who commits what, but I reserve the right to undo any changes :-). We'll see how things go. One thing I'm not very experienced with is ensuring portability. I develop on Windows XP with VC++.NET and Debian Sid with g++ 3. So if the build doesn't work on other platforms, I won't be particularly surprised. Please help me out with this! A little explanation about how the code works (since this afternoon's check-in): the public headers are in include/gui. The implementations are in src/win32 and src/gtk. There is a shared implementation file, src/multithread.cpp, for multi-threaded platforms. Each platform has a shared header, for example, src/gtk/gtk.hpp. Widgets are created via a factory. The factory template is declared in include/gui/utils.hpp. The actual factory is a typedef in the platform's shared header. Widget implementations inherit from the implements_widget template class, which provides registration, this_ptr access, and other niceties. The "real" widget is a class derived from widget_base. However, the user manipulates the real widget via a wrapper class. For example, the "real" window implementation, derived from window_base, is manipulated by the "window" class, which contains a boost::shared_ptr<window_base>. I'm interested in suggestions for the public interfaces for list widgets. They ought to be reasonably compatible with standard containers. I think they should simply contain strings. At this stage, I'm not looking at writing a serialization/unserialization library for widgets; nor am I looking at implementing a graphics library. But don't let that stop you from writing your own, if you are so inclined :-). As I mentioned on the Boost list, I want to allow extensibility on a per-platform basis. The idea is that another library could #include the semi-private platform shared header, and introduce a new widget type into the factory. The platform shared header contains an "implementation" ABC that should be sufficient to extend the library in any way you can think of. I also don't want to get into developing syntactic sugar for creating complex windows all in one expression. That can be done later. I'm trying to keep one eye on eventually supporting run-time selection of the backend. Regards David Turner P.S. I would be very interested to see a text-mode backend for the library, if anyone is interesting in creating one :-). |