Diary of a CrazyFrench

Ross, now one needs to integrate that to Gnome, totally. That and your XICC and we can have the display calibration handled in standard way.

For those who wonder about the Spyder2 color calibration hardware support, please read this. Sad. Very sad.

Dalibor comment on the Android SDK licensing. And Paul open questions about the announcement of Open Handset Alliance.

Happy to see that I'm not the only one thinking about that. I believe more in GMAE, and OpenMoko intents, as well as Nokia's, are much clearer.

I ran into a limitation of Glibmm while using std::for_each() with boost::bind() and Glib::RefPtr<>.

boost::bind() works well with any of the Boost.SmartPointer, or with raw pointers, but not with Glib::RefPtr<> as it lack the get_pointer() function.

I tried to do this:

Glib::RefPtr<Foo> foo;
std::vector<Bar> v;
/* ...initialize foo and v */
std::for_each(v.begin(), v.end(), 
	boost::bind( &Foo::do_something_with_bar, foo, _1 );

But it failed to compile as I was missing the function below.

namespace Glib {
/** Dereference Glib::RefPtr<> for use in boost::bind */
template< class T_CppObject >
T_CppObject *get_pointer(const Glib::RefPtr< T_CppObject >& p)
{
	return p.operator->();
}
};

Some explanations: the function is templated to work with any instance of Glib::RefPtr<>. It is in the the Glib namespace, and will be looked up naturally by the Koenig lookup which in principle allow looking the function up in the same namespace that the argument is in. It uses this ugly operator->() member call because there is no other way to get the raw pointer from the Glib::RefPtr<>, but this is an implementation detail.

Filed bug 495762. Adding it to Glibmm will not break the ABI as it is not a method, and it is a template function, hence instantiated locally. Maybe it could be maybe inline.

The above code is either under the same license governing Glibmm which is LGPLv2+.

"GNOME is attractive to some seasoned Linux users because it one of the few complete desktop environments that is more lightweight than KDE, which makes GNOME more appropriate for use on servers." -- Nicholas Petreley, November 1st 2007

Mr Petreley, you are the reason why I did not renew my subscription to Linux Journal and stopped reading the only dead-tree magazine I considered worthwhile. Not that its content was less good, just that your rants as Editor in Chief were always missing the point.

That was last year.

The question today would be: What would a desktop environement, whether it is KDE, Gnome or any other, have to do on a server? Beside wasting resources. I think it is time for you to stop writing about Linux and start using it.

OK, now I put away the rotten tomatoes.