In fact i was thinking of abstracting the singals out of the core libhal++ library so it could be optionally used with Qt signalling, etc, to make it also work well for Qt/KDE guys, just that after a talk with Thiago (Maciera, up-to-recently, but-ex Qt4-DBus developer) they kinda discouraged me from it citing that there would be even not much use for it. i however personally have not given up the idea, right now i first need to consolidate the base library first.
The 0.50 release reduced the footprint/usage of libhal and this hald massively, and i still need to iron a few things out. After that i can see what is possible although the library comes from a sigc++ development environment (i mean, BMP is developed using gtkmm which uses sigc++ in turn), so it was more natural for me to start with sigc++. I'v also planned at some stage an addon library using boost, libhalcc-boost, which would make a few things less borked and less obfuscated to use than they are in the base library (stuff like reading all of the properties into an std::map of variants, and as for variants, the probably safest way in terms of proven code is boost). However going with that i don't want to add too many dependencies to the base lib itself nor do i want to directly impose API onto people for stuff they might figure a better way for, or one that suits them better, i don't want to include boost stuff into halcc itself (we use boost a lot in BMP, but this situation is different; it's not like i don't like boost, it's just about keeping the library rather slim). I'll let the list know about major changes/additions to the library (so far no one except for you seems to be interested however i'll still keep posting :P) Should i CC you directly? Milosz On 11/26/06, Pierre THIERRY <[EMAIL PROTECTED]> wrote:
Scribit Milosz Derezynski dies 21/11/2006 hora 21:50: > I'd like to announce libhal++, a C++ wrapper for libhal, and > libhal-storage. It does not require glibmm nor gtkmm (although there > are tests in the dist which can make use of the glib mainloop), yet it > uses sigc++ to manage the signaling. Mostly for curiosity and a bit for proselytism, did you consider using another library to manage signals? I used various Boost[1] libraries pretty much, and they are very well designed. Most are a very good balance between power and ease of use. They have a Boost.Signals[2] library that I think gives much more flexibility. Specifically, it doesn't force the user to subclass a particular class. IIRC, any functor could be used as a callback. Would it be possible to use your library with Boost.Signals? Curiously, Pierre [1] http://boost.org/ [2] http://boost.org/doc/html/signals.html -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFaPyfxe13INnVDYoRAl4kAJ9u47w6HjHkOEDxH/I3j1++aqhEKACeLNL9 USeHkcHbsU94QFRMNT2CAHY= =fqKo -----END PGP SIGNATURE-----
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
