RE: [boost] Re: Re: GUI/GDI template library
Now that the interest for this kind of library has been shown (or not, whatever) could the interested parties please coordinate their efforts using other means than boost mailing list? IIUC this list is for issues with existing code (problems, usage patterns etc) and for submissions that have some code. I am already having problems keeping up with the list as is... Thanks, Drazen ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of E. Gladyshev > Sent: Thursday, August 07, 2003 10:33 AM > To: Boost mailing list > Subject: Re: [boost] Re: Re: GUI/GDI template library [...] > Not exactly, STL has some implmentation specific .cpp > files, is it a template library? > > I repeat the gui library itself will contain headers > only (NO .cpp files). All the cpp files will be > platform dependant that should be considered as > customizations of the pure template library. I really don't think there is any way around this. For those of you concerned with run-time flexibility please remember that your compile-time trait can be used to specify run-time flexible behavior. >The > customizations could be even put in another namespace. boost::gui::detail? Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
--- Bohdan <[EMAIL PROTECTED]> wrote: > > Under 'non-template' I mean that it is not > header-only > library. Generaly term 'template library' is used > for > Pure template-inline library which contains only > headers, > but not cpp. > Ex: spirit is template library, but boost::regex is > not. Not exactly, STL has some implmentation specific .cpp files, is it a template library? I repeat the gui library itself will contain headers only (NO .cpp files). All the cpp files will be platform dependant that should be considered as customizations of the pure template library. The customizations could be even put in another namespace. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
> Now that the interest for this kind of library has been shown (or not, > whatever) could the interested parties please coordinate > their efforts using other means than boost mailing list? > IIUC > this list is for issues with existing code (problems, usage > patterns etc) and for submissions that have some code. I do not think that is true. > I am > already having problems keeping up with the list as is... Set up some kind of filter that dispose of all messages with nonimportant for you topics. Or read it thread based. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
--- Drazen DOTLIC <[EMAIL PROTECTED]> wrote: > Now that the interest for this kind of library has > been shown (or not, > whatever) could the interested parties please > coordinate their efforts > using other means than boost mailing list? IIUC this > list is for issues > with existing code (problems, usage patterns etc) > and for submissions > that have some code. I am already having problems > keeping up with the > list as is... I am sorry for plaguing your mail box. We are going to open a sourceforge project and move this discussion there. Please bear with us for couple more days, please... Basically we just need to agree on the name. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of John Torjo > Sent: Monday, August 04, 2003 2:34 AM > To: Boost mailing list > Subject: Re: [boost] Re: Re: GUI/GDI template library > [...] > > Forgive me for not agreeing with you here ;-) OK, but just this one time :) > > Just think how hard it is - even for a programmer -, when dealing with > lets > say 50-100 types of windows, each window having more than 20-30 controls, > to > have an OVERVIEW. > Not talking about maintaining that code. > Not talking about internationalization. > > So IMHO resource files are THE option. Resource files might be the right solution to some problems, but I think there are a lot of GUI applications that could be written more simply with pure C++ code. A C++ GUI library and a resource system could be complementary. Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
> > 1. i'm 99% sure that plain > > resource language or even XML is much cleaner than c++ bindings- > > templates-operators mess. > > Templates aren't always beautiful, but this library is targeted towards > C++ programmers who should be familiar with them. We've had the STL for > over 5 years now. I don't know how to read "plain resource language" or > XML, but I know how to read C++. That said one of the primary goals of > the library should be to make easy to write and read user code. I think > the code generated using my library is pretty easy to read so far: > > gui_application gui = row("Name: ", edit(&employee::name)); > Forgive me for not agreeing with you here ;-) Just think how hard it is - even for a programmer -, when dealing with lets say 50-100 types of windows, each window having more than 20-30 controls, to have an OVERVIEW. Not talking about maintaining that code. Not talking about internationalization. So IMHO resource files are THE option. Best, John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
>From: "Edward Diener" <[EMAIL PROTECTED]> > Add to this the fact that nearly every C++ programmer already works with a > framework library depending on his implementation of choice. On Windows > alone I know of WTL, ATL, MFC, OWL, VCL, wxWindows, QT, and no doubt others > about which I have no knowledde, each tied very closely to a particular C++ > compiler, IDE, and implementation. I just wanted to point out that several of these, Qt and wxWindows, are cross-platform, so they are not tied to any specific compiler or platform. wxWindows is also Open Source, and I've good experience with the little I've used it. It's very easy to get up and running with it (at least it was on Windows). wxWindows is a wrapper for the native GUI API, while Qt emulates each GUI, using only the low-level graphics API. wxWindows could have been a candidate for Boost, had it not used "stone age" C++ - no templates, exceptions and namespaces (essentially "C with Classes" stage), to cater for a very broad range of compilers, even compilers such as MSVC 4 (!). There are plans to change this, though (http://www.wxwindows.org/roadmap.htm). To quote: --- Start --- Release 2.6.0 (stable) Release date: end of September 2003 Release 3.0.0 (stable) This release should finally mark the end of support for the antiquated compilers without decent support of the modern C++ features such as templates, exceptions and namespaces. wxWindows containers should be replaced with the corresponding standard library classes and std::basic_string<> should be used instead of wxString. --- End --- wxWindows also has 10 years of experience behind it, and an active developer community. Regarding what Dave Abrahams said in another posting about lack of templates (regarding FLTK) meaning that smart pointers can't be used - well, in this case, there are no exceptions, either, so you avoid problems with leaks from exceptions. :) Another note: The library is not a "lowest common denominator" library when it comes to features. There's a core set of components, such as controls, that are portable, but it also allows controls only available on one platform. Thus, it's up to the user how portable, or platform-specific, they want the application to be. Hopefully, this may give some ideas in the debate. Currently, Windows, Mac and Linux is supported, and an emulated version, wxUniversal (like Qt is doing it) is also worked on, e.g. for embedded use (http://www.wxwindows.org/wxuniv.htm). As to the discussion of encoding the layout in code, or using some sort of resource files, I think resource files may be preferrable for a few reasons: - You don't have to recompile the program for every GUI change, when designing the GUI - It's usually easier to make GUI designing programs for resource files, than ones generating source code. Besides, would you like "wizard-code" in your program, a la MFCs or Javas? - The layout and content may be changed at run-time, for example for localisation or customisation. No need for recompiling a client's code; just replace the resource files. Often, someone else but the programmer, a designer, makes the GUI design, and they should not have to be programmers. The same goes for web GUIs - a typical way of doing it is having a designer create the HTML, which is then used as some sort of template in the system, filling it in and transforming it, e.g. using PHP. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
--- Rene Rivera <[EMAIL PROTECTED]> wrote: > [2003-08-01] E. Gladyshev wrote: > > >> Are you aware that the pImpl idiom is used for > many > >> different things > > > >It defenitly has its place but not in modern C++. > > Could you do us the courtesy of indicating who you > are quoting when you post > to the list. It's very hard to follow otherwise. Not > to mention somewhat > rude to the originator of the comments. > Sorry about that. It was Edward Diener. As you can see I am learning :). Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
[2003-08-01] E. Gladyshev wrote: >> Are you aware that the pImpl idiom is used for many >> different things > >It defenitly has its place but not in modern C++. Could you do us the courtesy of indicating who you are quoting when you post to the list. It's very hard to follow otherwise. Not to mention somewhat rude to the originator of the comments. -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
> Are you aware that the pImpl idiom is used for many > different things It defenitly has its place but not in modern C++. > or have > you just decided its not modern C++ at all because > you don't use it for the > things you want to do ? In my opinion modern C++ is more oriented toward program specifications and generic (compile-time) programming. In modern C++, the program functionality can be customized by specifying custom data types and using them in a generic way (library). It is more like a type oriented programming not implementation driven. pImpl doesn't fit there. Don't get me wrong. I use pImpl myself but I try to avoid it as much as possible. I think that any industry standard TEMPLATE library should be designed in terms of modern C++. The compilation time should NOT be considred as an issue. Compilers are getting better, computers faster... boost should be setting programming standards not laging behind trying to accomodate some specific h/w requirements. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Gregory Colvin > Sent: Tuesday, July 29, 2003 4:25 PM > To: Boost mailing list > Subject: Re: [boost] Re: Re: GUI/GDI template library > [...] > > Yes, you might. But I think text and graphics are most often changed, > and > in the case I am describing this must be done with native resources. That makes sense. Surely we could come up with a platform independent method for managing platform specific resources. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
On Tuesday, Jul 29, 2003, at 16:02 America/Denver, Brock Peabody wrote: On Behalf Of Gregory Colvin [...] For this kind of localization loading the localized resources at runtime is essential. Regenerating C++ code and rebuilding the application is not an option. Why would it be necessary to reload anything besides the localized text? That wouldn't be too hard: gui_application app = row(localized_text(name_text_id), edit(&employee::name)); Are you going to change the behavior of the application from one country to another? Yes, you might. But I think text and graphics are most often changed, and in the case I am describing this must be done with native resources. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Gregory Colvin > Sent: Tuesday, July 29, 2003 3:39 PM > To: Boost mailing list > Subject: Re: [boost] Re: Re: GUI/GDI template library [...] > For this kind of localization loading the localized resources at runtime > is essential. Regenerating C++ code and rebuilding the application is > not an option. Why would it be necessary to reload anything besides the localized text? That wouldn't be too hard: gui_application app = row(localized_text(name_text_id), edit(&employee::name)); Are you going to change the behavior of the application from one country to another? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Bohdan > Sent: Tuesday, July 29, 2003 4:10 PM > To: [EMAIL PROTECTED] > Subject: [boost] Re: Re: GUI/GDI template library > [...] > 1. i'm 99% sure that plain > resource language or even XML is much cleaner than c++ bindings- > templates-operators mess. Templates aren't always beautiful, but this library is targeted towards C++ programmers who should be familiar with them. We've had the STL for over 5 years now. I don't know how to read "plain resource language" or XML, but I know how to read C++. That said one of the primary goals of the library should be to make easy to write and read user code. I think the code generated using my library is pretty easy to read so far: gui_application gui = row("Name: ", edit(&employee::name)); >2. Bug correction speed is higher than in case of spirit-like > interface. > I've made few parsers using sprit parsing library and my point > is that it is COOL, but for not-so-big parsers. For larger ones i > still > prefer using parser/lexer generators, even such primitive like > yacc/lex clones. I don't understand how correction speed is higher. You have to change a resource, rebuild it, and then rebuild your program. With a pure C++ solution, you just change and rebuild your program. If you think that Spirit is only useful for small or toy applications you should check out Wave: http://spirit.sourceforge.net/index.php?doc=download/Wave_0_9.html > > > > > > > > > 2. GUI-building code for complicated UI will be poor for compiler > > > perfomance > > > and in most cases code size. > > > As example you can look at spirit c++ parser ... > > > > Writing (for lack of a better term) spirit-like code will make your > > compile times increase if you are not careful. > > Ok i'm not careful, also aren't careful guys who wrote "c++" and "XML" > grammars in spirit. Can you give me example of at least one > complex project which was written "carefully" using spirit or spirit-like > library ? AFAIK "c++" and "XML" grammars in sprit are only parsers > without serious functionality, which will be present in real GUI projects. > In case if you find few ... i'm again 99% sure they were written by > real c++ gurus which can understand, find and fix "higher order c++ bugs" > shortly. > Don't get me wrong, i like spirit library idea, but it is neither > ideal > nor universal ... as everithing in this world :) Anyone writing a "c++" or "XML" grammar is a guru by my definition :) Maybe parsing is tougher on the compiler than what I'm doing. I'll try to get some of my GUI library code extricated from my company's code if you'd like to try it. It doesn't seem to take too long to me. > > > You need to break > > complicated GUI's into less complicated parts that can be compiled > > separately. > >In theory you are right, but in practice ... > If i constantly should change design just to make my project > compile faster , pardon me ... i prefer not to use such library. I think it's essential in managing large projects to keep your source files decomposed into small pieces anyway. I really don't like to see them have much over a screen-full of code. It might also be bad to sacrifice the quality of your design for a marginal decrease in compile time. In my experience so far, it takes a lot longer to compile 50 lines of spirit-like code than 50 line of old style code. However, that 50 lines of spirit-like code might have replaced 500 lines of the original code. > > > > > > > > > 3. It is possible to create some kind of resource-editor which can > > > dramatically increase development time. > > > > This is certainly possible (and has been done many times) but I would > > debate its positive effects on development time. It's the interface > > between the resource world and the 'real' code world that is so > > difficult. As you suggested, you'll have to solve many of the same > > problems involved in serialization - why bother doing that if your > > problem domain doesn't explicitly require that type of solution? > > 1. Mentioned problems should be handled by future boost serialization lib >(if any) anyway. Correct me if i'm wrong, i'm not aware about > serialization > library status . There will surely be one at some point. > > 2. Under "interface between resources and real code" you mean event >handlers ? If so and if i understand you correctly you don't want >to deal with event handlers inside resource files ... >I beleive this is not critical, there are multilple frameworks which >successfully handle this issure or aren't using event handlers in >resource files at all ( i mean resource ids like in MsWin resources). There are a lot of things that it would be difficult to express in any sort of resource file. Notably, anything having to do with behaviour. >
Re: [boost] Re: Re: GUI/GDI template library
On Tuesday, Jul 29, 2003, at 16:24 America/Denver, Bohdan wrote: "Brock Peabody" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Tuesday, Jul 29, 2003, at 12:25 America/Denver, Brock Peabody wrote: ... I don't think custom resource files would be any easier to edit that inline C++ code. I think they would be much less easy to edit and read. It's been a few years, but the last time I was writing a GUI application for an international market the shops in Japan, Korea, and Ireland that we paid to localize the application required platform-native resource files as their starting point. Neither custom resources nor C++ code would have been acceptable. And before that, when I was at XVT, we put a lot of work into supporting native resource files in our portable GUI toolkit. It might not be too hard to make the GUI objects 'serialize' themselves into a native resource file but this would be useless without something to convert a resource file back into C++ code. Something like this could be written on top of a pure C++ solution with the help of a serialization library. Sure, but this can be kind of simple c++ or even c code. Alternatively very important is possibility to load resources in runtime, possibly this can help to solve localization issues. For this kind of localization loading the localized resources at runtime is essential. Regenerating C++ code and rebuilding the application is not an option. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Bronek Kozicki > Sent: Tuesday, July 29, 2003 3:40 AM > To: Boost mailing list > Subject: Re: [boost] Re: Re: GUI/GDI template library > > E. Gladyshev <[EMAIL PROTECTED]> wrote: > > ** Option 1 (compile-time structure) > > typedef std::list< boost::entry > std::string> > listbox; > > I like it. More compile time information > better type safety, and more > space for user "plugins" (ie. template parameters) or future standard > library enhancements (ie. different containers). But I'm (definitely) > not an expert in GUI programming. In fact, I always try to avoid it ;) We need to figure out what can be specified by the compile time structure. A few things I can thing of are: 1) what types of widgets there are 2) how they are positioned 3) how they interact with each other (a check box may enable/disable other widgets) 4) how data is exchanged between the GUI and data structures 5) what is valid input for a given widget. How is invalid input handled 6) what is valid input for a group of widgets (each widget may have valid data but as a group the data is valid) There are just so many things that you might want to specify. We want to be able to do as much as possible at compile time. It is not going to be possible to specify all of this compile time information with a typedef. I really think an expression template type mechanism ala Spirit, like the system I use is the way to go. gui_application my_application = column(line_edit, check_box, row("spinner", spinner)); Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
E. Gladyshev <[EMAIL PROTECTED]> wrote: > GUI objects generate events. What is the best design > for it? Should the events handlers be executed I do not know what is best design, but here's what I think about it: - each "window" (or almost each - may it be widget, edit box, dialog, data view, or main application window, but maybe not static window) may own (but do not have to) its message thread; - if window owns its message thread, it will be able to receive UI events; - it window does not own its message thread, its UI events will be passed to its "parent" window (ie. window containing it; there may be windows, which does not have parents, like main app. window - in such case compilation error is preferred way to signalize that there's no thread able to handle window events); - window events thread must have signal/slots (or callbacks) mechanism, which will be used to call user-defined functions when particular event happens (lack of such mechanism should be compile time error) - user defined functions will be called in context of event thread, and will receive information about A. window (or widged) which fired event B. window, whose event thread accepted event (may be the same as A. or its parent, or its grandpa etc.). This way user will be able to register single function in multiple event threads (signal/slots mechanisms ?) and be sure, that while handling event from one window, the function will be able to accept event from another window (in another thread). On the other hand, window thread will be able to accept and process only single event at once, thus user functions should minimize time necessary to process event. - if user funtion needs to do some more processing for the event it received (thus blocking other events in the window which accepted the event), this function should postpone processing into another thread (created a priori or pooled ?). There should be some conveniant way of creating threads for this purpose. Thread function will be started just when user function leaves, and this separate thread will continue processing. In the same time, window which accepted event will be able to receive another event, and also receive (at some later time) notification about finished event processing. These are just ideas I do not even know how these ideas match to rules of GUI programming (if there are any). B. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
E. Gladyshev <[EMAIL PROTECTED]> wrote: > ** Option 1 (compile-time structure) > typedef std::list< boost::entry std::string> > listbox; I like it. More compile time information > better type safety, and more space for user "plugins" (ie. template parameters) or future standard library enhancements (ie. different containers). But I'm (definitely) not an expert in GUI programming. In fact, I always try to avoid it ;) B. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
> typedef std::list< boost::container boost::gui::fast_signals> > > mylistbox; As for the signals. GUI objects generate events. What is the best design for it? Should the events handlers be executed asynchronously in the context of some internal thread or should they be something like a message pump? In the first case we'd have to make sure that the whole boost::gui is thread safe. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
> I personnally prefer seeing something similar to: > > typedef std::list< boost::entry std::string> > listbox; > I think the basic issue here is this. Should we expose the gui structure as a set of direct STL data types or should we define separate GUI data types that will behave like the STL containers (iterator-like interface). In other words ** Option 1 (compile-time structure) typedef std::list< boost::entry > listbox; typedef std::list< list<...> > listboxN; ** Option 2 (run-time structure) boost::gui::listcontrol mylist; boost::gui::listcontrol childlist; boos::gui::edit lineedit; mylist.push_back(lineedit); mylist.push_back(childlist); The first option is more like a compile time structure and it is more innovative. The second option is a more like a dynamic run-time structre and it is more traditional. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Philippe A. Bouchard > Sent: Monday, July 28, 2003 6:08 AM > To: [EMAIL PROTECTED] > Subject: [boost] Re: Re: GUI/GDI template library > [...] > By the way, this should be defined in the Boost Library: > > template > struct tree > { > list element; > list children; > }; > > You get the idea that you have more control of how you wish to represent > you > container data & individual entries this way. If you want to (and you will) you can go crazy with the static types of the tree nodes. I'd recommend using some sort of mpl type list to define the structure of the tree and callbacks to generate the actual nodes at runtime - you don't necessarily want to have to generate them all at once. I've got a tree built on top of the windows tree control that takes a type tree to specify its layout. You also need to be able to specify recursive tree structures statically since things like paths may be arbitrarily deep. You can access children by specifying the values of its parent nodes (assuming everything is less-than-comparable). All of the access functions can be generated as part of the compile time structure of the tree. If this doesn't make sense I can dig up some sample code. It wasn't pleasant but I got it to work under VC 6. Brock Peabody ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edward Diener Sent: Friday, July 25, 2003 7:17 PM To: [EMAIL PROTECTED] Subject: [boost] Re: Re: GUI/GDI template library > I am not trying to discourage you on working on such a project but the > differences in GUI widgets and GDI functionality between operating systems > is still very great. As a very simple example, realizing that most examples > will be much more complex, items in a listbox may be representable by a > std::vector or even a std::map in one operating system but may have much > more complex requirements in another OS. Besides the issue of mere > representation of the items in the listbox is the way the listbox gets > populated with data and the way one reads data from the listbox back into > your containers. This also varies from OS to OS. Some OS's use messages to > transport data, some use callbacks, some use direct API calls, some use > enumerations, some use asynchronous I/O, and there may be other mechanisms > for all I know. And this is just a listbox, a very simple widget, and yet > you are going to have to write code for this that works for Windows, Linux, > Unix flavors, MacIntosh, VMS, OS2, and whatever else OSs Boost supports. > Think of more complicated widgets which have been developed like tree views, > page controls, list views, track bars, toolbars, edit controls, combo boxes, > and many others. On the GDI side there is the drawing of bitmap images, > geometrical figures, text, regions, vector images, low-level APIs like >OpenGl and DirectX, the list goes on and on. The task is daunting. I don't know about other platforms, but in Windows at least, the API is very ugly and un-C++ like. There is a two phase create/destroy process of objects, the message map system, etc... I think the thing to do is to put all of these existing frameworks out of your mind and think of an idealized GUI interface. I can make MFC, at least, act like I want it to. I would speculate that other libraries are less painful to use and thus easier to adapt than MFC. The most critical step for me in making MFC more friendly was to create wrappers for all the MFC classes so the programmer could use callbacks (via boost::function) rather than message maps. > but it will be very hard for most C++ programmers to give up their > RAD and RAD-like tools for manipulation of a library entirely by code. All of the RAD tools I've used make it easy to quickly create toy applications and impossible to create real world applications. If we can create a library that will reduce the lines of code required to implement a GUI by a significant factor programmers will happily abandon their various outdated GUI tools. > Finally many C++ programmers, being the creators that they are, have already > invented C++ template-based mechanisms to use on top of the GUI/GDI > framework of choice which their compiler and implementation provides. They > may be very loath to use another more general template-based framework no > matter how good it is. I disagree - most programmers were probably overjoyed to stop using CString and CArray and start using the std::string and std::vector<>, for instance. Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
> Your notes made me think of a consistent > reperesentation of state machines in terms of C++ > templates. It should be generic enough to be used in > all sorts of things. > yes. andreas (huber) has something in the pipeline. its a non-trivial thing though (the topic and the library). i suspect it will be excellent for formalizing FSMs but as you say - not a lot of time is spent formalizing state machines during GUI development. > And yes, in the basic widget library, the state > machine issues are to be specifically avoided (if > possible). yeah, i can understand that. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
Hi, On Saturday 26 July 2003 04:27, E. Gladyshev wrote: > It was not exactly my experience. The ammount of code > just to manage the GUI states and data transfer > between GUI structures and internal application > reperesentations is huge. I agree with this, but I don't think that an STL like interface will solve the problem. One reason is that only a small portion of all GUI widgets is container like. AFAICS the main problem with data transfer between GUI and application is that it is bi-directional and that more often than not conversions are required. E.g. numerical values need to be converted to their textual presentation, they might need to be scaled first to adjust for different units (km/m) used for presentation. Currently the conversions are done in different parts of the code depending on the direction, thus begging for inconsistency. I would like to see something like this : !Pseudocode; double app_data; Widget* line_edit; Binding app_data_connection (ref(app_data) >> scale(10.) >> to_string(fixed(), precision(2))); // Move app_data to Widget app_data_connection.write(); // Update app_data from Widget app_data_connection.read(); Regards Thomas -- Thomas Witt [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
[...] > I am not trying to discourage you on working on such > a project but the Thanks for your comments. Don't worry, this is why I posted it here, to hear what other people think. [...] > works for Windows, Linux, > Unix flavors, MacIntosh, VMS, OS2, and whatever else > OSs Boost supports. The library itself won't care/know about all the systems. It would be up to the developer to provide a relevant template parameter that defines the required GUI/GDI traits (the traits for couple of the most popular systems could be included in the first distrubution). [...] > Think of more complicated widgets which have been > developed like tree views, > page controls, list views, track bars, toolbars, > edit controls, combo boxes, > and many others. I don't think that there are too many standard widgets, just about 20. > Add to this the fact that nearly every C++ > programmer already works with a > framework library depending on his implementation of > choice. You could have made the same argument before STL was invented. Nearly every C++ programmer already worked with some sort of private containers/algorithms. > The amount of code which must be > written often becomes negligible by the programmer > after the design time > interfaces have been set up. It was not exactly my experience. The ammount of code just to manage the GUI states and data transfer between GUI structures and internal application reperesentations is huge. > RAD and RAD-like tools for manipulation of a library > entirely by code. Yes, it is not intended for RAD developers like VB forms and such. > > Finally many C++ programmers, being the creators > that they are, have already > invented C++ template-based mechanisms to use on top > of the GUI/GDI >... > programmers adopting your implementation as opposed > to what they have > already been using. > Again, the same argument could have been made about building STL. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost