[boost] Re: Re: GUI/GDI template library

From: Bohdan (gejrlaug_at_[hidden])
Date: 2003-07-29 17:09:53

"Brock Peabody" <brock.peabody_at_[hidden]> wrote in message
news:005901c355fe$d78ea5d0$580a10ac_at_npci.com...
>
<snip>
> >     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