- Boost - lists.boost.org

Re: [boost] Re: GUI library - another one
by Beman Dawes 04 Mar '04

04 Mar '04

At 12:10 PM 3/4/2004, David Turner wrote: >... A button in one window isn't necessarily >the same thing as a button in another window; just as a bold font in one >document isn't necessarily the same as a bold font in another. I'd rewrite that as "The implementation of a button in one window isn't necessarily the same thing as the implementation of a button in another window..." To modify Dave's example to make a point: button OK_button("OK"); window_one("Warning: now entering twilight zone one") [ text_field("my favorite color is:"), OK_button | button("cancel") | attribute_x(1) ] window_two("Warning: now entering twilight zone two") [ text_field("my favorite color is:"), OK_button | button("cancel") | attribute_x(2) ] Perhaps the implementation of OK_button in window_one is very different from window_two. But they both have OK_buttons, and at the interface level these are the same button. > >One cannot say in general that elements can be exchanged between >documents. Similarly, one cannot say in general that widgets can be >exchanged between windows. I understand that the implementation details can't be exchanged. But we aren't taking about implementations of buttons, we are talking about the abstract concept of an OK_button. That certainly could be transferred, couldn't it? More importantly, you could build up a widget library which could be used regardless of the target window. Sorry if I'm missing something here; I'm not much of a GUI programmer. --Beman

6 5

Re: GUI library - another one
by Jesse Booher 04 Mar '04

04 Mar '04

>>> dave(a)boost-consulting.com 03/04/04 08:59AM >>> > button("click me") doesn't have to be a widget. Think expression > templates. It can just build up a type to be used by window to add a > button. Well said. This exemplifies the reason why most gui toolkits are so horrible to use, they allow implementation technicalities to dictate interface. Having to decide where an object is going to live before any of its properties can be set is a clear violation of object oriented design principles but we live with these kind of problems all the time for supposed technical reasons.

7 12

Re: [boost] Re: GUI library - another one
by Jesse Booher 04 Mar '04

04 Mar '04

David Turner wrote: > At a broader level, I'd argue that there is a good reason to use this > document/elements design because the type of the widgets have to match the > type of window they're going to go into. If we think of a button object as a particular implementation designed explicitly to support a particular window's interface requirements, this is would make sense. However, we might step back from the implementation particulars and consider a button to be a collection of properties such as caption, color, etc. that might at some point get bound to a window at which point the button object could become linked to a widget implementation appropriate to that context. This opens up the possibility that an object will specify properties that the implementation to which it gets attached does not support, but this is one of the corner stones of object oriented design. An object (e.g. button) advertises it properties and it's up to the user of the object (e.g. window) to realize those properties as best it can. Regards, Jesse Booher

1 0

RE: [boost] Re: First lambda
by Powell, Gary 04 Mar '04

04 Mar '04

