GNOME Bugzilla – Bug 328842
patch to build without gnome libraries
Last modified: 2007-12-08 14:10:54 UTC
configure switch and ifdefs on WITH_GNOME to allow it to build with plain gtk. use goption and extension based mime detection to avoid explicit linking to popt and dependence on libmagic.
Created attachment 58209 [details] [review] the patch
Created attachment 59063 [details] [review] small cleanup patch backend does no longer depend on vfs,remove unneeded include This makes the gtk-only diff smaller
Created attachment 59636 [details] [review] updated gtk patch diff against today's HEAD, with a cleaner configure.ac patch please let me know if you're interested in this and if I should keep it updated against CVS.Otherwise I will make diffs only against releases. thanks
Jani, we are happy to see evince as gtk-only application. But in current state it's not optimal to check such kind of patch. Probably someone will object to that but it will create additional problems without much win. We do need to have gnome-based features and do need to use gnome for that. Let's make this process incremental, for example, we already have patch for popt, let's review and apply it. Then let's migrate to gtk-only recent-files (I suspect this code is already merged into gtk, we just need to use it). I hope after that problem will disappear automatically. Until that please update your patch, it's really interesting and useful.
I agree with Nickolay when he says we shold do this in a incremental way. For example, maybe it is not the best approach to copy code from GNOME VFS and paste it in evince code if we are not running a GNOME environment. GNOME VFS takes care of a crucial part of the system transparently and it can be easily built in a system without any GNOME libraries (including WIN32). In my opinion, if it is really our interest don't make use of GNOME VFS, we should implement something like a ev-file.c or ev-io.c where al #ifdef WITH_GNOMEVFS would live. Let's first detail things even more and find alternatives for other stuff like keyring, gconf an so on.
I agree too with the incremental updates btw. I'd just like the build system patch in first to make the rest easier. Nothing is lost for those not using the --disable-gnome flag (everybody actually rigth now) The reason for copying code from gnome-vfs is because I see no other way of doing that part of the code. There is cut-n-pasted code already, but true it's in a separate dir. As for gnome-vfs buildability outside gnome it is not relevant here since on linux gnomevfs is built with gnome libraries and some more. So the very dependency on gnome-vfs is what I am trying to avoid. And as said, I think evince should still use gnome-vfs I do not intend to replace that, it just needs to be made optional. As for keyring/gconf I don't think we need alternatives. A gtk-only build is purposely lacking features as a trade-off for not using gnome libraries. It is not my intention to switch evince to a gtk only app while preserving all it's functionality. When d-vfs and d-conf are more than vapourware and project ridley achieves it's goal yes, but right now I just want a feature impaired version of the full evince (which IMHO still covers 99% of the use-cases, that is viewing local pdf/ps files in the good old-fashioned way)
Created attachment 71968 [details] [review] updated patch Updated against today's CVS head. It's smaller than the previous ones as the changes to use goption are no longer needed, and it assumes gtk+2.10 so the eggerecent module is not touched at all.
I updated the patch to the latest version (v0.6.1). The patched source can be found on my <a href=http://petra.hos.u-szeged.hu/~ngaba/linux/index.html>homepage</a>.
I updated the patch to the latest version (v0.7.0)
I think that depending on gnome-vfs wouldn't be such a big problem, at least it would be a lot better than the current situation for evince users who don't want a full-blown Gnome desktop. g-vfs is right at the bottom of the Gnome dependency tree and drags in nothing special, so it doesn't hurt that much...
Updated patch status and committed view fix.
Gabor, if you update the patch to 0.7.1 please add it as an attachment, it's easier to review than getting the full tarball. Also have you looked into GnomeIcon (a newly added dependency) and whether GtkIcon can replace it? thanks
Patch updated to v0.7.1. Gnome-VFS dependency optional, missing icons are downloadable.
Updated to v0.7.2. Please test the 'open link' function (maybe I ran into a gnomeVFS bug (?)); and report the missing features (which are not listed on my homepage)
attaching the patch would make it more likely that it gets reviewed and commented on.
No, because my patch keeps changing (when I'm working on it, I may update it daily).
Created attachment 87395 [details] [review] New author, new approach, new patch Attached is a patch that takes the point of view that not all of GNOME is evil. - libgnomeui BAD - libgnome BAD - gnome-vfs WE CAN LIVE WITH - gnome-keyring BEST FRIENDS FOREVER It's not 100% finished: - help doesn't work (can't spawn a web browser) - MIME icons are empty (this can be fixed and the libgnomeui dependency removed too)
glad to see this moving forward :) * for gnome-client maybe the new smclient module in libegg is good enough and gets rid of ifdefs at the expense of having another egg module under copy-paste * for emulating gnome_help_display(), g_spawning gnome-help, or alternately 'gnome-open yelp' should do as in the patch attached to http://bugzilla.gnome.org/show_bug.cgi?id=399818
1) Agreed. Is that module usable yet I wonder. 2) Using gnome-open is a temporary work around, but gnome-open is provided by libgnome, so it doesn't really help. :)
1) I think so, at least the svn has an example for gedit at least which uses gnome-client a lot more than evince. 2) Weird, I was under the impression it was in gnome-utils or such, but it seems not. So xdt-open and fall back on gnome-open maybe. Or just gnome-help which is provided by yelp.
+#else + dot_dir = g_build_filename (g_get_home_dir (), + ".evince", How about using g_get_user_config_dir() of g_get_home_dir() ? +#else + g_option_context_add_group (context, gtk_get_option_group (TRUE)); + g_option_context_parse (context, &argc, &argv, NULL); + gtk_init (&argc, &argv); You need to check the return value of g_option_context_parse, and free the option context afterwards. And since you added the gtk option group to the context, there's no need to call gtk_init again.
2) I remember what was the advantage of calling gnome-open : even if the app still depends on libgnome it is no longer a linktime hard-dependency, so it does not add up to startup time, and it can fail graciously when the whole GNOME desktop and libgnome is not present. And no ifdefs needed either.
Created attachment 87408 [details] [review] Revised patch This patch fixes the option parsing and uses g_get_user_config_dir(). I'll look at the other bug for the help de-gnome-ification later.
Created attachment 87440 [details] [review] Revised patch This patch replaces the use of libgnome when looking up icons for MIME types with from GTK+ (as used in the recent file manager and the file chooser). This change (to shell/ev-sidebar-attachment.c) can be applied on its own. However it is untested because I don't have any files which cause the attachments sidebar to be enabled, but it is an almost direct copy of the code in GTK+ so I can't see it failing.
Created attachment 87450 [details] [review] Re-revised patch In libdocument/ev-file-helpers.c replaced WITH_LIBGNOME tests with WITH_GNOME
Created attachment 87517 [details] [review] Latest patch This patch incorporates Eduardo's fix, and also doesn't use libgnome to open help (instead uses a similar piece of code to the g-p-m patch). In my opinion, this patch is now feature-complete.
Ignore the addition of .bzrignore obviously. :)
Patch looks good to me. I only have a question, why not always use g_get_user_config_dir ()?
Because traditionally GNOME apps have stored configuration in .gnome2/. If the maintainer don't mind Evince 2.20 losing the metadata, print settings, and toolbar settings, then that change can be done.
Note: I'll happy commit fragments of this patch, for example the help change, if it helps start the merge process.
Ok, I thought g_get_user_config_dir() == gnome_user_dir_get(). The whole patch looks good to me. If Nickolay doesn't have any objections, feel free to commit it.
Just one nit: +#else + dot_dir = g_build_filename (g_get_user_config_dir (), + ".evince", "evince", not ".evince" :)
chpe: whoops, good catch. Nickolay?
Heh, fine for me :) But probably we can call it not without-gnome but with-gmae or something like that?
It's not really GMAE specific, it literally is --without-gnome. Would --without-libgnome be preferred?
As you like, probably without-gnome is fine too. Please commit it.
Committed, thanks!
Well, I updated my patch, correct MIME handling is also implement using xdgmime: http://jedlik.vein.hu:60080/linux/evince/evince-en.html Now --with-gnomevfs and --with-gnome should be identical to the original version (apart from my little own modifications), but those not well tested.