Re: hal++ announcement

["Milosz Derezynski" <internalerror gmail com>]

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 <nowhere man levallois eu org> 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
--
nowhere man levallois eu org
OpenPGP 0xD9D50D8A


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFaPyfxe13INnVDYoRAl4kAJ9u47w6HjHkOEDxH/I3j1++aqhEKACeLNL9
USeHkcHbsU94QFRMNT2CAHY=
=fqKo
-----END PGP SIGNATURE-----