>>Yeah, but do you propose to make local names visible inside the anonymous >>function, or not? If you do, you open a big can of worms for implementations >>(recursive nested functions, need I say more?), if you don't, BLL can still >>do things that anonymous functions can not. Anonymous functors could help >>some, but their syntax won't be quite as compact as your example above. > Now, to complicate matters, what if I wish to access v in the > inner anonymous function? Can you also do that? Example: > std::for_each(vv.begin(), vv.end(), > void (vector<int> const& v) > { > std::for_each(v.begin(), v.end(), > void (int x) > { > cout << x << endl; > do_fomething_with(v); // <<--here > } > } > ); > Joel de Guzman This gets ugly. As you want to "import" only one the variables you declare. For the previous example with std::accumulate. e.g.. implementation. template <class InputIterator, class T, class BinaryOperation> T accumulate<InputIterator v, InputIterator l, T i, BinaryOperation bin_op) { while (v != l) i = bin_op(i, *v++); return i; } int i = 0; unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, auto (auto lhs, auto rhs) { return ( lhs + rhs.count) + i; // Which "i"!!!! } ); And this is where BLL wins big, it has a mechanism for importing variables into the fn. And no I don't have a good solution for this. -Gary-

1 0

RE: [boost] Re: First lambda
by Powell, Gary 04 Mar '04

04 Mar '04

> "Shannon Stewman" <stew(a)uchicago.edu> wrote in message > news:20040304025205.GD832@uchicago.edu... > >>On Wed, Mar 03, 2004 at 01:34:50PM -0800, Powell, Gary wrote: >> >> >>>unsigned long n = std::accumulate( >>> xs.begin(), xs.end(), 0UL, >>> long (long lhs, X const &rhs) // inline fn with no > > name. > >>> { >>> return lhs + rhs.count; >>> } >>> ); >> >>This seems to cast out the type inference present in BLL. I think >>that's one of the nicer concepts in the lambda library, and a real >>boon to programming. In my limited experience with SML/OCaml, type >>inference seems a better, safer, and more convenient way to program, >>albeit requiring a lot more compiler intelligence. As BLL shows, > > though, > >>this is quite possible, though perhaps limited, with existing C++. >> > > > How about: > > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > auto(long lhs, const auto& rhs) // inline fn with no > name. > { > return lhs + rhs.count; > } > ); > I would prefer also eliding the argument types: > > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > lambda(lhs, rhs) > { > return lhs + rhs.count; > } > ); > > Most of the time, you also do not know the type of the > arguments before hand. > Joel de Guzman There are still direct templates (even without implied ones.) The syntax would be a bit verbose though. unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, template<class T, class S) auto (T const &lhs, S const &rhs) { return lhs + rhs.count; } );

1 0

circular_buffer v3.6
by Jan Gaspar 04 Mar '04

04 Mar '04

Hello all! New version of the circular_buffer is available. It can be found at http://groups.yahoo.com/group/boost/files/circular_buffer_v3.6.zip Release notes: - fixed bug regarding not destroyed elements - requirements for element types were changed to CopyConstructible concept - changed debug support classes - no dynamic memory allocation needed - changed debug support for invalidated iterators: assertion raised also when used iterator which points to the overwritten element - added allocator& get_allocator() /* NONCONST */ {...} method - added functionality to set_capacity() and resize() methods - changed circular_buffer_space_optimized constructor signatures Regards Jan __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com

1 0

RE: [boost] GUI library - another one
by Jesse Booher 04 Mar '04

04 Mar '04

>>> hurdm(a)sig.com 03/03/04 10:30PM >>> >> Even the "why not" version seems overly complex compared to a console >> iostreams "Hello, world". Why not just: >> >> winout << title("Example window") << button("Hello, world!") >> << wait_for(delete_signal); >> >> I'm not necessarily pushing that exact approach, but just pointing out >> more >> C++-like alternatives. > > I understand you're not pushing that approach. It couldn't quite work > like that as you're trying to structure a tree rather than a sequence. Not that I'm pushing the approach either, but if all your objects that can be parents have an insertion operator then building a tree is simple a matter of adding parentheses: tree << a << b << © << d << e << (f << g) ); or breaking it up f << g; c << d << e << f; tree << a << b << c;

1 0

Re: GUI library - another one
by Jesse Booher 04 Mar '04

04 Mar '04

It is never a bad thing when someone is interested in donating their time to develop software to share with the world, and if there is a community of developers here with the time and motivation to develop a full featured GUI library that rises to the high standards of Boost that would be a wonderful thing. That said a GUI library is a *HUGE* undertaking and other cross platform libraries like wxWidgets have a big head start. Not that this is a race or anything but when it comes to GUI libraries, features nearly always trump form. After all an awkward interface is a developer annoyance, whereas a missing feature can be a show stopper. There is a certain allure to clean slate designs and there may very well be no existing open source user interface projects that you would consider worthy of your time, but I wondered if you have considered any slightly less ambitious alternatives such as creating a framework employing components from an existing open source project? It seems to me that the promise of open source development is not served when wheels (or widgets) need to be reinvented over and over again.

3 2

RE: [boost] GUI library - another one
by Hurd, Matthew 04 Mar '04

04 Mar '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Shannon Stewman > Sent: Thursday, 4 March 2004 2:42 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] GUI library - another one > > On Wed, Mar 03, 2004 at 10:30:47PM -0500, Hurd, Matthew wrote: > > > On Behalf Of Beman Dawes > > > > <snip> > > > > > Even the "why not" version seems overly complex compared to a console > > > iostreams "Hello, world". Why not just: > > > > > > winout << title("Example window") << button("Hello, world!") > > > << wait_for(delete_signal); > > > > > > I'm not necessarily pushing that exact approach, but just pointing out > > > more > > > C++-like alternatives. > > > > I understand you're not pushing that approach. It couldn't quite work > > like that as you're trying to structure a tree rather than a sequence. > > This is beside the point. Trees are isomorphic to lists that contain > lists. For example: > > winout << title("Example window") > << divider(2) << up << ( panel << vertical > << label("Hello, world!") > << textentry("Name: ") ) > << down << ( panel << horizontal > << button("OK") > << button("Cancel") ); > > Which, assuming my parens are right, could give you something > like: > > +---------------------------------------------+ > | Hello, world! | > | Name: ____________________________ | > +---------------------------------------------+ > | /-------\ /--------\ | > | | OK | | Cancel | | > | \-------/ \--------/ | > +---------------------------------------------+ > For sure, to be sure. Not sure I like the approach though. You could off add and << as alternative for the same thing. I see that you could have multiple properties for the same container by having the result as the container too. Some_widget << colour_red << width(pixel(100)) << text_box << font("Arial") << height(millimetres(8)); Not unreasonable and you could format it like Some_window << ( some_widget << colour_red << width(pixel(100)) << some_other_property ) << ( panel << horizontal << ( button("OK") << click_event( dooby_doo::on_click ) ) << button("Cancel") ) ; Not as bad as I thought before I started typing this mail... Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

RE: [boost] GUI library - another one
by Hurd, Matthew 04 Mar '04

04 Mar '04

> On Behalf Of Beman Dawes <snip> > Even the "why not" version seems overly complex compared to a console > iostreams "Hello, world". Why not just: > > winout << title("Example window") << button("Hello, world!") > << wait_for(delete_signal); > > I'm not necessarily pushing that exact approach, but just pointing out > more > C++-like alternatives. I understand you're not pushing that approach. It couldn't quite work like that as you're trying to structure a tree rather than a sequence. Your << approach might be nice syntactic sugar for adding an element and event_handlers or listeners and / or modifying a property. Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2