Re: [boost] GUI/GDI template library
>The confusion is that your interpretation (more >traditional) of a modern GUI framework is a bit >different from notus. We are not concerned with >building low-level controls. The low-level >implementation is basically proveded by the platform >(Mac, win32, etc.). Notus is just going to be using >it. Notus's objective is exaclty to connect the >'real-world' data (STL containers, etc) to the >low-level GUI. In fact, the data-GUI connection and >data/GUI management policies IS a low-level for notus, >below is just a presentation layer. Traditional GUI >toolkits are mostly concerned with the presentation >level, notus is not! (well to a degree) > Maybe you're thinking just too low level ;) Just think of you wanting to provide a grid. As Brock put it, you'll use row()/ col()/ or whatever to build that. That's just presentation. Or, you want a three-state button (pushed/ not-pushed/ disabled). You first have to allow for that (presentation), then you can think about linking to some data (like, if i < 0 -> not-pushed i > 0 -> pushed i = 0 -> disabled) After you have that in place, you can think about data. (but that's just my .02 Euros;) ) Best, John >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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: bind/lambda - unsupported use case?
Brian McNamara <[EMAIL PROTECTED]> writes: > I can't speak for bind/lambda, although I imagine there must be a way, > probably involving delaying the evaluation of _1 for one step. > > Using FC++, it would be > >using fcpp::fun1; >using fcpp::lambda; >using fcpp::ptr_to_fun; >fun1 f = > lambda(X)[ ptr_to_fun(post_command)[ > lambda()[ ptr_to_fun(show_warning)[ message_dialog(), X ] > ] ] ]; > > The explicit lambda notation makes it easier to (mentally and > syntactically) sort out functions like these where the placeholder > variables are bound by a lambda (bind expression) other than the > innermost one. > > (The calls to to ptr_to_fun above are necessary only to promote the > function pointers into FC++ "functoids".) Yep, the lambda(X) is nice because it shows where the argument is going to be used. However Peter Dimov's original post was correct, bind/lambda "protect" or lambda's "unlambda", would do the same. The issue being keeping _1 from being evaluated until later. -Gary- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
automating registering of events (was: Re: [boost] GUI/GDI templatelibrary)
Eugene,
one more thing when you implement the GUI library.
I ALWAYS hated the message maps from MFC/WTL.
So now I came up with a quite cute method of automating registering of events for a
given window.
(this should work for registering messages, etc.)
It's very flexible. In other words, when you add an event for wnd_widget,
it does not couple the header file wnd_widget.h to the resource file (think MFC
for a moment ;) ) So, in case you modify the ID of a resource, all
you have to do is recompile the source file (wnd_widget.cpp), not the whole files
depending on wnd_widget.h.
So, lets get down to it:
Here's how to register an event for window test:
// test.h
class test : public wnd< test> {
public:
event_base on_ok();
};
// test.cpp
#include "resource.h"
test::event_base test::on_ok() {
// [do whatever you like to handle the event]
// this is how we say that on_ok should handle the ID_OK event
//
return event< ID_OK, &test::on_ok>();
}
P.S. you have no idea how many workarounds/ twists I had to do to make this compile on
VC6 !!!
---
#include
#include
template< class initializer_class>
struct wnd_initializer {
struct init {
init() {
initializer_class::do_initialize();
}
};
static init s_init;
};
template< class initializer_class>
wnd_initializer< initializer_class>::init wnd_initializer< initializer_class>::s_init;
template< class wnd_class>
struct wnd {
struct event_base;
typedef event_base (wnd_class::*func)();
// ... prevent wnd_event_base from being constructed directly
struct event_base {
protected:
event_base( int id, func f, void* )
: m_id( id) {
}
public:
event_base( const event_base& other)
: m_id( other.m_id){}
private:
int m_id;
// VC6 chokes on this
//func m_f;
};
private:
template< int id, func f>
struct event_initializer {
static void do_initialize() {
wnd< wnd_class>::s_events.add_event( id, new func_wrapper());
}
};
protected:
template< int id, func f>
struct event
: public event_base,
private wnd_initializer< event_initializer >
{
typedef wnd_initializer< event_initializer > initializer;
event() : event_base( id, f, (void*)&initializer::s_init) {
}
};
private:
// keeping the member function pointers as data members
// (example : struct keeper { func m_f; }) makes VC6 choke
struct func_wrapper_base {
virtual void call_event( wnd_class *) const = 0;
};
template< func f>
struct func_wrapper : public func_wrapper_base {
virtual void call_event( wnd_class *p) const {
(p->*f)();
}
};
public:
// contains the events for this window
struct events_for_wnd {
typedef std::map< int, func_wrapper_base*> events_coll;
void add_event( int id, func_wrapper_base * f) {
m_events[ id] = f;
}
const events_coll & get_events() const {
return m_events;
}
void call_event( int id, wnd_class * p) const {
typedef typename events_coll::const_iterator const_iterator;
const_iterator found = m_events.find( id);
if ( found != m_events.end() )
if ( p != 0)
found->second->call_event( p);
}
~events_for_wnd() {
std::for_each( m_events.begin(), m_events.end(), do_delete);
}
private:
static void do_delete( const std::pair< const int, func_wrapper_base *> &val) {
delete val.second;
}
private:
events_coll m_events;
};
static events_for_wnd s_events;
};
template< class wnd_class>
wnd< wnd_class>::events_for_wnd wnd< wnd_class>::s_events;
// test.h
class test : public wnd< test> {
public:
event_base on_ok();
event_base on_cancel();
event_base on_apply();
};
// test.cpp
#include
#define ID_OK 1
#define ID_CANCEL 2
#define ID_APPLY 3
test::event_base test::on_ok() {
std::cout << "ON OK event called" << std::endl;
// this is how we say that on_ok should handle the ID_OK event
//
return event< ID_OK, &test::on_ok>();
}
test::event_base test::on_cancel() {
std::cout << "ON CANCEL event called " << std::endl;
// this is how we say that on_ok should handle the ID_CANCEL event
//
return event< ID_CANCEL, &test::on_cancel>();
}
test::event_base test::on_apply() {
std::cout << "ON APPLY event called " << std::endl;
// this is how we say that on_ok should handle the ID_APPLY event
//
return event< ID_APPLY, &test::on_apply>();
}
int main(int argc, char* argv[])
{
test t;
typedef test::events_for_wnd::events_coll coll;
const coll & events = test::s_events.get_event
[boost] Overriding LD_LIBRARY_PATH
I am trying to compile Boost against the uClibc libraries. This requires that I define a custom value for LD_LIBRARY_PATH, so that my uClibc libraries are used instead of the standard system libraries. The problem I have is that building Boost.Python generates its own LD_LIBRARY_PATH definition that points to my Python library directory only. This results in the following unpleasant result: ldd libboost_python_debug.so.1.30.0 libc.so.6 => /lib/i686/libc.so.6 (0x40022000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x) libm.so.0 => /usr/uclibc/lib/libm.so.0 (0x) libgcc_s.so.0.9.9 => /usr/uclibc/lib/libgcc_s.so.0.9.9 (0x) libc.so.0 => /usr/uclibc/lib/libc.so.0 (0x) libm.so.6 => /lib/libm.so.6 (0x) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x) libc.so.6 => /lib/libc.so.6 (0x) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x) Note that BOTH glibc and uClibc libraries have been linked against. If I manually copy the very long line that builds the libboost_python.so file and run it under my environment, it links correctly, but I cannot force jam to do what I want. My question is : How do I stop this internal value for LD_LIBRARY_PATH being set? I've tried every environment variable I can think of. My system is a Mandrake 9.1 base. I'm running Python 2.2.3 compiled against uClibc & I'm using the uClibc toolset based on gcc 3.2.3. Everything else compiles and links well. I have an embedded system running this version of Python & it's very happy. Boost is my one remaining problem. Here is my setup file: export PYTHON_ROOT=/usr/uclibc/usr export GCC_ROOT_DIRECTORY=/usr/uclibc/ export GCC_BIN_DIRECTORY=/usr/uclibc/i586-linux/bin/ export GCC_STDLIB_DIRECTORY=/usr/uclibc/lib export CPATH= /usr/uclibc/i586-linux/include:/usr/uclibc/i586-linux/sys-include:/usr/uclibc/lib/gcc-lib/i586-linux/3.2.3/include:/usr/include export CPLUS_INCLUDE_PATH= "/usr/uclibc/usr/include/python2.2:/path-to-Boost/boost:/usr/uclibc/include/c++:/usr/uclibc/include/c++/i586-linux:/usr/uclibc/include/c++/backward:/usr/include" export LD_LIBRARY_PATH=/usr/uclibc/lib:/usr/uclibc/usr/lib/python2.2/config bjam -d2 -q ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [regex] Escaping a search string?
George A. Heintzelman wrote: Given that I have a string 's' from somewhere, I'd like to create a regular expression where some part must match that string. The problem is, the 's' could contain characters that have a special meaning in regular expressions. Is there some support function that can provide an escaped version of 's'? Something that transforms "my.*string" into "my\.\*string"? If there isn't, would it be possible/easy to provide one? Second that request. I just had a need for this, though I wound up ignoring the problem rather than fixing it... There must be something in the air; I just had a need for this too. My quick-and-dirty solution was to simply replace every non-alphanumeric character with a hex escape sequence (\xNN). Having it just add escapes to a list of special characters wouldn't work as a general solution, because the list of characters depends on the flags passed to the regex functions. Of course there are settings where my hex-escape solution won't work either. I don't think a general solution is possible without making it part of the library; it needs access to the innards of the regex objects in order to know the exact syntax they recognise. -- Ross Smith .. Pharos Systems, Auckland, New Zealand "Remember when we told you there was no future? Well, this is it." -- Blank Reg ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Support for gcc-2.95 in 1.31
David Abrahams wrote: Martin Wille writes: Hello, a couple of libraries are regressing for gcc-2.95.3/Linux: date_time graph iterator multi_array numeric/interval numeric/ublas (only with stlport) random variant Are those libraries supposed to support gcc-2.95? iterator is. I think graph is also. Where are you posting these results? I see no 2.95 regressions at http://boost.sourceforge.net/regression-logs/cs-Linux-rc-1_30_0/developer_summary_page.html That is for the RC_1_30_0. The results for CVS HEAD can be found at: http://boost.sourceforge.net/regression-logs/cs-Linux/developer_summary_page.html Regards, m PS: The number of messages with "1.31" in the subject line but discussing the 1.30.2 release is confusing. I suggest to change the subject when continuing the respective threads. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: GUI sublanguage ?
"Brock Peabody" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Because for a pretty large number of applications you can really
> simplify your code a lot by relying on the GUI system to 'do the right
> thing':
>
>using boost::gui;
>
>void my_action() {...}
>void progress_action(int tick) {...}
>
>gui::show( "sample boost application",
> column ( button ("click it", &my_action),
>progress (100, &progress_action)));
>
>
> There are a lot of good reasons why we would not always want to have
> total control.
"Not always" means "sometimes not" ?
According to this logic your gui language is
layer built on top of interface proposed by me
... just for convenience. Right ?
> I want my applications to be as simple as possible, and
> to all look the same.
Generally GUI applications are semantically complicated.
Forget about "universal cure" from this. Everithing you can
do is to symplify development in some cases.
> If the GUI library picks the 'best' settings for
> the platform automatically, the individual programmer doesn't have to
> think about it. Everything just works like it should. To take a few
> things from your snippet that are suspect to me:
>
> > w.width( 400 );
> > w.height( 200 )
>
> Where do 400 and 200 come from? This seems arbitrary to me. The GUI
> system should be able to tell how to size itself.
Have you invented universal algorithm for window size/position ?
>
> > b.align( alignment::vcenter | alignment::hcenter );
>
> A real world application needs much more sophisticated positioning
> mechanisms than this. The tiny snippet above (in my code) hides some
> pretty good positioning logic.
Don't be boring, this is just simple example ... without details in mind.
"sophisticated positioning mechanism" can be implemented by
control/window class methods too. Even more, such interface allows
changing behavior in runtime.
>
> > pb.min( 0 );
> > pb.max( 100 );
> > pb.step( 5 );
> > pb.smooth( true );
>
> Again, these values should be picked automatically.
Only if you are satisfied by default values. Believe
me, this is very rare situation. Especially for "progress bar"
control :))
>
> Now, it might be cool to be able to change my above code to:
>
> gui::show( "sample boost application",
> ...
Generally runtime gui styles (flat, 3d ...) can be more helpful, because
changing look-and-feel in "application options" is very frequent situation
for serious GUI applications. Please don't be too obsessed by compile
time, it is not very good way for GUI toolkit.
> Where you can have specified such things as whether or not your progress
> bars are smooth and what the step size is. Maybe you could even do it
> at run-time.
>
> get_my_company_gui_traits().show("sample boost application",
> ...
>
> My motivation for the design of this again:
>
> - GUI code is difficult, tedious, and error prone even for simple tasks,
> I want to make it simple (for simple tasks)
Agree! But only for simple tasks.
Now things are clear. My conclusion is following :
1. Such interface is ok for no-so-compicated gui and/or controls.
I mean situations when you are satisfied by default values
for properties or properties differ from default ones not so much.
2. It should be implemented on to of more functional, runtime,
interface ( used in most gui libs).
>
> - control positioning is especially difficult
If you mean MFC or pure win32, most probably it is true. But don't
forget there are a lot of other GUI libs around which can handle this
problem without significant problems.
>
> - Consistency in GUI applications is difficult. Give ten programmers a
> lower level GUI API and they'll turn out ten applications each with a
> different look and feel. I don't want to have to remember that step
> size for our company is always '5', for instance.
Interface proposed by me can and should have default values as well.
> If we head in the direction we've been talking we would also provide a
> cross platform lower level API where you could get more control and do
> things like what you describe below. I hope that most programmers would
> find it unnecessary though.
IMHO this interface is must.
regards,
bohdan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.31 release?
Douglas Paul Gregor <[EMAIL PROTECTED]> writes: > On Mon, 11 Aug 2003, David Abrahams wrote: >> According to your chart, the following libraries are all regressing: >> function >> >> Are these real regressions or just newly-tested compilers? Can the >> library authors/maintainers address these problems? Where is our >> maintenance wizard? > > All of the failures for function are due to newly-tested compilers. Misha and Aleksey -- I think we really need to distinguish those failures from real regressions in the chart somehow or we'll never be able to tell where we stand. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Alisdair Meredith wrote: > Aleksey Gurtovoy wrote: > > > While I totally support the failures markup goal, I would like to see > > _the_ release criteria to include "no regressions from the previous > > release" item as well, preferrably for all non-beta compilers that are > > currently under regression testing. Especially since now we have tools > > to ensure it. > > OTOH, it might not always be achievable. > For boost 1.31 we are having an interface breaking change to the > iterator_adaptors, and not all compilers pass all tests with the new > adaptors yet. > > While this may not be a problem for the iterators library (it is > effectively new) Yes. > it may have a knock-on effect on any other boost libraries implemented > on top of it. And any failures concerned with the interface change per se should be fixed before the release. It might happen that major changes in a library inadvertently cause _functionality regression_ on the particular compiler, but IMO "inadvertently" is a key word here. > > The principle is a good one, but I be prepared to make a few allowances > in the practice. Sure, as long as it's an explicit decision. After all, those could be put in the release notes. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
Beman Dawes wrote: > At 07:37 AM 8/11/2003, David Abrahams wrote: > >Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > > >> Beman Dawes wrote: > >>> Assuming I'm release manager for 1.31.0, I'm going to publish explicit > >>> release criteria for key platform/compiler pairs. Basically, the > >>> criteria will be 100% accounting for all failures on those > >>> platform/compiler pairs. > >> > >> While I totally support the failures markup goal, I would like to see > >> _the_ release criteria to include "no regressions from the previous > >> release" item as well, preferrably for all non-beta compilers that are > >> currently under regression testing. Especially since now we have tools > >> to ensure it. > > > >I worry a little about requiring library authors not to regress on > >compiler combinations they don't test with. For example, who is going > >to address the one lexical_cast failure that's plaguing the 1.30.2 > >release? It's only on intel-7.1 with STLPort and looks for all the > >world like a config problem. > > It can be very time consuming to track down the exact reason for failures. > Thus we should focus our 1.31.0 effort on a small number of widely used > compilers which don't have a lot of problems. It doesn't have to be the release manager who investigates all the issues himself, though. There might be enough of the interested parties with motivation/resources to resolve most of these in a reasonable time frame if they a given a chance/"managed" properly. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
--- Joel de Guzman <[EMAIL PROTECTED]> wrote: > E. Gladyshev <[EMAIL PROTECTED]> wrote: > > Since GTL is already taken, how about GTF (GUI > > Template Framework)? > > Can't we be more imaginative than that? Aren't we > all > already saturated with acronyms and acronyms and yet > more > acronyms? There is no policy anyway that forces us > to use > acronyms in boost. > > When Spirit was being reviewed, I was a bit afraid > that someone > would come out and suggest that it be named as BPL. > Akkk! > Fortunately, no one did. And after all, BPL already > stands for > boost python library. > > In the world of computers, it is already a sea of > acronyms. > IMO, acronyms are ugly! This is my opinion of > course. I > am entitled to my own opinion right? :-) Of course you are. ;) I'd like a normal name too. All these acronyms are just very easy to come up with. I've been lazy. ;) Don't know where to start... Greek and Roman mythology? 'Aquilo' the north wind, the ruler of the winds. 'Notus' the south wind 'Flora' goddess of flowers and spring. 'Arcadia' a district of the Peloponnesus, the home of pastoral simplicity. 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: Boost 1.31 release?
At 01:39 PM 8/8/2003, Martin Wille wrote: >In order to avoid problems to be discovered too late for fixing them >I'll list the tests that fail for many compilers/compiler versions >on Linux: > >- filesystem::operations_test Hum... That looks like a CVS problem. It looks like boost-root/libs/filesystem/src/operations_posix_windows.cpp has not been updated to 1.15. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Release date? (was the boost::signal sample crashes)
At 08:00 AM 8/11/2003, John Maddock wrote: > >> I'm not sure how to proceed with this so if there is anything I can do >> in the meantime, let me know. Feel free to e-mail me off the list. > >OK, I've got this working pretty well with regex - but as it entails >changes >to boost.config I'm not sure if I should make the changes now or wait until >after the next release - Beman I guess we have a couple of weeks still to >run yes? Yes. Target dates haven't been set yet, so you should be OK. > >[ Footnote - on second thoughts it just means moving code that's in >boost.regex now into the central config system it's not new code - so maybe >I should go ahead ] Yes. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
>
> http://lists.boost.org/MailArchives/boost/msg46513.php
>
> indicating some interest in combining thread safety and
> decoration. It seems to me (a novice in threading) that
> what needs to be protected is the access to the end
> of the pipeline, i.e. the final streambuf, which is
> connected to the actual output medium (a file, or console or
> pipe). Hence, I'm wondering if it's a good idea to
> combine the two in a ostream class. I confess I haven't
> looked at your code, but I think it would be nice if
> somehow it could be streambuf thread safety could be separated
it is, in the library I developed.
It's quite cute and efficient too ;)
Unfortunately I haven't had time to do the docs, since other stuff
too over.
Maily, SMART_ASSERT - which I want to finish the docs for ;)
and then I want to create a wingui.
And I have a job also ;)
But, if there's interest in it, I'll make some time.
Otherwise, it'll wait a couple more months :(
Best,
John
> from the {o,i}stream features which are only concerned with
> formatting. Does that make sense?
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost 1.31 release?
[2003-08-11] David Abrahams wrote: >Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > >> Well, sure, as long as we are in agreement about having differently >> named toolsets for different compiler versions/configurations, e.g. >> >> bcc-5.5.1 >> bcc-5.6.4 >> intel-7.1-vc60 >> intel-7.1-vc60-stlport > >It's OK with me. I'd rather that they have the same root as the base toolsets... borland-5.5.1 borland-5.6.4 intel-win32-7.1-vc60 intel-win32-7.1-vc60-stlport Makes for easier maintenance. -- 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: RC_1_30_2 tagged for release
David Abrahams wrote: Martin Wille writes: The fix made to the gcc toolset regarding the use of the GXX variable should be backported to 1_30_2. Please be more specific, i.e. post a patchset. If I had a patchset then I would have applied it :) (I sent a bug report some time ago to the JamBoost list. Rene fixed the issue immediately) I'll look into this on sunday. Regards, m ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
