We released some extra C++ bindings recently:
gtksourceviewmm-2.0
I updated Dodji’s gtksourceviewmm to wrap the new gtksourceview-2.0 API. Here’s the svn, and the tarball download.
libnotifymm and hildon-notifymm
Johannes Schmid created libnotifymm (svn, tarball) to wrap libnotify, and we also wrapped Maemo’s hildon-notify, though there’s no documentation to say what this does beyond regular libnotify. I suspect that Maemo should just use a port of libnotify without requiring use of special API.
There are lots of examples in the libnotifymm source code. It seems quite simple, and particularly useful for code that uses Gtk::StatusIcon.
Hei Murray, hildon-notify is wrapper around libnotify that adds support for dbus callbacks on notification actions. I’m still discussing with Christian how to add this to libnotify. Documentation will come soon. :-)
Lucas, what are “notification actions”. Is that something that happens in response to a click on a notification window, or something similar?
Yes, In notification-daemon terms (the one used in GNME), it’s what happens when you click on one the actions buttons that appear in the notification bubble. In hildon terms, we only have only support one default action (which is activated when you click in the notification).
Currently, libnotify only supports client-side callbacks for those actions. hildon-notify just adds support for D-Bus callbacks. The problem is that the implementation I did is (kind of) a hack. But I haven’t found a better way to implement this in a sane way in libnotify yet.
I do not think that this is your fault, but I am not very happy about the gtksourceview (and gtksourceviewmm) 2.0 API.
Namely, I do not like that the source markers got dropped (because gedit does not use them?).
I have been using gtksourceviewmm since it’s freshmeat.net days… breaking backwards compatibility is always a bad idea. Say what you want about Windows, but I can still write apps in 2007 based on what I learned from Petzold’s book when I read it back in the mid 90’s.
> I do not like that the source markers got dropped.
Apparently it didn’t work very well. They plan to do it properly in the future.
> breaking backwards compatibility is always a bad idea.
The gtksourceviewmm (and gtksourceview) 1.0 version installs in parallel. You can keep using it.
> The gtksourceviewmm (and gtksourceview) 1.0 version installs in parallel. You can keep using it
That is true, but the point here is that (at least with the new opensuse10.3) the “broken” version installs by default, and the user has to go out of his/hers/its/ way to fix the issue (i.e. install the 1.0 API).
Also with opensuse10.3 I cannot get the development package for gtksourceview-1.0 simply by running the software management tool. I have to go to their online repository and download and install manually.
I realize that this is specific to one vendor but it just goes to show how the effects of one not-so-good design from one community get amplified by another group’s or vendor’s less-than-perfect decision
And as I noted elsewhere, after this first-hand experience I can understand much better how these things lead to people getting frustrated about Gnome (because it is the brand that like it or not encompasses all modules).
Again, I know it is not your fault but as a voice in the Gnome community maybe you cann pass these concerns on.
Best regards.
> with the new opensuse10.3) the “broken†version installs by default,
I don’t believe that SUSE ship gtksourceviewmm at all. I guess you mean gtksourceview.
> and the user has to go out of his/hers/its/ way to fix the issue (i.e. install the 1.0 API).
Users don’t knowingly install APIs.
> Also with opensuse10.3 I cannot get the development package for gtksourceview-1.0 simply by running the software management tool. I have to
> go to their online repository and download and install manually.
We are not responsible for SUSE’s mistakes. I can recommend Debian or Ubuntu, though they are not perfect.
> it just goes to show how the effects of one not-so-good design from one community get amplified by another group’s
Many decisions are a choice between competing priorities. Doing one thing is often preferrable to the downside of not doing it. In this case, I guess the downside was of shipping an API that could not be supported. You’d feel cheated if you used an API that was known to be broken.
If you are interested in this particular API, please contact the maintainers so you can learn what the actual issues are and maybe help to get the feature ready.
> I can understand much better how these things lead to people getting frustrated about Gnome
Sorry, I think that’s nonsense.