cxxgui-devel Mailing List for Boosted C++ GUI toolkit
Brought to you by:
davidturner
Menu
▾
▴
cxxgui-devel — Design & development discussion
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: David T. <dkt...@gm...> - 2004-11-02 07:57:36
|
New documentation out on the website (http://cxxgui.sf.net) and in CVS. I still need to write two tutorials, one for users and one for developers, to provide a point-of-entry. However, if you read *all* the documentation that is now on the website you should have a pretty good idea of how the library works :-). Regards David Turner |
|
From: David T. <dkt...@te...> - 2004-10-02 16:04:16
|
I've been working on the Win32 version of a data_view, and I have this to say: the API for the ListView control is extremely badly designed. I knew this from back when I was writing MFC apps, but having to look at it at this level of detail has been an eye-opener. It looks like something a 12-year-old would design. Seriously. It's bad even by Microsoft's standards. Anybody know who was responsible for this abortion? Maybe I'll pay him a visit and kick his ass. Apart from that, it's also totally inflexible. I'm beginning to believe I'll have to write a custom control to get what I want. |
|
From: David T. <dkt...@te...> - 2004-09-30 21:57:24
|
Any ideas for implementing a multicolumned tree-view in Windows? I'm not keen on owner-draw. Perhaps it would be better to have separate tree and list views? Let me know what you think. Regards David Turner |
|
From: David T. <dkt...@te...> - 2004-09-30 21:45:20
|
Hi David
I'm so glad to know that at least one person is interesting in helping
out :-). The fact that the project is mostly inactive is my fault; I've
been rather busy with a new startup recently and haven't had time to
maintain it. But I seem to have more time on my hands now, so hopefully
progress will happen.
[snip]
> Anyway, so I thought my first project would be menus, under win32 for
> now, and this is the usage I've conjured up (I've written the
> interface
> for it and the beginnings of the win32 impl as well):
>
> using namespace gui;
> window win("Test");
> menu mn;
> win.contain(mn);
> mn.append(
> menu("File").append(menu("New").append(menu_item("Picture",boo
> st::bind(on_new_picture,win)))
[snip]
I like the chaining thing too, and what you've designed is more or less
what I had in mind for the menus :-). Please send me the patch so that
I can have a look at it!
There is an implementation detail which has been bothering me (one of
the reasons I haven't approached menus yet). The detail is this: Win32
menus are stupid. They make all sorts of crass assumptions about being
bound to windows in certain places, intercepting keystrokes and so on.
Good for user-interface consistency, but bad design in general. What I
was thinking of doing was containing the menu in a child window of its
own, which may or may not work. What are your thoughts?
> I'll drop it. But I have an implementation question (assuming
> that this
> method is acceptable): Should I go ahead and add some kind of set (or
> maybe even map?) of Callback ids to signals in the window
> implementation? or maybe just a deque?
Have a look at what I did with win32/button.cpp. I think this approach
might be appropriate for menus, too. The
win32/window.cpp:window_dispatch is the main window procedure for all
top level gui::windows. This function checks the window long to see if
it needs to dispatch the message to the window's object. However, it
also checks to see if the message is a WM_COMMAND message; in this case,
the message is instead dispatched to the *originating* window (i.e. the
control). This way buttons get their own click notifications. The same
principle should work for menus, but I haven't looked into it.
(There are far too many assumptions and arbitrary decisions in USER32.
In my opinion.)
>
> Finally, there seems to be rather schizophrenic support for
> std::string
> and std::wstring: it's in the win32 implementation code, but
> not in the
> interface code (e.g. labels on buttons). Is there a reason for this?
Yes. I decided (perhaps wrongly) to use UTF8 exclusively on the
interface side. If you grep for utf8_to_unicode you should see what's
happening.
Regards
David Turner
|
|
From: David T. <dkt...@te...> - 2004-09-30 21:22:03
|
Hello
I've finally managed to get on the ball, and I've made some progress
with cxxgui.
Specifically:
* Boost.build V2 should now be working; this is in preparation for
using BoostBook. I plan to document the library thoroughly so
that everyone can get a feel for how it works and how to use it.
* Added a few things to win32/dataview.cpp so that it will at least
run the test program without throwing a "not implemented"
exception.
* No longer uses DEF files on Win32.
* Various minor fixes, mostly to make it more Boost-like.
What I had to do to get it to compile:
* Install Boost (obviously).
* Set BOOST_BUILD_PATH to the Boost installation directory.
* Put user-config.jam in my home directory, and edit as necessary
(my version attached for those who are interested).
* On Windows: set the HOME environment variable to:
"C:\Documents and Settings\David"
(that INCLUDES the quotes).
* Go to the root of the cxxgui directory and type "bjam --v2".
Please report any problems/suggestions to me.
Help wanted. Very much. Please let me know if you think you can
contribute anything to the project. Even if it's just a suggestion.
I'm getting the feeling that nobody is listening to this list ;-).
Regards
David Turner
|
|
From: David H. <dl...@st...> - 2004-09-12 03:02:27
|
Hi, I just recently discovered this --mostly inactive--project and I
thought I'd like to help breathe a little life into it. Anyway, my skill
set isn't amazing, I know c++ ok, but the only GUI toolkit I really know
is wxWidgets, which offends my sense of rightness with all the heavy
macro use and such. I'm generally a quick learner, and have access to
Windows, Mingw, and soon Linux with gtk and gcc.
Anyway, so I thought my first project would be menus, under win32 for
now, and this is the usage I've conjured up (I've written the interface
for it and the beginnings of the win32 impl as well):
using namespace gui;
window win("Test");
menu mn;
win.contain(mn);
mn.append(
menu("File").append(menu("New").append(menu_item("Picture",boost::bind(on_new_picture,win)))
.append(menu_item("Document",boost::bind(on_new_document,win)))
)
.append(menu_item("Open...",boost::bind(on_open,win)))
.append(menu_item("Save",boost::bind(on_save,win)))
.append(separator())
.append(menu_item("Close",boost::bind(on_close,win)))
.append(menu_item("Exit",boost::bind(on_exit,win)))
)
.append( menu("Edit").append(menu_item("Cut",boost::bind(on_cut,win)))
.append(menu_item("Copy",boost::bind(on_copy,win)))
.append(menu_item("Paste",boost::bind(on_paste,win)))
);
I personally like the append chaining, but if it's generally not liked,
I'll drop it. But I have an implementation question (assuming that this
method is acceptable): Should I go ahead and add some kind of set (or
maybe even map?) of Callback ids to signals in the window
implementation? or maybe just a deque?
Finally, there seems to be rather schizophrenic support for std::string
and std::wstring: it's in the win32 implementation code, but not in the
interface code (e.g. labels on buttons). Is there a reason for this?
David Hall
|
|
From: David T. <dkt...@te...> - 2004-07-25 16:37:54
|
Hi everyone
The data_view widget represents a columned list. It implements an
STL-style interface to an ordered list of rows, through what I call a
"bridged iterator" mechanism. Bridged iterators are RAII wrappers
around iterator objects that use virtual dispatch to connect to a
declared (but not defined) container. These are understandably quite
heavy-weight.
The question is what the "row" interface should look like. I originally
designed it to be a list of items with iterators, much like the list,
but this is a bit too heavy (and hard to implement!) for my liking. I'm
considering reducing it to something like this:
class row
{
datum& operator [](int idx);
const datum& operator [](int idx) const;
datum& operator [](const std::string& column_name);
const datum& operator [](const std::string& column_name) const;
};
(In other words, no iterators). Datum, by the way, is a key/value pair
much like std::map::value_type.
Any thoughts on the subject? Does anyone know of a lighter mechanism
than bridged iterators?
Zhuo Qiang has joined the development team, and I'm going to ask him to
do the Win32 implementation of the data_view (once I've done some
commenting and documentation, which is what I'm doing now). I'm doing
the GTK data_view. Anybody else who'd like to work on other widgets,
please let me know.
Regards
David Turner
|
|
From: David T. <dkt...@te...> - 2004-07-14 17:30:48
|
Hi =D7=BF=C7=BF > i'm very interesting in a boost style gui libarary.i=20 > found two project aimed it, yours cxxgui and the one named=20 > notus.but the cvs has updated nothing since these months,so=20 > is it dead or u just pause a while to something else?=20 I'm still alive, and I have actually been working on cxxgui. Unfortunately I have changed jobs twice in the last three months, so I've been very busy :-). If you would like to get involved in the development, I would be most glad of the help. Please get in touch with me if you'd like to take up development of various pieces. The difference between notus and cxxgui is as follows. Cxxgui is aimed at rather low-level "imperative" interface programming. Its primary aim is to provide a portability layer, with very little extended functionality. The idea is that you should be able to put together a simple interface very quickly. However, it provides hooks to allow vendors to enhance the API with platform-specific functionality. A drawing library will be provided separately through this mechanism. Notus on the other hand is more of a presentation manager, aimed at abstracting the various ways of presenting information. Notus could very well end up using cxxgui as its back-end. As things stand, cxxgui is usable for very simple interfaces (data entry forms, for example). I'm busy working on the list view widget. Currently GTK and the Win32 User API are supported as platforms. Cxxgui uses an automatic layout mechanism based on grids (tables), although I will probably provide a fixed-layout widget at a later stage. Hope you find this useful. Regards David Turner |
|
From: <ben...@id...> - 2004-05-25 10:42:27
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: David T. <dkt...@te...> - 2004-03-12 21:32:39
|
Hi everyone The interfaces for the data_view widget are now checked in. They're quite bulky, and not quite elegant enough for my taste. Now is a good time to peek at the code and criticize the design, before I get too carried away with the implementation... The GTK implementation should be finished sometime on Sunday. The Windows version will follow during the week. Regards David Turner |
|
From: David T. <dkt...@te...> - 2004-03-12 16:11:15
|
On Fri, 2004-03-12 at 16:21, Daniel James wrote: > > OK, I've done it this way, but I'm not sure about it. Every compiler that's > available to me (Visual C++ 6, Borland, mingw, cygwin, Digital Mars) > supports alloca, _alloca or both, so I don't think TEMP_FREE is really > needed. I'm worried about exception safety when using it, it seems like it > could easily lead to leaks. Thanks, Daniel. I don't think exceptions are a worry (as long as those macros are used only as intended ;-)). I should be ready to commit the new list widget sometime tonight. After that I'll get it to run on Cygwin. Regards David Turner |
|
From: David T. <dkt...@te...> - 2004-03-12 16:04:41
|
On Fri, 2004-03-12 at 16:21, Daniel James wrote: > David Turner wrote: > > I think you forgot to "cvs add" the build/ subdirectory? > > It looks like it's in there. Did you use the -d flag for cvs? ie. cvs > update -d. I always forget to do that. Oops, my apologies. Missing .cvsrc *blush*. Regards David Turner |
|
From: Daniel J. <dan...@em...> - 2004-03-12 15:10:41
|
David Turner wrote: > #ifdef MSC_VER > #include <malloc.h> > #define TEMP_ALLOC(size) _alloca(size) > #define TEMP_FREE(ptr) > #elseif defined(CYGWIN) > #define TEMP_ALLOC(size) alloca(size) > #define TEMP_FREE(ptr) > #else > #define TEMP_ALLOC(size) malloc(size) > #define TEMP_FREE(ptr) free(ptr) > #endif > > Can you fix this, please? OK, I've done it this way, but I'm not sure about it. Every compiler that's available to me (Visual C++ 6, Borland, mingw, cygwin, Digital Mars) supports alloca, _alloca or both, so I don't think TEMP_FREE is really needed. I'm worried about exception safety when using it, it seems like it could easily lead to leaks. > CreateThreadEx() is appropriate, I think. > [snip] > I'll look into this. Thanks, I've only ever used boost for multithreading, so I wouldn't know where to start here. Daniel |
|
From: Daniel J. <dan...@em...> - 2004-03-12 15:10:32
|
David Turner wrote: > I think you forgot to "cvs add" the build/ subdirectory? It looks like it's in there. Did you use the -d flag for cvs? ie. cvs update -d. I always forget to do that. Daniel |
|
From: David T. <dkt...@te...> - 2004-03-11 20:19:49
|
Hi Daniel On Wed, 2004-03-10 at 21:39, Daniel James wrote: > Ok, it's checked in. They still need quite a bit of work. There's stuff > in the Jamfile for test which should be defined in the library jamfile. > But it does work for GTK. I think you forgot to "cvs add" the build/ subdirectory? Regards David Turner |
|
From: David T. <dkt...@te...> - 2004-03-11 18:18:56
|
On Wed, 2004-03-10 at 21:39, Daniel James wrote: > Cygwin Problems: > > - The windows code uses _alloca, but cygwin doesn't have this, it has > alloca instead. I guess that the best thing to do is a define a macro > which calls the right one, say CXXGUI_ALLOCA or something similar. I > think this could be defined in win32.hpp, because that's included by all > the windows implementation files, or would you prefer a separate header? > Alternatively we could use boost::scoped_array. Yes, _alloca is MSVC-specific. This should be quite easy to work around, and the win32 header is the place to do it. In fact, I think it should really be done with a pair of macros: #ifdef MSC_VER #include <malloc.h> #define TEMP_ALLOC(size) _alloca(size) #define TEMP_FREE(ptr) #elseif defined(CYGWIN) #define TEMP_ALLOC(size) alloca(size) #define TEMP_FREE(ptr) #else #define TEMP_ALLOC(size) malloc(size) #define TEMP_FREE(ptr) free(ptr) #endif Can you fix this, please? > > - main.cpp calls _beginthreadex(), which isn't on cygwin. I have no idea > what the cygwin equivalent of that is. CreateThreadEx() is appropriate, I think. The reason I don't use a boost::thread here is because boost::thread waits for the thread to commence execution. Threads started in DllMain don't actually begin running until the call to DllMain returns, which means that boost::thread deadlocks if it's used here. _beginthreadex() is comparable to CreateThreadEx, except that it also initializes thread-local storage and mutexes for various standard library variables. I'll look into this. > > Visual C++ 6 problems: > > - SetWindowLongPtr, GetWindowLongPtr and LONG_PTR aren't available, you > need to use SetWindowLong, GetWindowLong and LONG. I guess that we > should either define the missing functions for Visual C++ 6, or provide a > wrapper function which call the appropriate version. I realise that we > want to use the newer functions when they're available. That's a tricky one. On the other hand, I doubt Visual C++ 6 is going to be used much on 64 bit architectures, so it should be okay to #define this problem away. > There are some other problems, but I think I can fix them quite easily, > I'll have a go when I get the chance and post patches to the list, so > that you can say if they're okay. I also checked in a quick change to > util.hpp, so that is uses BOOST_DEDUCED_TYPENAME. It seemed trivial > enough that I didn't need to check first. Indeed :-). > Even if all these problems are fixed, the build system still won't work > on windows, because it doesn't create the dll properly. I think that may > take me a little while to get working. I managed to successfully build > the cygwin version, by making it single threaded, but it crashed when I > clicked on the button to open the new window. I think it died at the > message loop. Hmm. What were the symptoms? In theory, this library should be able to work on single-threaded architectures :-). > I'm also not sure how to link the application so that it calls 'main' > instead of 'winmain' but still acts like a GUI app. I think the GTK folks solved this one by writing a WinMain function that did the globbing and then called main(). Windows certainly has a function to do the globbing in there somewhere, but whether or not it has an API for it is a totally different question. For the moment, I'm not too concerned about this problem, but I agree that it would be nice to make it go away. Regards David Turner |
|
From: David T. <dkt...@te...> - 2004-03-11 18:06:44
|
On Wed, 2004-03-10 at 21:39, Daniel James wrote: > On Tue, 2004-03-09 at 11:46, David Turner wrote: > > I dislike having to work explicitly through the model if the view is to be > > updated. > > I don't think it's practical to use STL algorithms in this way. They > mainly work by assignment, which doesn't map very well to gui > operations. Also, it's hard to see how you would link items in the list > view with items in the model, since iterators are easily invalidated. It > will be very difficult to keep the model and view in sync. Yes; I agree. I've decided that the challenges are such that this is best dealt with In Another Library (tm). Regards David Turner |
|
From: David T. <Da...@fi...> - 2004-03-11 15:47:20
|
Hi
> > The user must provide an adaptor class, called the Model. =20
> Canned models
> > for various STL container types will be provided. The model also
> > supplies metadata, such as column names. The Model derived=20
> from an ABC
> called
> > gui::data_model.
>=20
> What would be the purpose of the metadata?
Column names and types.
I've decided that the MVC plan is just too unwieldy, so here's a simpler
plan:
struct column_type
{
std::string title;
std::string type; // "string" | "bool"
// + some nice constructors
};
class data_view
{
public:
template<typename ColIt> data_view(ColIt col_begin, ColIt col_end);
// + other constructors
// + swap(), operator =3D
int column_count() const;
void insert_column(int order, const column_type& col);
void append_column(const column_type& col);
void erase_column(int order);
iterator insert(const_iterator where);
iterator insert(const_iterator parent, const_iterator where);
iterator append();
iterator append(const_iterator parent);
iterator erase(iterator which);
// + begin, end, rbegin, rend
iterator children_begin(iterator parent);
iterator children_end(iterator parent);
// + const_iterator forms
// + iterator_swap
boost::signal1<iterator>& selection_signal();
};
where data_view::iterator::value_type =3D=3D std::vector<std::string> =
(or an
equivalent).
How about that?
It's much simpler, and if you really want it, an MVC framework can be
built on top. This fits in better with the philosophy of keeping the
GUI library as lean as possible.
I'm going to have to use some or other bridged iterator pattern.
Possibly use iterator_facade and make the implementation functions
virtual. I'm looking into good ways of doing this (if anyone knows of a
good way, please tell me ;-)).
Regards
David Turner
|
|
From: Matt T. <mat...@ho...> - 2004-03-11 14:01:41
|
Heya David,
> This is my preliminary design for the list widget. I'm concerned that
> it might be too complicated. Let me know what you think.
I'm concerned it may be too complicated too! :O
> 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.
What would be the purpose of the metadata?
> 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.
Or a reference preferably... :)
> The view automatically tracks the data.
I'm not convinced automatic tracking is ideal. We used to use it in our
framework at work but found that often only the manipulator of the
data/model
knows best when to trigger an update. For example, typically what happens
is that a number of changes occur to the data. With automatic tracking
this means that every change causes an update which is unnecessary. Manual
tracking would allow you to change the data willy-nilly and then signal the
model to call an update to the view (if required) at the end. Perhaps
manual/auto should be a policy?
> 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
How would the model know to update the view here?
> I dislike having to work explicitly through the model if the view is to
> be updated.
I agree. It's a bit clumsy because the model can never know if the data
has changed.
But a better solution? Not sure yet. I'm going to sleep on it... :)
Will speak soon!
Cheers,
Matt
|
|
From: Matt T. <mat...@ho...> - 2004-03-11 10:21:48
|
Heya David, > 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. My Sourceforge user id is: "matt_trentini". > 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. I'll digest and comment on that soon... :) > 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 :-). Will do! :) > > 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. Yeah, I agree that it seems pretty straightforward so far. But these things have a habit of growing so I'll tidy it up where I can. Cheers, Matt |
|
From: Daniel J. <dan...@em...> - 2004-03-10 20:12:56
|
On Wed, 2004-03-10 at 05:33, David Turner wrote: > Great. I've added you to the developer's list on the project, so you > should be able to commit your changes. Ok, it's checked in. They still need quite a bit of work. There's stuff in the Jamfile for test which should be defined in the library jamfile. But it does work for GTK. > Hmm. It would be nice to have it working... unfortunately I don't have > VC6 anymore. If you could send me an error output, maybe I can fix it. > I suspect that the problem will be the factory. It should be quite easy > to write it in a compatible manner. > > I'll test with cygwin and mingw this end. I've been trying it with cygwin as well. Anyway, here's a list of problems. Most of them I can fix, but I just want to check what the right way is. Cygwin Problems: - The windows code uses _alloca, but cygwin doesn't have this, it has alloca instead. I guess that the best thing to do is a define a macro which calls the right one, say CXXGUI_ALLOCA or something similar. I think this could be defined in win32.hpp, because that's included by all the windows implementation files, or would you prefer a separate header? Alternatively we could use boost::scoped_array. - main.cpp calls _beginthreadex(), which isn't on cygwin. I have no idea what the cygwin equivalent of that is. Visual C++ 6 problems: - SetWindowLongPtr, GetWindowLongPtr and LONG_PTR aren't available, you need to use SetWindowLong, GetWindowLong and LONG. I guess that we should either define the missing functions for Visual C++ 6, or provide a wrapper function which call the appropriate version. I realise that we want to use the newer functions when they're available. There are some other problems, but I think I can fix them quite easily, I'll have a go when I get the chance and post patches to the list, so that you can say if they're okay. I also checked in a quick change to util.hpp, so that is uses BOOST_DEDUCED_TYPENAME. It seemed trivial enough that I didn't need to check first. Even if all these problems are fixed, the build system still won't work on windows, because it doesn't create the dll properly. I think that may take me a little while to get working. I managed to successfully build the cygwin version, by making it single threaded, but it crashed when I clicked on the button to open the new window. I think it died at the message loop. I'm also not sure how to link the application so that it calls 'main' instead of 'winmain' but still acts like a GUI app. Daniel |
|
From: Daniel J. <dan...@em...> - 2004-03-10 20:12:38
|
On Wed, 2004-03-10 at 05:58, David Turner wrote: > 9, Adding new backends, although I think between Win32 and GTK, we've > got 99% of the desktops out there covered. I would like to see things > like PalmOS backends, though. In fact, I have a Tungsten, so I may just > write one myself :-). An OS X backend would be good. If there aren't any OS X developers around, then I might attempt a GNUstep backend. I think they're both based on the same API (openstep?), so it should be easy to port at a later date. I'll have to look into that some more. Daniel |
|
From: Daniel J. <dan...@em...> - 2004-03-10 19:58:47
|
On Tue, 2004-03-09 at 11:46, David Turner wrote:
> 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.
I don't think it's practical to use STL algorithms in this way. They
mainly work by assignment, which doesn't map very well to gui
operations. Also, it's hard to see how you would link items in the list
view with items in the model, since iterators are easily invalidated. It
will be very difficult to keep the model and view in sync.
The interface for the supplied model will probably have to be limited to
what works well with the data_view. Which probably means that the
iterators would need to be const, and modifications would be done by
member functions of the model.
Having said that, you might be able to come with something clever that I
haven't thought of.
Daniel
|
|
From: David T. <Da...@fi...> - 2004-03-10 06:24:27
|
Hello Here is a short to-do list: 1. Win32: windows should be created at the smallest possible size. They should automatically resize when recalculate_layout is called (probably because a widget was added) iff they are not already large enough for their contents. 2. Some "trivial" widgets: a) gui::frame (a visible border with an optional title) b) gui::checkbox (just like a button, except the signal should indicate its state) c) gui::divider (user-draggable horizontal or vertical divider) 3. Some "intermediate" widgets, requiring a little thought a) gui::tabset (tab control - no need for an iterator interface to this one) b) gui::radiobutton and gui::radiogroup (I think these should behave much like they do in HTML, i.e. buttons should have values, and the group signals the current value). 4. Some "difficult" widgets, requiring a lot of thought a) gui::list (I'm working on it) b) gui::menu c) gui::selection (MVC or static?) 5. Lots of documentation to be written, although I'd like to stabilize the APIs before investing a lot of time in that. 6. Decide between owner-document and free widget models. 7. Some things that I think belong in distinct libraries, mostly because they're subject to featuritis: a) A drawing surface (2d, 3d?) b) A multi-line text editor c) bitmap buttons 8. Getting it to build on different platforms. 9, Adding new backends, although I think between Win32 and GTK, we've got 99% of the desktops out there covered. I would like to see things like PalmOS backends, though. In fact, I have a Tungsten, so I may just write one myself :-). Any and all input is appreciated. Regards David Turner |
|
From: David T. <Da...@fi...> - 2004-03-10 05:58:48
|
Hi Daniel > I better tell you what I've been up to then. As I mentioned=20 > 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. Great. I've added you to the developer's list on the project, so you should be able to commit your changes. > 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=20 > bothering with > visual c++ 6, since it looks like many of the boost libraries=20 > are going > to give up on it over the next year or two. Hmm. It would be nice to have it working... unfortunately I don't have VC6 anymore. If you could send me an error output, maybe I can fix it. I suspect that the problem will be the factory. It should be quite easy to write it in a compatible manner. I'll test with cygwin and mingw this end. Regards David Turner |