- Boost - lists.boost.org

RE: [boost] Re: Re: C++ GUI - another view
by Brian Braatz 24 Sep '04

24 Sep '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Noah Stein [Brian Braatz] (Snip)_ > > Yes..As I have touched in in a previous post this should be accessible > at > > the 'device layer'. OTOH Another way to look at a pixel is as a > > rectangular > > box that is *currently*, *on this device*, (say) 0.25 mm wide and 0.25 > mm > > high or whatever, the next layer up. > > What does "accessible at the device layer" mean in this context? A pixel > is > a fundamental unit in any graphics context. I don't think that an > application programmer should be forced to jump through hoops to get at > it. > [Brian Braatz] I have been watching this one for a bit now and it is time for me to weigh in. I have 2 perspectives to share: ** Encapsulation of common functionality in UI frameworks*** I am working on a framework that sits on top of boost for the purpose of making Thick Client DB apps. One of the things that I am going to be needing is a *light* layer over the various windowing libraries out there. What I need is about 20% of the common functionality between MFC\ Winforms\ Qt\ WxWindows in standard wrapper classes. This will allow me to write "most" of my applications to that interface and select the underlying platform\ framework as a build target. I mention my problem domain, because I believe it to be a rather common one. I also agree with the notion that it takes *alot* of effort to fully encapsulate a GUI. What I would LIKE would be a simple windowing system that I can use, maybe it is not the most robust, but it is "boost standard". This would then allow me to write portable Gui applications. In so far as paradigm, this would mean choosing between the common model features of the above libraries. I will be developing this, and may eventually submit it to boost, but if someone does before me, all the better. I just eventually want something that is "standard" in some way that gives me platform \framework isolation. *** Simple windowing layer needed for Boost ** I would like to also develop some GUI tools that do things like allow one to: * "step through" bjam files interactively \ debug * Show a "report" of my command line configuration outlining what appears to be set correctly (i.e. doxygen will not work in your config because variable XX is not set to a valid path) (maybe even a little cartoon dog that wags his tail if your vars are set properly) (<< JUST KIDDING) I believe simple gui tools along those lines would help the usage and spread of boost in general, and would help those who use boost on a day to day basis. To support that concept- I suggest something along the lines of the TinyXML library buried somewhere in boost. It is a bare bones lib that gets the job done. If we were to have: * Ability to create dialogs * make buttons and respond to them * make edit controls and read and write to them * make list boxes and manipulate them * make a tree control and manipulate it As a *very* simple and light library, this would allow me to make simple GUI apps that were "boost standard". The above functionality should be simple enough to do with Raw API calls on the various platforms. I would ask that those considering GUI libs take my perspective seriously, as the greatest value that can be had is "having something simple that is standard", more than it is in making something do everything. This would also provide a small incremental step to address many of the interesting ideas that have been put forth on this thread. :) (my 2 cents) Brian Braatz

2 1

getting started with boostbook
by Neal D. Becker 23 Sep '04

23 Sep '04

I'm trying to learn boostbook. I want to use this without bjam. Any hints what's wrong here: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN" "http://www.boost.org/tools/boostbook/dtd/boostbook.dtd"> <library name="Any" dirname="any" xmlns:xi="http://www.w3.org/2001/XInclude" id="any" last-revision="$Date: 2004/01/15 16:08:59 $"> <libraryinfo> <author> <firstname>Kevlin</firstname> <surname>Henney</surname> </author> <librarypurpose> Safe, generic container for single values of different value types </librarypurpose> <librarycategory name="category:data-structures"/> </libraryinfo> </library> xsltproc /usr/local/src/boost.cvs/tools/boostbook/xsl/html-single.xsl \ test.xml > stuff No template for "/library" (or any of its leaves) exists in the context named "title" in the "en" localization. No template matches library. No template matches libraryinfo in library. No template matches librarypurpose in libraryinfo. No template matches librarycategory in libraryinfo.

2 1

Thread-safety in Boost.Signals
by Aaron W. LaFramboise 23 Sep '04

23 Sep '04

I see that the FAQ mentions that a future version of Boost.Signals will be thread-safe. Are there any plans for this to happen any time soon? Right now, is there even a weak thread-safety guarantee? Specifically, may two separate signal objects be manipulated by two separate threads at the same time? Aaron W. LaFramboise

2 1

outputformatters - using just one decorator string
by John Torjo 23 Sep '04

23 Sep '04

