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

2003-08-14 Thread Drazen DOTLIC
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

2003-08-14 Thread Brock Peabody


> -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

2003-08-14 Thread E. Gladyshev

--- 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

2003-08-09 Thread Rozental, Gennadiy
> 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

2003-08-07 Thread E. Gladyshev

--- 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

2003-08-04 Thread Brock Peabody


> -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

2003-08-04 Thread John Torjo
> >   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

2003-08-02 Thread Terje Slettebø
>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

2003-08-01 Thread E. Gladyshev

--- 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 Thread Rene Rivera
[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

2003-08-01 Thread E. Gladyshev
> 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

2003-07-29 Thread Brock Peabody


> -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

2003-07-29 Thread Gregory Colvin
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

2003-07-29 Thread Brock Peabody


> -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

2003-07-29 Thread Brock Peabody


> -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

2003-07-29 Thread Gregory Colvin
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

2003-07-29 Thread Brock Peabody

> -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

2003-07-29 Thread Bronek Kozicki
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

2003-07-29 Thread Bronek Kozicki
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

2003-07-28 Thread E. Gladyshev
> 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

2003-07-28 Thread E. Gladyshev
> 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

2003-07-28 Thread Brock Peabody


> -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

2003-07-28 Thread Brock Peabody


-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

2003-07-27 Thread Scott Woods
> 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

2003-07-26 Thread Thomas Witt

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

2003-07-25 Thread E. Gladyshev
[...]
> 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