GNOME Bugzilla – Bug 591304
libgnomecanvas heavily depends on libart_lgpl
Last modified: 2014-08-02 12:52:45 UTC
So *if* Evo wants to keep using libgnomecanvas for GNOME3: libgnomecanvas drags in libart_lgpl which is deprecated too. $:andre\> cd libgnomecanvas/ $:andre\> grep -r libart . ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_misc.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_rect.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_vpath.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_bpath.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_vpath.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_vpath_bpath.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_svp.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_svp_vpath.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_rect_svp.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_gray_svp.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_svp_intersect.h> ./libgnomecanvas/gnome-canvas-clipgroup.c:#include <libart_lgpl/art_svp_ops.h> ./libgnomecanvas/gnome-canvas-rect-ellipse.c:#include "libart_lgpl/art_vpath.h" ./libgnomecanvas/gnome-canvas-rect-ellipse.c:#include "libart_lgpl/art_svp.h" ./libgnomecanvas/gnome-canvas-rect-ellipse.c:#include "libart_lgpl/art_svp_vpath.h" ./libgnomecanvas/gnome-canvas-rect-ellipse.c:#include "libart_lgpl/art_rgb_svp.h" ./libgnomecanvas/libgnomecanvas-2.0.pc.in:Requires: libart-2.0 gtk+-2.0 ./libgnomecanvas/gnome-canvas-path-def.h:#include <libart_lgpl/art_bpath.h> ./libgnomecanvas/gnome-canvas-util.h:#include <libart_lgpl/art_svp.h> ./libgnomecanvas/gnome-canvas-util.h:#include <libart_lgpl/art_vpath.h> ./libgnomecanvas/gnome-canvas-util.h:#include <libart_lgpl/art_svp_vpath_stroke.h> ./libgnomecanvas/gnome-canvas-util.h:/* Convert from GDK line join specifier to libart. */ ./libgnomecanvas/gnome-canvas-util.h:/* Convert from GDK line cap specifier to libart. */ ./libgnomecanvas/gnome-canvas-line.c:#include "libart_lgpl/art_vpath.h" ./libgnomecanvas/gnome-canvas-line.c:#include "libart_lgpl/art_svp.h" ./libgnomecanvas/gnome-canvas-line.c:#include "libart_lgpl/art_svp_vpath.h" ./libgnomecanvas/gnome-canvas-line.c:#include "libart_lgpl/art_svp_vpath_stroke.h" ./libgnomecanvas/gnome-canvas-pixbuf.c:#include <libart_lgpl/art_rgb_affine.h> ./libgnomecanvas/gnome-canvas-pixbuf.c:#include <libart_lgpl/art_rgb_rgba_affine.h> ./libgnomecanvas/gnome-canvas-pixbuf.c:/* This is private to libart, but we need it. Sigh. */ ./libgnomecanvas/gnome-canvas-shape-private.h:#include <libart_lgpl/art_vpath.h> ./libgnomecanvas/gnome-canvas-shape-private.h:#include <libart_lgpl/art_svp.h> ./libgnomecanvas/gnome-canvas-shape-private.h:#include <libart_lgpl/art_vpath_dash.h> ./libgnomecanvas/gnome-canvas-shape-private.h:#include <libart_lgpl/art_svp_wind.h> ./libgnomecanvas/gnome-canvas-util.c:#include <libart_lgpl/art_uta.h> ./libgnomecanvas/gnome-canvas-util.c:#include <libart_lgpl/art_svp.h> ./libgnomecanvas/gnome-canvas-util.c:#include <libart_lgpl/art_svp_ops.h> ./libgnomecanvas/gnome-canvas-util.c:#include <libart_lgpl/art_rgb.h> ./libgnomecanvas/gnome-canvas-util.c:#include <libart_lgpl/art_rgb_svp.h> ./libgnomecanvas/gnome-canvas-util.c:#include <libart_lgpl/art_uta_svp.h> ./libgnomecanvas/gnome-canvas-util.c:#include <libart_lgpl/art_rect_svp.h> ./libgnomecanvas/gnome-canvas-util.c: * Convert from GDK line join specifier to libart. ./libgnomecanvas/gnome-canvas-util.c: * Return value: The line join specifier in libart format. ./libgnomecanvas/gnome-canvas-util.c: * Convert from GDK line cap specifier to libart. ./libgnomecanvas/gnome-canvas-util.c: * Return value: The line cap specifier in libart format. ./libgnomecanvas/libgnomecanvas-2.0-uninstalled.pc.in:Requires: libart-2.0 pango pangoft2 gtk+-2.0 ./libgnomecanvas/gnome-canvas-clipgroup.h:#include <libart_lgpl/art_bpath.h> ./libgnomecanvas/gnome-canvas-clipgroup.h:#include <libart_lgpl/art_svp_wind.h> ./libgnomecanvas/gnome-canvas-clipgroup.h:#include <libart_lgpl/art_vpath_dash.h> ./libgnomecanvas/gnome-canvas-text.c:#include "libart_lgpl/art_affine.h" ./libgnomecanvas/gnome-canvas-text.c:#include "libart_lgpl/art_rgb_a_affine.h" ./libgnomecanvas/gnome-canvas-text.c:#include "libart_lgpl/art_rgb.h" ./libgnomecanvas/gnome-canvas-text.c:#include "libart_lgpl/art_rgb_bitmap_affine.h" ./libgnomecanvas/gnome-canvas-text.c: /* FIXME: Do the libart thing instead of divide by 255 */ ./libgnomecanvas/gnome-canvas.h:#include <libart_lgpl/art_misc.h> ./libgnomecanvas/gnome-canvas.h:#include <libart_lgpl/art_rect.h> ./libgnomecanvas/gnome-canvas.h:#include <libart_lgpl/art_svp.h> ./libgnomecanvas/gnome-canvas.h:#include <libart_lgpl/art_uta.h> ./libgnomecanvas/gnome-canvas.h:#include <libart_lgpl/art_affine.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_rect.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_vpath.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_bpath.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_vpath_bpath.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_svp.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_svp_point.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_svp_vpath.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_vpath_dash.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_svp_wind.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_svp_intersect.h> ./libgnomecanvas/gnome-canvas-shape.c:#include <libart_lgpl/art_rect_svp.h> ./libgnomecanvas/gnome-canvas-polygon.c:#include "libart_lgpl/art_vpath.h" ./libgnomecanvas/gnome-canvas-polygon.c:#include "libart_lgpl/art_svp.h" ./libgnomecanvas/gnome-canvas-polygon.c:#include "libart_lgpl/art_svp_vpath.h" ./libgnomecanvas/gnome-canvas-polygon.c:#include "libart_lgpl/art_svp_vpath_stroke.h" ./libgnomecanvas/gnome-canvas-path-def.c:#include <libart_lgpl/art_misc.h> ./libgnomecanvas/gnome-canvas-rect-ellipse.h:#include <libart_lgpl/art_svp.h> ./libgnomecanvas/gnome-canvas.c:#include "libart_lgpl/art_rect.h" ./libgnomecanvas/gnome-canvas.c:#include "libart_lgpl/art_rect_uta.h" ./libgnomecanvas/gnome-canvas.c:#include "libart_lgpl/art_uta_rect.h" ./libgnomecanvas/gnome-canvas.c:#include "libart_lgpl/art_uta_ops.h" ./docs/reference/tmpl/gnome-canvas-clipgroup.sgml:see libart for details. Defines the clipping intersection rule (FIXME?). ./configure.in:m4_define([libart_required_version], [2.3.8]) ./configure.in: libart-2.0 >= libart_required_version dnl ./demos/dash-demo.c:#include <libart_lgpl/art_vpath_dash.h>
We can probably just include the libart sources inside libgnomecanvas. Libart is AFAIK unmaintained, anyway.
(In reply to comment #1) > We can probably just include the libart sources inside libgnomecanvas. Libart > is AFAIK unmaintained, anyway. Just like gnome canvas, which is why I'd like to WONTFIX this and say: If someone wants to depend on GNOME Canvas (even though it's deprecated and supposed to be dropped), merge the code into your codebases (and take libart as well). This is what we tell people using old GTK+ widgets anyway: take the code and maintain it on your own...
The Evolution project will likely take ownership of libgnomecanvas since it's the only application that still uses it (right?) and migrating off of it before GNOME 3 is not realistic. I would prefer it remain a separate module, like gtkhtml, but I'm fine with merging libart into libgnomecanvas if that's feasible.
(In reply to comment #3) > since it's the only application that still uses it (right?) There's also gthumb (bug 584882) and planner.
In bug #571742, Federico suggested that Evolution move to foocanvas. I missed the significance of that. IIUC, Nautilus and Gnumeric already embed foocanvas. Assuming Evolution, gthumb and Planner can be painlessly ported to foocanvas, perhaps the easiest way forward is to merge foocanvas back into libgnomecanvas, call it version 3, leave it deprecated, and move it from 'platform' to 'desktop' for GNOME 3.
Xournal relies heavily on libgnomecanvas, and foocanvas won't do (it's not antialiased). Too bad it seems to be emerging as the winning successor to libgnomecanvas. IMHO the deprecation of libgnomecanvas occurred WAY too early, with no clear preferred replacement in sight for the antialiased canvas. (whoever listed "cairo" as official successor of libgnomecanvas in GNOME 3 was clearly misinformed). Anyway: just wanted to say, I'd really really really prefer to see libgnomecanvas (or a drop-in replacement with the antialiasing features) available in GNOME 3 -- even if it's largely unsupported and officially deprecated. Please just make sure it still compiles! Denis
(In reply to comment #6) > IMHO the deprecation of libgnomecanvas occurred WAY too early Errm, it has been deprecated for more than four years now. > (whoever listed "cairo" as official successor of libgnomecanvas in GNOME 3 > was clearly misinformed). Where is cairo listed as successor? URL, please? > Anyway: just wanted to say, I'd really really really prefer to see > libgnomecanvas (or a drop-in replacement with the antialiasing features) > available in GNOME 3 As much as gtk1 is still shipped by distros, gnomecanvas will still be shipped by distros. Just not in the official GNOME releases, that's all.
(In reply to comment #7) > Errm, it has been deprecated for more than four years now. If I had known that four years ago, I might not have based xournal on it (though I'm not sure what else I could have used). I'm not in the inner circle of GNOME developers, but I certainly wasn't aware of anything until messages started popping up in the last few months alluding to the deprecation... > > (whoever listed "cairo" as official successor of libgnomecanvas in GNOME 3 > > was clearly misinformed). > > Where is cairo listed as successor? URL, please? Many of the top hits for "libgnomecanvas deprecated" in google are variations on http://www.debian-news.net/2009/04/06/preparing-for-gtk-30-and-gnome-3/ which says LIBGNOMECANVAS - Deprecated in favor of libcairo. Now I realize this is not an official page, and presumably just based on the vague information at http://www.gnome.org/~gman/roadmap.html which mentions a "new API based on the Cairo library", but it's pretty much the first piece of information that comes up. > As much as gtk1 is still shipped by distros, gnomecanvas will still be shipped > by distros. Just not in the official GNOME releases, that's all. Ok, sounds reasonable then. I'll stop complaining. I'll still vote very much in favor of making sure that libgnomecanvas can be compiled/linked against GTK+ 3, so that apps that use it don't get stuck in GTK+ 2.x territory. (unless GTK+ 3 adopts another antialiased canvas, of course). Denis
(In reply to comment #8) > > Errm, it has been deprecated for more than four years now. > If I had known that four years ago, I might not have based xournal on it There is no other canvas that is blessed either, so there's no real point to avoid it if your app is not an official GNOME app. Other canvases dependencies are more light-weight however. > Now I realize this is not an official page, and presumably just based on the > vague information at http://www.gnome.org/~gman/roadmap.html ...which talks about stuff to happen in GNOME 2.8. Released in September 2004. And now let me google for all the great stuff to be expect in Windows Longhorn, just to find out later that 90% were never implemented... ;-))
I'm bundling both libart_lgpl and libgnomecanvas into Evolution until GNOME finally decides on a canvas library. This effectively kills our attempted foocanvas migration, since there's no real value in switching libraries at this point. For Evolution's purposes this bug can be closed. OTOH, if libgnomecanvas releases are to continue into GNOME 3, I can help with getting it building against GTK3. It will require an API break to deal with the GtkObject::flags issue.
Since evo doesn't depend on gnomecanvas anymore, I just removed it from its dependencies in jhbuild for the 3.0 moduleset.
The last libgnomecanvas code changes took place in January 2011: https://git.gnome.org/browse/archive/libgnomecanvas/log/ This project is not under active development anymore. This project got recently archived in GNOME Git. It is currently unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again. If you are interested in maintainership, inform https://mail.gnome.org/mailman/listinfo/desktop-devel-list