Hi Reece, This just popped into my head. A lot of confusion seems to come from how you pass decorators. What I'm trying to say is that it can be very difficult to get the decorator strings right (especially for more complex things like XML) from the first time. I would suggest every formatter takes only one string which parses and finds all decorators itself. Each formatter will have one or more escape sequences which it uses to find the decorators. Something like: // in this case, '%' is used for identifying an element // '*' is to mean "leave default" (don't change) std::vector<int> v; // equivalent to your "[ ", ", ", " ]" std::cout << formatob(v, "[ %, % ]"); // eq. to "<< ", " | ", " >>" std::cout << formatob(v, "<< % | % >>"); // set only open/close decorators std::cout << formatob(v, "<< %*% >>"); // sets only the separator std::cout << formatob(v, "*% | %*"); // for pair - you have "%1" and "%2" std::vector< std::pair<int,long> > vp; // write XML std::cout << formatob(vp, containerfmt("<elem> % </elem><elem> % </elem>", pairfrt("<int>%1</int><long>%2</long>"))); How's that? Best, John -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

6 10

[graph] fix for intel-win32-7.1-vc6
by Joaquín Mª López Muñoz 23 Sep '04

23 Sep '04

This trivial fix takes care of issues having to do with BOOST_NO_STDC_NAMESPACE, which impact the test layout_test on intel-win32-7.1-vc6. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 106a107 > #ifndef BOOST_NO_STDC_NAMESPACE 107a109 > #endif // BOOST_NO_STDC_NAMESPACE 126a129 > #ifndef BOOST_NO_STDC_NAMESPACE 127a131 > #endif // BOOST_NO_STDC_NAMESPACE 145a150 > #ifndef BOOST_NO_STDC_NAMESPACE 146a152 > #endif // BOOST_NO_STDC_NAMESPACE

3 2

[graph] A patch for an invalid html link in the docs.
by Jurko Gospodneti� 23 Sep '04

23 Sep '04

