Linux GUI on other than Ubuntu

[gsipe]

It is exciting to see a Linux GUI at long last! At parity with the Mac even!

...but only Ubuntu. I use Fedora and it would be great if there were a .RPM to download and install, but I'll build from source if need be. Unfortunately, there is no .RPM and the Linux source does not include the GUI.

What are the plans for supporting other Linux distributions and/or providing the Linux GUI source?

[s55]

Linux GUI source is available in the tar and in the svn.

Don;t think there is any plans to add any more downloads so you'll just have to build from source.

[JohnAStebbins]

I wasn't planning on creating other packages. To make everyone happy, I would have to build a very large number of them.
Ubuntu 32/64 8.04/8.10, Fedora 32/64 9/10, Suse, Slack, gentoo, centos, ...
You get the picture. I picked something that would cover a significant number of people.

[tcameron]

For what it's worth, the gtk bits won't compile on RHEL 5 since it still runs an older version of GNOME (2.16). The autoconf script bombs out looking for gio which IIRC is part of GNOME 2.2. I would gladly contribute packages for RHEL if the author could get it to compile under GNOME 2.16.

[JohnAStebbins]

Sorry, but I have no desire to backport to gnome 2.16. It would be a bit of a pain and a step backwards. I make use of gio and a few other gnome 2.2 specific features.

[jeffcobb]

Question (and not an attempt to hijack the thread): I really like what the author of this ghb tool did and would like the ask a couple of simple questions about it from the perspective of another developer:
1. If I wanted to extend the source in some significant way, which would be a better base to start from, the svn src or the stuff in the tarball?
2. What dev tools did the author use to develop it? I see Anjuta projects and jam files...

Nice work, seriously. I was fooling with QTCreator to crank something out with a slightly different usecase and while it did seem nice enough, I just felt like I wasn't getting the 'tao' of how it wanted your workflow to go...

Cheers,
Jeff

[JohnAStebbins]

Definitely start with svn. The release tarball is already seriously out of date. If you haven't built it yet, we have a detailed compile guide in the documentation.

If your going to contribute, please discuss your ideas here or on irc before putting in significant amounts of time. Many ideas have been thoroughly discussed in the past and there are many patches for various things floating around. Don't want you to waste your time (or ours ).

I started the project with anjuta because I knew very little about gtk development and autoconf build systems. Anjuta set up an initial project for me. But I abandoned anjunta pretty early in the project. ghb.anjuta is vestigial and is absolutely useless now. The ui initially used libglade and I did the initial layout with glade-2. But right about that time, it was announced that gtkbuilder would be the official layout engine for gtk. So I switched to it. glade-3 has support for gtkbuilder, but it's got several bugs that makes it only partially usable. Most of the time I just edit the xml layout file with vi. The Jamfile was an early experiment in figuring out how I could integrate my build system with the rest of the hb build. It's not used and I should delete it. So my "dev tools" are pretty low tech. vi and autoconf/make.

[jeffcobb]

Cheers John;

I am still working on some specifications for this; until that is done I am not sure on the best way to integrate with ghb (or integrate ghb with this). I have my own set of tools/extensions for HandBrake I am using now but could drop some of the more interesting ones into ghb such as an XML-RPC interface to a DVD lookup server with track name and type information. End result is the user inserts a disc, the proper names for *all* tracks appear in the selection window. There is a lot more but this is some low-hanging fruit. I have this running in a Python-based system ATM but thought making a super-tight C or C++ version of the lib just to see how slender I could do it (man I need a life). This would seem to be an excellent test vehicle for such functionality. Note this functionality would be very optional and configurable (users could use custom servers, etc) but hey, it sounded fun to try.

I have a lot of other things too that are almost certainly related, yet outside the target of ghb as I am automating the entire video life-cycle for a video on demand system. These are some of the things that I should think on more to see if/how they best fit here...

Again, primo work and I will pull the svn of the code immediately. Cheers for the fast reply.

Jeff

[JohnAStebbins]

When contributing, one key feature you should keep in mind is that HandBrake is cross-platform. You should do things in such a way that it is easy for the other platforms to adopt. In the case of the XML-RPC interface, this means that it should be integrated into libhb. Any support libs would be added to contrib dir and targeted changes to libhb would be made to use those libs. That might make the job a little more difficult since you would need to find an xml-rpc lib that is portable to all the platforms (or write one from scratch). This also means you need to get the support of the other developers. Part of doing that is showing that you're committed. I didn't get the linux gui accepted into the project until after I hung around for several months showing consistent interest and a willingness to maintain my code. I like the xml-rpc idea, but I'm curious how well it works in practice. How complete is the database, how is accuracy assured, etc.