I totally agree with your statements besides javascript, win32 & .NET
because you know better this stuff than I do. The only platform dependent
utils you need is stylish fonts, locales, frames, rectangles, windows &
menus in the end.
A spinbox is basically a lineedit with 2 button; a combobox is
Do I detect some sarcasm here? I thought it was fairly clear why I mentioned
javascript, win32, etc. Did I say something you agree with? Something
obvious? I can't tell.
"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> It smells like what I was saying in pa
It smells like what I was saying in part besides the javascript, win32 API &
.NET. What is the definition of a widget? It is basically the visual
representation of a container. In ten years from now, I expect to cout my
application to the screen:
typedef tree >, ...> >, ...> >, ...> > myapplica
Based on David's suggestion, I'll try to briefly define all the terms
I've used in my earlier post.
> Brian McNamara <[EMAIL PROTECTED]> writes:
> > I have posted the first "boostified" version of FC++ to the YahooGroups
> > files section; it is called "fcpp".
> >http://groups.yahoo.com/group/
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of E. Gladyshev
> Sent: Monday, July 28, 2003 6:34 PM
> To: Boost mailing list
> Subject: Re: [boost] Re: GUI/GDI template library
>
> I agree that one can derive other required ingradients
> from the ones
Brock Peabody
Software Development Manager
NPC International
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Rob & Lori
> Sent: Monday, July 28, 2003 5:56 PM
> To: 'Boost mailing list'
> Subject: RE: [boost] GUI/GDI template library
>
> > -Or
> 3. I believe almost everything can be done using the
> following ingredients:
> a. The ability to create, destroy, size,
> position, show and hide a
> rectangular window with no children and no
> decorations.
> b. The ability to draw an image (bitmap, png,
> etc.) at a particular
> poin
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Brock Peabody
> Sent: Monday, July 28, 2003 9:16 AM
> To: 'Boost mailing list'
> Subject: RE: [boost] GUI/GDI template library
>
>
> It wasn't a great leap to progress further to:
>
> typedef boost::mpl
When I tried to run the regression tests for MacOS (gcc 3.2) this morning;
they didn't complete.
This seems to be the relevant portion of the regression log:
don't know how to make config_info/regex_config_info.cpp
don't know how to make concepts/concept_check.cpp
don't know how to make concept
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of E. Gladyshev
> Sent: Monday, July 28, 2003 5:27 PM
> To: Boost mailing list
> Subject: RE: [boost] GUI/GDI template library
>
> It makes a perfect sense. Thanks for the details. I
> guess things like
> 2. is there potential to identify a "generic state
> machine"
> that can be part of your gui templates/library
> without
> getting tangled in the application specific
> machines. i
One more on the state machines. Even the standard
button control is a state machine (when you press it,
it goes to
> Does this make sense? I'm sorry if I am not
> explaining this very well.
> I'll see if I can dig up the documentation I wrote
> for our programmers
> here.
It makes a perfect sense. Thanks for the details. I
guess things like resizable dialog boxes are a natural
consequence of your design.
EG
I am very interested in this project, and would be willing to devote a
considerable amount of time to it, depending on how it evolves. (Please
forgive me if I focus exclusively on GUI objects, and ignore the connection
with STL-containers of non-GUI objects.)
I believe that it is possible to creat
> 1. events are very much part of the state machine
> issue.
> i mean, what is receiving the events and how do they
> respond to the events (at different times)?
The library would consider all events as independent
slots that need to be created by the app or
internally. It is similar to the MFC's
At 05:44 PM 7/28/2003, David Abrahams wrote:
>
>I have confirmed that the problem reported below is occurring: Please
>take extreme care in using the Boost website until we've corrected it.
>The web pages are unmodified on the server itself, so we have to wait
>for Beman to contact the ISP.
I just
FYI, Users of browsers other than Microsoft Internet Explorer need
not worry (unless there's another attack for other detected browsers
embedded in our server).
I tried to collect as much information regarding the attack as I
could; scripts, binaries, etc.
It seems that the following MS IE v
David Abrahams wrote:
Juanma Barranquero <[EMAIL PROTECTED]> writes:
On Sat, 26 Jul 2003 13:03:36 -0400
David Abrahams <[EMAIL PROTECTED]> wrote:
Well, that's self contradictory!
Not really. A bit later it says:
On all x86 compatibles (Celeron, PIII, P4, Athlon, etc) you need gcc
2.95.x or ear
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of E. Gladyshev
> Sent: Monday, July 28, 2003 1:00 PM
> To: Boost mailing list
> Subject: RE: [boost] GUI/GDI template library
>
>
> > boost::function positioner =
> > row( edit_1, combo_1, co
> > Sometimes you want your events to be called
> > instantaneously (clear
> > paintdevice before drawing on it) and sometimes you
> > will want to catch and
> > forward them elsewhere (i.e. keystrokes). You need
> > both.
>
> I guess what I am trying to say is that I'd prefer a
> single underlyi
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Philippe A. Bouchard
> Sent: Monday, July 28, 2003 8:13 AM
> To: [EMAIL PROTECTED]
> Subject: [boost] RE: Re: Re: GUI/GDI template library
>
> Yes I know, this could be defined by another property wha
I have confirmed that the problem reported below is occurring: Please
take extreme care in using the Boost website until we've corrected it.
The web pages are unmodified on the server itself, so we have to wait
for Beman to contact the ISP.
Sorry,
Dave
From: turbotrup256 <[EMAIL PROTECTED]>
>
> Sometimes you want your events to be called
> instantaneously (clear
> paintdevice before drawing on it) and sometimes you
> will want to catch and
> forward them elsewhere (i.e. keystrokes). You need
> both.
I guess what I am trying to say is that I'd prefer a
single underlying event genera
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of JOUBERT Antoine
> Sent: Monday, July 28, 2003 4:14 AM
> To: '[EMAIL PROTECTED]'
> Subject: [boost] FW: Dijkstra with several starting point
>
> -Original Message-
> From: JOUBERT Antoine
> Sent: 28
E. Gladyshev wrote:
>> 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 sh
E. Gladyshev wrote:
[...]
> 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< bo
Brock Peabody wrote:
>
>
>> -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,
Brian McNamara <[EMAIL PROTECTED]> writes:
> On Mon, Jul 28, 2003 at 05:38:01PM +0200, Miroslav Silovic wrote:
>> Well, nobody posted anything definite on FC++, which is a pity, since I
>> find this library potentially very useful. Here are some comments.
>> Caveat: I haven't extensively used th
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> On Sat, 26 Jul 2003 13:03:36 -0400
> David Abrahams <[EMAIL PROTECTED]> wrote:
>
>> Well, that's self contradictory!
>
> Not really. A bit later it says:
>
>> On all x86 compatibles (Celeron, PIII, P4, Athlon, etc) you need gcc
>> 2.95.x or earlier,
> 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
> 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
"Nigel Stewart" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> > IMO the resize/shrink cannot be added via adaptor (unless it is very
complex
>> > one).
>>
>> An adaptor that wraps push() and insert() would
>> be considerd too heavy-weight?
>
I think it is pretty heavyweight, but m
On Mon, Jul 28, 2003 at 05:38:01PM +0200, Miroslav Silovic wrote:
> Well, nobody posted anything definite on FC++, which is a pity, since I
> find this library potentially very useful. Here are some comments.
> Caveat: I haven't extensively used the library, but I have quite a bit
> of experienc
> boost::function positioner =
> row( edit_1, combo_1, column( edit_2,
> some_static_text));
Interesing idea about a separate positioner object.
What are the row/column do exactly?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web s
> Uh. I would not recommend inheriting from STL. I
> think that template
> policies would be rather more appropriate solution:
I agree with that.
> myWindow.create_widget
>(myapp::ENUM_ID_LIST_OF_ITEMS,
Just a note.
Ideally, the library won't have to deal with the
numeric control ID's. You cre
> -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 Libra
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 fac
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
Dear Boost friends,
> was unwittingly working with apples and oranges. Correct me if I'm wrong,
> but it really feels like the two containers are a scalar data type (ignoring
> the attached associative data structures) and a metric (or "distance"
> function). "Metric" is already a much more gene
Well, nobody posted anything definite on FC++, which is a pity, since I
find this library potentially very useful. Here are some comments.
Caveat: I haven't extensively used the library, but I have quite a bit
of experience with functional programming. I won't comment on the naming
scheme or th
John Maddock wrote:
> > In adding output streaming support for variant, I've realized the
> > standard library packaged with gcc 2.9.7 and below does not support the
> > templated stream classes. I've also realized that Boost.Tuple features a
> > workaround addressing this same problem, with a comm
-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
> differenc
I'm using a library I developed here at work which I developed with the
goals of
1) hiding MFC
2) eliminating the repetitious and tedious nature of positioning and
manipulating various controls.
My library is far from boost ready (as it depends on other libraries of
mine and is only implemented f
IMO the resize/shrink cannot be added via adaptor (unless it is very complex
one).
An adaptor that wraps push() and insert() would
be considerd too heavy-weight?
It may be possible to design circular_buffer<> as adaptor over [vector |
deque | list | slist | shrinkable vect
From: JOUBERT Antoine <[EMAIL PROTECTED]>
> I want a shortest path calculation from several starting point . I
> could of course reapply the dijkstra for every starting point, but i
> would rather initialize Disjkstra with a container of vertex .
If I understand you correctly, I did this by addin
-Original Message-
From: JOUBERT Antoine
Sent: 28 July 2003 12:09
To: '[EMAIL PROTECTED]'
Subject: Dijkstra with several starting point
I want a shortest path calculation from several starting point . I could of course
reapply the dijkstra for every starting point, but i would rather
On Sat, 26 Jul 2003 13:03:36 -0400
David Abrahams <[EMAIL PROTECTED]> wrote:
> Well, that's self contradictory!
Not really. A bit later it says:
> On all x86 compatibles (Celeron, PIII, P4, Athlon, etc) you need gcc
> 2.95.x or earlier, or gcc 3.1 or newer.
WRT best optimizer
> Also, I'm str
Dear Boost friends,
Thanks for all the comments. They encourage us to go ahead with our
plans for SMTL. SMTL spatial maps are implemented with Kd-trees and metric
containers are implemented with vantage-point trees (vp-trees), but
many other implementations are possible and we would like to suppor
Philippe A. Bouchard <[EMAIL PROTECTED]> wrote:
>> // ScrollViews, ButtonGroups, ListBox, ...:
>> typedef list container;
> struct container : list { ... };
>
Uh. I would not recommend inheriting from STL. I think that template
policies would be rather more appropriate solution:
typedef boost::g
"Nigel Stewart" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> > Wouldn't it be better to use smaller internal memory block initially and
> > resize it only when demand goes up?
>
> That's a good point, but it certainly complicates both the interface
> and the semantics of the con
49 matches
Mail list logo