Hi all. I attaching a patch for file 'libs/graph/doc/using_adjacency_list.html' that fixes one invalid link in a '<A HREF>' tag. Would someone please apply it. Hope this helps, Jurko begin 666 diff.txt M1DE,12!#3TU005))4T].#0I0<F]D=6-E9#H@,3 N.2XR,# T(#$U.C W.C0Y M#0H-"BHJ*B!U<VEN9U]A9&IA8V5N8WE?;&ES="YH=&UL(#(P,#0M,#8M,C @ M,#4Z,S<Z,3 N,# P,# P,# P("LM,#(P, T*+2TM('5S:6YG7V%D:F%C96YC M>5]L:7-T+FAT;6P@,C P-"TP.2TQ," Q-3HP-3HR,RXP,# P,# P,# @*RTP M,C P#0HJ*BHJ*BHJ*BHJ*BHJ*BH-"BHJ*B T,S,L-#8P("HJ*BH-"B @/%!2 M13X-"B @("!T>7!E9&5F('!R;W!E<G1Y)FQT.W9E<G1E>%]D:7-T86YC95]T M+"!F;&]A="P-"B @(" @(" @(" @(" @<')O<&5R='DF;'0[=F5R=&5X7VYA M;65?="P@<W1D.CIS=')I;F<F9W0[("9G=#L@5F5R=&5X4')O<&5R='D[#0H@ M(" @='EP961E9B!P<F]P97)T>29L=#ME9&=E7W=E:6=H=%]T+"!F;&]A="9G M=#L@161G95!R;W!E<G1Y.PT*#0H@(" @='EP961E9B!A9&IA8V5N8WE?;&ES M="9L=#MM87!3+"!V96-3+"!U;F1I<F5C=&5D4RP-"B @(" @(" @(" @(" @ M(" @(" @(" @(" @(%9E<G1E>%!R;W!E<G1Y+"!%9&=E4')O<&5R='DF9W0[ M($=R87!H.PT*#0H@(" @1W)A<&@@9RAN=6U?=F5R=&EC97,I.R O+R!C;VYS M=')U8W0@82!G<F%P:"!O8FIE8W0-"B @/"]04D4^#0H-"B @/% ^#0H@(%1H M92!P<F]P97)T>2!V86QU97,@87)E('1H96X@<F5A9"!F<F]M(&%N9"!W<FET M=&5N('1O('5S:6YG('!R;W!E<G1Y#0HA(&UA<',N(%-E92!396-T:6]N(#Q! M($A2148](B-S96,Z:6YT97)I;W(M<')O<&5R=&EE<R(^26YT97)I;W(-"B$@ M4')O<&5R=&EE<SPO03X@9F]R(&$@9&5S8W)I<'1I;VX@;V8@:&]W('1O(&]B M=&%I;B!P<F]P97)T>2!M87!S#0HA(&9R;VT@82!G<F%P:"P@86YD(')E860@ M4V5C=&EO;B \00T*(2!(4D5&/2(N+W5S:6YG7W!R;W!E<G1Y7VUA<',N:'1M M;"(^4')O<&5R='D@36%P<SPO03X@9F]R(&AO=PT*(2!T;R!U<V4@<')O<&5R M='D@;6%P<RX-"@T*(" \4#X-"@T*(" \2#,^/$$@3D%-13TB<V5C.F-U<W1O M;2UE9&=E+7!R;W!E<G1I97,B/CPO03X-"B @0W5S=&]M($5D9V4@4')O<&5R M=&EE<PT*(" \+T@S/@T*#0H@(#Q0/@T*("!#<F5A=&EN9R!A('EO=7(@;W=N M('!R;W!E<G1Y('1Y<&5S(&%N9"!P<F]P97)T:65S(&ES(&5A<WD[(&IU<W0@ M9&5F:6YE#0H@(&$@=&%G(&-L87-S(&9O<B!Y;W5R(&YE=R!P<F]P97)T>2X@ M5&AE('!R;W!E<G1Y('1A9R!C;&%S<R!W:6QL(&YE960@=&\-"BTM+2 T,S,L M-#4Y("TM+2T-"B @/%!213X-"B @("!T>7!E9&5F('!R;W!E<G1Y)FQT.W9E M<G1E>%]D:7-T86YC95]T+"!F;&]A="P-"B @(" @(" @(" @(" @<')O<&5R M='DF;'0[=F5R=&5X7VYA;65?="P@<W1D.CIS=')I;F<F9W0[("9G=#L@5F5R M=&5X4')O<&5R='D[#0H@(" @='EP961E9B!P<F]P97)T>29L=#ME9&=E7W=E M:6=H=%]T+"!F;&]A="9G=#L@161G95!R;W!E<G1Y.PT*#0H@(" @='EP961E M9B!A9&IA8V5N8WE?;&ES="9L=#MM87!3+"!V96-3+"!U;F1I<F5C=&5D4RP- M"B @(" @(" @(" @(" @(" @(" @(" @(" @(%9E<G1E>%!R;W!E<G1Y+"!% M9&=E4')O<&5R='DF9W0[($=R87!H.PT*#0H@(" @1W)A<&@@9RAN=6U?=F5R M=&EC97,I.R O+R!C;VYS=')U8W0@82!G<F%P:"!O8FIE8W0-"B @/"]04D4^ M#0H-"B @/% ^#0H@(%1H92!P<F]P97)T>2!V86QU97,@87)E('1H96X@<F5A M9"!F<F]M(&%N9"!W<FET=&5N('1O('5S:6YG('!R;W!E<G1Y#0HA(&UA<',N M(%-E92!396-T:6]N(#Q!($A2148](G5S:6YG7W!R;W!E<G1Y7VUA<',N:'1M M;"-S96,Z:6YT97)I;W(M<')O<&5R=&EE<R(^#0HA($EN=&5R:6]R(%!R;W!E M<G1I97,\+T$^(&9O<B!A(&1E<V-R:7!T:6]N(&]F(&AO=R!T;R!O8G1A:6X@ M<')O<&5R='D@;6%P<PT*(2!F<F]M(&$@9W)A<&@L(&%N9"!R96%D(%-E8W1I M;VX@/$$@2%)%1CTB=7-I;F=?<')O<&5R='E?;6%P<RYH=&UL(CX-"B$@4')O M<&5R='D@36%P<SPO03X@9F]R(&AO=R!T;R!U<V4@<')O<&5R='D@;6%P<RX- M"@T*(" \4#X-"@T*(" \2#,^/$$@3D%-13TB<V5C.F-U<W1O;2UE9&=E+7!R M;W!E<G1I97,B/CPO03X-"B @0W5S=&]M($5D9V4@4')O<&5R=&EE<PT*(" \ M+T@S/@T*#0H@(#Q0/@T*("!#<F5A=&EN9R!A('EO=7(@;W=N('!R;W!E<G1Y M('1Y<&5S(&%N9"!P<F]P97)T:65S(&ES(&5A<WD[(&IU<W0@9&5F:6YE#0H@ M(&$@=&%G(&-L87-S(&9O<B!Y;W5R(&YE=R!P<F]P97)T>2X@5&AE('!R;W!E <<G1Y('1A9R!C;&%S<R!W:6QL(&YE960@=&\-"@`` ` end

