GNOME Bugzilla – Bug 691389
Update libnotifymm to wrap libnotify 0.7.5 and use mm-common
Last modified: 2013-02-15 19:18:14 UTC
This is not a gtkmm bug. It's a libnotifymm bug, but I can't find a suitable place for such a bug in bugzilla. This bug is the continuation of a discussion on gtkmm-list. https://mail.gnome.org/archives/gtkmm-list/2013-January/msg00007.html Phong Cao has downloaded libnotifymm-0.6.1 and updated it to make it compatible with libnotify-0.7.5. His updated version is here: http://www.mediafire.com/?qo17ojs7v9ke774 As I mentioned on the gtkmm-list, I plan to do two things with libnotifymm. 1. Push Phong Cao's changes to the git repository. 2. Make libnotifymm use mm-common, as most mm packages do. I'm not familiar with libnotify[mm], and I will have questions to Johannes Schmid and Phong Cao. I will use this bug for those questions.
Created attachment 233086 [details] Diff between Phong Cao's libnotifymm-0.7.5 and libnotifymm-0.6.1 These are the differences between Phong Cao's libnotifymm-0.7.5 and libnotifymm-0.6.1 downloaded from http://ftp.gnome.org/pub/GNOME/sources/libnotifymm/0.6/libnotifymm-0.6.1.tar.gz The attachment contains only differences in files that are stored in git. Generated files are excluded. Modified files -------------- configure.ac Makefile.am Only a deleted extra space examples/Makefile.am examples/status-icon/ Deleted directory libnotify/libnotifymmconfig.h.in *) libnotify/src/libnotify_methods.defs libnotify/src/libnotify_signals.defs libnotify/src/notification.ccg libnotify/src/notification.hg tools/extra_defs_gen/generate_defs_libnotify.cc tools/m4/convert_libnotifymm.m4 tools/m4/convert.m4 *) - tarball 0.6.1 does not contain autogen.sh. - 0.7.5 contains an autogen.sh which is very different from the one in git. It calls autoheader. Autoheader generates a libnotifymmconfig.h.in which is very different from the one in 0.6.1 and git. - git contains an autogen.sh that does not call autoheader.
@Kjell: I think we will need an almost redone with libnotifymm, not just modifying the existing 0.6.1. The reason that I deleted the status-icon folder was that in libnotify 0.7.5 the API no longer requires status-icon to construct NotifyNotification.
I have pushed a first commit to the master branch in git: http://git.gnome.org/browse/libnotifymm/commit/?id=70a2dac8e9c569ad256cc438a8432e5124b3a005 This commit contains approximately Phong Cao's modifications, but I had to make some changes to be able to build libnotifymm. Now the first bunch of questions: - examples/widget/test-window.cc contains a call to the deleted method attach_to_widget(). Is this example worth keeping? I suggest that we delete both examples/widget/ and examples/status-icon/. - What is the debian/ directory good for? There are no similar directories in other mm packages. If it must be kept and updated, I hope someone else will do the updating. - The new release of libnotifymm will break both ABI and API. Therefore the name libnotifymm-1.0 in installed directories and files shall be changed, shan't it? To libnotifymm-2.0? The next step will be to have libnotifymm use mm-common. That will simplify future maintenance. It means changing autogen.sh, configure.ac, all Makefile.am, and some other files. It's not as difficult as it may sound. I can copy most files from http://git.gnome.org/browse/mm-common/tree/skeletonmm and make small changes to the copies.
I am currently a bit busy but I will have a look at this ASAP.
I have pushed two more commits. Transition to the mm-common build system: http://git.gnome.org/browse/libnotifymm/commit/?id=7344542d24644c7d8e6a78ae66ca46126843e559 Miscellaneous small fixes: http://git.gnome.org/browse/libnotifymm/commit/?id=33545e75c4494165a18a5398c53e8ab9722001b0 I will probably stop here and wait for comments on my questions, or other comments. More questions: - The documentation of Notify::uninit() says that it's called automatically on exit. I doubt that. If it's true, it must be done in a destructor. There is only one class in libnotifymm: class Notify::notification. Its destructor does not call uninit(), and it would probably not be the right place for such a call. Is it important to call uninit()? The example programs don't call it, and they seem to work correctly. - The libnotify package does not depend on gtk+ any more, but it does depend on gdk-pixbuf. (libnotify's example programs depend on gtk+, but the library does not.) libnotifymm still depends on gtkmm. It would probably be possible to make it independent of gtkmm, but it's complicated by the fact that gtkmm is the C++ binding of both gdk-pixbuf and gtk+. Would a continued dependency on gtkmm be a nuisance to users of libnotifymm? If you build the latest version from the git repository and want to study the generated reference documentation, I recommend using doxygen 1.8 in the build. Doxygen 1.7 contains a rather serious bug. The generated html files contain erroneous paths to the stylesheet file. The web browser does not find the stylesheet, and uses its default styles. That looks bad, at least in Firefox.
@Kjell: libnotify does not depend on gtk+ but glib, since it uses GVariant for some of its functions. I think it is not bad to let libnotifymm depends on gtkmm. I mean if you're using libnotifymm you're probably using some other mm's already in your system. http://developer.gnome.org/libnotify/0.7/NotifyNotification.html#notify-notification-set-hint About the Notify::uninit(): Although the example programs do not call it, I usually call notify_uninit() on my projects on destruction of objects. I think it would be better to let the users uninit() when they want, instead of having to destroy the Notify::Notification. You can either let the uninit() a static method in Notify::, or make it protected so users can subclass it.
(In reply to comment #4) > I am currently a bit busy but I will have a look at this ASAP. Johannes, are you still busy? I don't mean to push you, I'm just curious.
Looks good to me. I have the "dist" build and uploaded libnotifymm 0.7.0 to the ftp server. Thanks for your patience!