> -----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<employee> 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.
>
> 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).
I agree here. Surely they could share some code. Likely one would be
implemented in terms of the other.
>
> 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).
Please don't encourage non-programmers to do development :) Some day in
the not so distant future a real programmer will have to redo the
project.
>
>
> >
> > 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 ?
I think we could come up with both a compile time and a resource
oriented system. It is important to me to be able to do everything
inline in C++ without knowing about or interfacing with any other
applications. I can understand how in other situations it may be
important to deal in resource scripts rather than c++.
Brock
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