2 1

Workaround macro for intel-7.1-vc6-*
by Jonathan Brandmeyer 23 Sep '04

23 Sep '04

What is the correct BOOST_WORKAROUND macro for this platform? I'm currently using #ifdef ((BOOST_WORKAROUND( BOOST_INTEL_CXX_VERSION, == 710)) && defined(_WIN32)) which does not seem to be enough. Thanks, -Jonathan

3 3

[Optional] Inplace test is broken
by Aleksey Gurtovoy 23 Sep '04

23 Sep '04

"optional_test_inplace" fails on many compilers with the following diagnostics (from http://tinyurl.com/5nnh8) In file included from ../libs/optional/test/optional_test_inplace.cpp:22: /boost/head-regression/boost/boost/utility/typed_in_place_factory.hpp:15:52: boost/detail/in_place_factory_prefix.hpp: No such file or directory /boost/head-regression/boost/boost/utility/typed_in_place_factory.hpp:54:52: boost/detail/in_place_factory_suffix.hpp: No such file or directory Date: 2004-09-23 04:40 Looks like a result of incomplete/inconsistent checkin. Fernando? -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

RE: [boost] Re: C++ GUI - another view
by Reece Dunn 23 Sep '04

23 Sep '04

Matt S Trentini wrote: >John Torjo wrote: > >>Could you elaborate a bit? What do you think is the window handle limit >>under win32? > >I think that perhaps Mathew is talking about the GDI object limit. At >least under Windows 2000 and earlier versions (I'm not sure about XP) there >is a firm limit of 16K handles that can be allocated system wide - >regardless of your particular specs (ie adding memory does not help). When >this limit is reached weird stuff [1] happens which can only be fixed by a >reboot. > >Any object that allocates a handle under Windows (pens, brushes, dc's, etc) >consume those resources and if you've got a graphically intense GUI using a >greedy GUI library (ie one that holds it's handles for a long duration) >that limit isn't too hard to break. Wouldn't you process the pen objects, etc. when handling the drawing event. Instead of storing a pen handle for each line (which IMHO is overkill), you would do something like: namespace gdi = boost::gdi; namespace colors = boost::gdi::colors; namespace units = boost::units; void draw( gdi::canvas & c ) { gdi::pen mypen( colors::lightskyblue ); gdi::font myfont( "Times New Roman", units::picas( 12 )); c.set_units( units::picas ); c.attach( mypen ); c.attach( myfont ); c.set_color( colors::red ); c.draw_string( 1, 1, "Hello World!" ); // uses myfont + colors::red c.line( 10, 10, 10, 15 ); // uses mypen c.line( 10, 15, 15, 15 ); // uses mypen c.line( 10, 10, 15, 15 ); // uses mypen c.attach( gdi::default_pen( colors::red )); // ... } Likewise, with the component framework (windows, widgets), it should be possible to implement windowless components that do not have a handle attached to them. This would be useful when implementing the layout managers. Handling an event should not be bound to the component that generates them. For example, MFC provides handling the exit message on the application object and not the main window object. This would then allow you to bind events to a graphical object without using a window handle. IMHO, line information should be separate from its colour, thickness, etc. Otherwise, you would need to do something like: class line_object { private: unit x1, y1, x2, y2; gdi::pen * pen; public: void draw( gdi::canvas & c ) { c.attach( *p ); c.draw_line( x1, y1, x2, y2 ); } }; which wastes a call to attach the pen each time. This is especially bad if you have 1000s of lines (e.g. drawing a hilbert curve or serpinski's triangle fractal with a fractal depth of 4 or more). Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

[Boost-bugs] [ boost-Bugs-1033370 ] atomic_count_gcc.hpp does not compile on cygwin gcc 3.3.3
by SourceForge.net 23 Sep '04

23 Sep '04

Bugs item #1033370, was opened at 2004-09-23 16:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1033370&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Latoshek (forester22) Assigned to: Nobody/Anonymous (nobody) Summary: atomic_count_gcc.hpp does not compile on cygwin gcc 3.3.3 Initial Comment: this operator long() const { return __exchange_and_add(&value_, 0); } causes error because on cygwin __exchange_and_add() is declared as: static inline _Atomic_word __attribute__ ((__unused__)) __exchange_and_add (volatile _Atomic_word *__mem, int __val); value_ must be made mutable or cast must be added in operator long() const. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1033370&group_… ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0