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
[boost] Re: Re: GUI/GDI template library
"E. Gladyshev" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > --- Bohdan <[EMAIL PROTECTED]> wrote: > > > 2. Finally your lib may become non-template ( i mean > > cpp files) ... > > If it becomes not-template, I'll stop working on it > :). cpp files are allowed for the layer 1 code and > compilation-time optimization wrappers only, that's > it! Both has little to do with the library itself. 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. > > > What about simple boost::gui ? > > I would like to have an unique name without the boost > prefix. Under boost:: i mean namespace and by gui i mean nested namespace for your library. But in documentation it should be called Boost GUI ( BGUI ). regards, bohdan ___ 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
[boost] Re: Re: GUI/GDI template library
E. Gladyshev wrote:
> --- Rainer Deyke <[EMAIL PROTECTED]> wrote:
>> For a GUI library to be useful to me, it would need
>> to support custom
>> physical GUI layers. I would then write my own
> [...]
>> full-screen multimedia. I
>> realize that my needs are unusual, and boost::gui
>> may be unable to
>> accomodate them.
>
> It seems strange to me, why are you willing to give up
> on your requirements. What is so unusual about them? I
> believe boost::gui must accomodate them and it can.
> Your requirements are very reasonable IMHO.
Ok.
>> Nonetheless I also dislike the idea of
>> PhysicalGUILayer as a template
>> parameter to all GUI elements.
>
> PhysicalGUILayer is great for your requirements. Why
> do you dislike it?
There's the compile-time issue, but there's also the physical dependency
between the high-level GUI structure and the physical GUI layer. I would
prefer a system where they are kept independent. This would have the
benefit of allowing the phyisical GUI layer to be specified at runtime.
top_level_window = create_top_level_window();
if (using_wx_windows) {
wx_gui_layer::run(top_level_windows);
} else {
win32_gui_layer::run(top_level_windows);
}
>> It violates the
>> principle of Once and Only
>> Once.
>
> You can use a default template parameter for the
> PhysicalGUILayer and define it only once in your
> program.
The GUI code would still be physically bound to a single physical GUI layer.
--
Rainer Deyke - [EMAIL PROTECTED] - http://eldwood.com
___
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
[boost] Re: Re: GUI/GDI template library
E. Gladyshev wrote: >> Not quite. pImpl is really bad when you have >> multiple interacting >> concrete types. I think you'll find yourself doing >> a lot of >> polymorphic_downcast<>s. > > Another good point against the pImpl idiom. I'd > suggest to overwrite some of the boost libaries that > use the pImpl thing. It is not like a modern C++ at > all. Are you aware that the pImpl idiom is used for many different things or have you just decided its not modern C++ at all because you don't use it for the things you want to do ? ___ 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 resour
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
[boost] Re: Re: GUI/GDI template library
"Brock Peabody" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > > -Original Message- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > On Behalf Of Gregory Colvin > > Sent: Tuesday, July 29, 2003 1:15 PM > > To: Boost mailing list > > Subject: Re: [boost] Re: GUI/GDI template library > > > > 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. regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: GUI/GDI template library
"Brock Peabody" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > 1. Resouce files can be easily edited by hand, contrary to > "inline" > > GUI-building code. > > 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. If you have more or less complicated GUI with multiple event handlers, you should use a LOT of binders and other modern c++ like techniques ... Now imagine that this all is written by somebody else and your task is to continue work on such project ... 1. i'm 99% sure that plain resource language or even XML is much cleaner than c++ bindings- templates-operators mess. 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. > > > > > 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 :) > 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. > > > > > 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 . 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). 3. Resource files are just for simplifying developer life. I beleive there still should be way to create gui using pure c++ code. The only thing i want is to have more runtime possibilities than "spirit" does. (Personally i'll be completely happy if spirit include kind of parser/lexer code generator more complicated than bison/flex but more lightweight than ANTLR). 4. Creating GUI isn't only job for programmer. Frequently there is a plenty of work for designers (commonly not so good c++ programmers ) ... in this case kind of resource editor is much preferable than c++ code (even simple and nicely documented one) and you don't want to use XP "dual programming" ... :o). > > Whether it's a good idea or not, I think if you were going to go to the > trouble of generating a resource script language and editor that you > wouldn't necessarily want to tie it to one programming language (i.e. > c++). IMHO, creating simple resource script language or using XML isn't as difficult as you might think of. BTW, boost has nice bindings to python ... possibly it can be used too ? Most modern GUI libraries have bindings to python and/or to some other script languages. Would be it be "100% correct" just to close this way and use compile-time pragmatism ? regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: GUI/GDI template library
"Brock Peabody" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > 1. Resouce files can be easily edited by hand, contrary to > "inline" > > GUI-building code. > > 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. If you have more or less complicated GUI with multiple event handlers, you should use a LOT of binders and other modern c++ like techniques ... Now imagine that this all is written by somebody else and your task is to continue work on such project ... 1. i'm 99% sure that plain resource language or even XML is much cleaner than c++ bindings- templates-operators mess. 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. > > > > > 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 :) > 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. > > > > > 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 . 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). 3. Resource files are just for simplifying developer life. I beleive there still should be way to create gui using pure c++ code. The only thing i want is to have more runtime possibilities than "spirit" does. (Personally i'll be completely happy if spirit include kind of parser/lexer code generator more complicated than bison/flex but more lightweight than ANTLR). 4. Creating GUI isn't only job for programmer. Frequently there is a plenty of work for designers (commonly not so good c++ programmers ) ... in this case kind of resource editor is much preferable than c++ code (even simple and nicely documented one) and you don't want to use XP "dual programming" ... :o). > > Whether it's a good idea or not, I think if you were going to go to the > trouble of generating a resource script language and editor that you > wouldn't necessarily want to tie it to one programming language (i.e. > c++). IMHO, creating simple resource script language or using XML isn't as difficult as you might think of. BTW, boost has nice bindings to python ... possibly it can be used too ? Most modern GUI libraries have bindings to python and/or to some other script languages. Would be it be "100% correct" just to close this way and use compile-time pragmatism ? regards, bohdan ___ 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
[boost] Re: Re: GUI/GDI template library
Philippe A. Bouchard wrote:
[...]
> Because you have more control over individual listbox' entries. Take for
> example MS Excel. It is a spread sheet (list< list< entry std::string> > >) with different popups on each entry, depending on its
> data type and other user-defined conditions.
In fact, it is more a multi_array, 2>...
> Even a listBox can be a list< list< entry<...> > > with hidden columns,
> etc.
>
> What I would like to see is a listBox of lineEdits, labels, or even
> pushbuttons or labeled checkboxes, like the Advanced Options in MS
> Internet Explorer.
[...]
Or a tree-like container for file management, etc.
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.
--
Philippe A. Bouchard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: GUI/GDI template library
Bronek Kozicki wrote: [...] > Uh. I would not recommend inheriting from STL. I think that template > policies would be rather more appropriate solution: Agreed. > typedef boost::gui::list, > boost::gui::win32::listbox, boost::gui::fast_signals> mylistbox; I personnally prefer seeing something similar to: typedef std::list< boost::entry > listbox; typedef std::list< boost::container > mylistbox; Because you have more control over individual listbox' entries. Take for example MS Excel. It is a spread sheet (list< list< entry > >) with different popups on each entry, depending on its data type and other user-defined conditions. Even a listBox can be a list< list< entry<...> > > with hidden columns, etc. What I would like to see is a listBox of lineEdits, labels, or even pushbuttons or labeled checkboxes, like the Advanced Options in MS Internet Explorer. > myWindow.create_widget(myapp::ENUM_ID_LIST_OF_ITEMS, > boost::gui::position(30, 30)); > myWindow(myapp::ENUM_ID_LISTOFITEMS).append(myData.begin(), > myData.end()); > > (just an idea) Do not forget dynamic layout management... ;) -- Philippe A. Bouchard ___ 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
[boost] Re: Re: GUI/GDI template library
E. Gladyshev wrote: >> Microsoft has a Windows Template Library, WTL, for >> Windows specifically, >> which is template-based but which they barely >> support for their VC++ users. > > The main point of the proposed library is not a > wrapper. WTL is just a Win32 wrapper. > The main idea is to simplify the use of STL containers > as data sources for UI widgets (in a portable way). > See my ListControl sample in a prev. message. > Also the proposed library will help to organize the > GUI/GDI elements and controlling data structures in a > consistent (with the C++ standard) way using the > 'iterator' paradigm. I understand that. > > It seems to me that in our practicle life, we ended up > with two different worlds in our hands. One is the > nice and clean C++ template world which works great to > program algorithms and data strucures and another one > is the dirty GUI world that we have to use to present > our nice data structures. Most of the time when we try > to bring these two together, the nice structure of C++ > template programming doesn't look so nice anymore. Again I see what you want to do. > > It is a big project but at the end, it should bring > these two worlds together (at least bit). 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. 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. While there may well be C++ programmers looking for a cross-platform GUI/GDI from Boost, most programmers are already very comfortable with the framework which comes with their C++ compiler and with the IDE features and tools that make using their "widgets" very easy. Some of these frameworks, hooked to dialog editors or window placement tools, allow the programmer to literally draw or place the widget exactly where it should go and specify both the widget's physical representation and data representation, and even the structures by which the data will be passed from and to the widget. The amount of code which must be written often becomes negligible by the programmer after the design time interfaces have been set up. Yes, the data structures are pretty primitive compared to C++ template containers and whatever other good things you might create, 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. 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 am not trying to argue you against pursuing your goal but simply trying to point out the difficulties that exist and the barriers against many C++ programmers adopting your implementation as opposed to what they have already been using. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
