#26 GTK+ 3 support

[Balló György]

This patch adds full support for GTK+ 3 by fixing all deprecations in Xarchiver. It keeps the compatibility with GTK+ 2 by using the --disable-gtk3 configure flag.

Can be applied to Xarchiver 0.5.4.

[Giuseppe Torelli]

Hi Gyorgy,

after applying this patch I can't compile anymore:

make[3]: *** No rule to make target sexy-icon-entry.c', needed byxarchiver-sexy-icon-entry.o'. Stop.

By the way, it would be better to direct your efforts toward the new development code that uses GModules to support the archive formats.

Please have a look:
$ svn checkout svn://svn.code.sf.net/p/xarchiver/code/trunk xarchiver

[Balló György]

You just have to regenerate the Makefile (and update the configure script) with ./autogen.sh (or run xdt-autogen directly). It requires xfce4-dev-tools.

[Giuseppe Torelli]

Can you generate a patch for getting rid of xfce stuff please?

[Balló György]

I attached the patch. Now you can use standard autotools to regenerate makefiles. Just run ./autogen.sh

[Giuseppe Torelli]

I applied the patch. After installing the devel package of GTK+3 I was able to compile. However now I get a lot of "Deprecated messages". I can't release a newer version with all those messages. There is no sense in doing that, don't you believe so?

By the way, thanks for your interest in Xarchiver, I do appreciate it.

[Balló György]

Those deprecations are already there in the current code. I fixed all of them that affects the GTK+ 2 version. So if you build Xarchiver with '--disable-gtk3' configure flag, you won't see any of those messages. If you want to remove the rest of the deprecations introduced in GTK+ 3, then it breaks GTK+ 2 compatibility.

Note that all GTK+ based software uses deprecated API, because they changes the API every half a year. So you can't make your application compatible with multiple GTK+ versions and fix all deprecations at the same time, because the code would be unmaintainable due to many conditional code.

[Giuseppe Torelli]

That's why is better to concentrate the efforts on one code. The one on the SVN can be ported to GTK+3 and forget about GTK+2 as it's undeveloped. This branch, 0.5.4 is buggy and slow. Try to open a 180MB zip file with both versions. The SVN one opens it instantly, the 0.5.4 freezes the GUI.

If you want I can port the SVN code to GTK+3 and get rid of all the deprecated API, in the meantime you could take care of completing the ZIP module by allowing it to allow add,test and dnd. Most of the code can be reused from this branch to do that. Look at the new extract dialog... does it sound tantalizing?

[Balló György]

Why don't you just use libarchive as backend? It could able to read and write into many archive formats, so you don't have to deal with each command line extraction program.
http://libarchive.org/

[Giuseppe Torelli]

Because I would add another dependency. Also libarchive can't write RAR and 7Z:

rar (read only, starting in libarchive 3.0)
7-Zip (read only, starting in libarchive 3.0)

Did I convince you to concentrate your efforts on the faster and better SVN code?

[Balló György]

You can use it also with the bsdtar binary. And the readme file is outdated, it supports writing 7z archives:
https://code.google.com/p/libarchive/issues/detail?id=41#c9

RAR is a proprietary format, and no open source tools are available to write into it, so I don't think it's so important.

I'm not really interested in a project that doesn't support libarchive/bsdtar.

[Giuseppe Torelli]

I'm not going to argue about proprietary and open source. I do not want to add another dependency Gyorgy, sorry.

I'm using your patch to have the SVN code use GTK+3 right now.

Your patches are welcome, thanks for your time :)