[patch] New Qt4 GUI

[saintdev]

• When creating presets does get implemented (provided it's not an issue with my setup), might I suggest sharing a common presets file with the gtk interface? Right now, ghb uses {$HOME}/.config/ghb/custom_presets to store custom presets. While that's probably not an appropriate location for qtHB, perhaps you and the gtk ui maintainer could use a common location for presets?

Yeah, this is kind of a pain. None of the interfaces use the same preset layout. Maybe someday we'll get around to unifying them.

[stealthdave]

You are correct, there it is. Was this a fairly recent addition to the build? I rebuilt both qtHB and ghb today from latest, and I could have sworn that when I looked at Preview yesterday, it only showed the image with no options to change. (The build was about a month old or so.) Then again, maybe I just didn't look hard enough.

Thanks for the tip!
- Dave

[gonza]

Thanks for all the feedback. Hopefully I'll get a chance to fix up some of the outstanding things soon. The presets thing has really only just begun so I imagine there are some problems there. Also I think I found a bug whereby the output filename is ignored, so look out for that. I think the output file ended up as a random named file in the home directory.

If anyone else is keen on improving it, please do so and post a patch, or a link to your git repository with the modified code.

Thanks!

[invader_dag]

Hey everyone,

I am having a problem compiling QHandBrake on Linux (Kubuntu 8.04). I used jam, and HandBrake compiled correctly. But then when I go to compile qtHB in qt4/ I get the following error:

In file included from ../libhb/hb.h:8,
from qhandbrake.h:21,
from main.cpp:19:
../libhb/hbversion.h:4:1: error: unterminated #ifndef
make: *** [main.o] Error 1

I am running "qmake && make".

I can remove the last line from hbversion.h and it will get past this point, but then it dies at this:

g++: ../libhb/libhb.a: No such file or directory
make: *** [qtHB] Error 1

I am sorry if I am out of line asking this here, but I have looked every where for a way around this but I could not find one.

It looks great from the screen shots and I would love to be able to try it out. Thanks everyone

[gonza]

Hi invader_dag,
Which sources are you using? The git ones mentioned above are the most recent.

[Donar]

Hello invader_dag i have the same problem but i think that it begins during "configure && jam"

Code: Select all

....
C++ libhb/ipodutil.o
libhb/ipodutil.cpp: In constructor »IPodUUIDAtom::IPodUUIDAtom()«:
libhb/ipodutil.cpp:22: Warnung: veraltete Konvertierung von Zeichenkettenkonstante in »char*«
Cc libhb/common.o
HBVersion hbversion.h
/bin/sh: Syntax error: Unterminated quoted string

    echo "#ifndef HB_BUILD" > ./libhb/hbversion.h
    echo "#define HB_BUILD 2008081801" >> ./libhb/hbversion.h
    echo "#endif" >> ./libhb/hbversion.h
    echo "#ifndef HB_VERSION" >> ./libhb/hbversion.h
    echo "#define HB_VERSION  >> ./libhb/hbversion.h
    echo "#endif" >> ./libhb/hbversion.h
    echo "#ifndef HB_APPCAST_URL" >> ./libhb/hbversion.h
    echo "#define APPCAST_URL \"http://handbrake.fr/appcast_unstable.xml\"" >> ./libhb/hbversion.h
    echo "#endif" >> ./libhb/hbversion.h

...failed HBVersion hbversion.h ...
...skipped <libhb>hb.o for lack of <libhb>hb.c...
...skipped <libhb>ports.o for lack of <libhb>ports.c...
...skipped <libhb>scan.o for lack of <libhb>scan.c...
...skipped <libhb>work.o for lack of <libhb>work.c...
...skipped <libhb>decmpeg2.o for lack of <libhb>decmpeg2.c...
...skipped <libhb>encavcodec.o for lack of <libhb>encavcodec.c...
...skipped <libhb>update.o for lack of <libhb>update.c...
...skipped <libhb>demuxmpeg.o for lack of <libhb>demuxmpeg.c...
...skipped <libhb>fifo.o for lack of <libhb>fifo.c...
...skipped <libhb>render.o for lack of <libhb>render.c...
...skipped <libhb>reader.o for lack of <libhb>reader.c...
...skipped <libhb>muxcommon.o for lack of <libhb>muxcommon.c...
...skipped <libhb>muxmp4.o for lack of <libhb>muxmp4.c...
...skipped <libhb>sync.o for lack of <libhb>sync.c...
...skipped <libhb>stream.o for lack of <libhb>stream.c...
...skipped <libhb>decsub.o for lack of <libhb>decsub.c...
...skipped <libhb>deca52.o for lack of <libhb>deca52.c...
...skipped <libhb>decdca.o for lack of <libhb>decdca.c...
...skipped <libhb>encfaac.o for lack of <libhb>encfaac.c...
...skipped <libhb>declpcm.o for lack of <libhb>declpcm.c...
...skipped <libhb>encx264.o for lack of <libhb>encx264.c...
...skipped <libhb>decavcodec.o for lack of <libhb>decavcodec.c...
...skipped <libhb>encxvid.o for lack of <libhb>encxvid.c...
...skipped <libhb>muxavi.o for lack of <libhb>muxavi.c...
...skipped <libhb>enclame.o for lack of <libhb>enclame.c...
...skipped <libhb>muxogm.o for lack of <libhb>muxogm.c...
...skipped <libhb>encvorbis.o for lack of <libhb>encvorbis.c...
...skipped <libhb>dvd.o for lack of <libhb>dvd.c...
...skipped <libhb>muxmkv.o for lack of <libhb>muxmkv.c...
...skipped <libhb>deblock.o for lack of <libhb>deblock.c...
...skipped <libhb>deinterlace.o for lack of <libhb>deinterlace.c...
...skipped <libhb>denoise.o for lack of <libhb>denoise.c...
...skipped <libhb>detelecine.o for lack of <libhb>detelecine.c...
...skipped <libhb>decomb.o for lack of <libhb>decomb.c...
Cc libhb/lang.o
...skipped <libhb>enctheora.o for lack of <libhb>enctheora.c...
...skipped libhb.a for lack of libhb.a(hb.o)...
...skipped test/test.o for lack of test/test.c...
...skipped test/parsecsv.o for lack of test/parsecsv.c...
...skipped HandBrakeCLI for lack of test/test.o...
...failed updating 1 target(s)...
...skipped 39 target(s)...
...updated 39 target(s)...

Are you sure configure & jam work without any problem during your compile?

The files it's missing seem to be there where they should be (and sorry "ll" didn't work somehow)

Code: Select all

donar@HAL2008:~/Desktop/HandBrake/libhb$ ls
common.c      decomb.c       enclame.c    internal.h    muxcommon.c  stream.c
common.h      decsub.c       enctheora.c  ipodutil.cpp  muxmkv.c     sync.c
common.o      deinterlace.c  encvorbis.c  ipodutil.o    muxmp4.c     update.c
deblock.c     demuxmpeg.c    encx264.c    Jamfile       muxogm.c     work.c
deca52.c      denoise.c      encxvid.c    lang.c        ports.c
decavcodec.c  detelecine.c   fifo.c       lang.h        ports.h
decdca.c      dvd.c          hb.c         lang.o        reader.c
declpcm.c     encavcodec.c   hb.h         Makefile      render.c
decmpeg2.c    encfaac.c      hbversion.h  muxavi.c      scan.c
donar@HAL2008:~/Desktop/HandBrake/libhb$    

I use this git repository (as posted by hunterk elsewhere)

Code: Select all

    
git clone git://repo.or.cz/HandBrake.git
cd HandBrake
git checkout --track -b bonne/qhandbrake origin/bonne/qhandbrake

Regards

[jbrjake]

Ok I'm sick of seeing this thread pop up at the top of the Dev forum and not having any actual development discussion, just compilation hand-holding.

Moving to *nix.

[gonza]

I think the problem you are experiencing lies with the generation of the file libhb/hbversion.h.
In the Makefile in the main directory is probably the line:

Code: Select all

echo "#define HB_VERSION  >> ./libhb/hbversion

Which should read:

Code: Select all

echo "#define HB_VERSION \"$(HB_VERSION)\"" >> libhb/hbversion.h

For whatever reason I think the Makefile hasn't been generated properly. I'm not an expert on build systems but I would start by checking how old your installed jam, make etc. is.

[gonza]

More info for those still having problems compiling.

My version of the file libhb/hbversion.h looks like this:

Code: Select all

#ifndef HB_BUILD
#define HB_BUILD 2008070801
#endif
#ifndef HB_VERSION
#define HB_VERSION "svnexported"
#endif
#ifndef HB_APPCAST_URL
#define APPCAST_URL "http://handbrake.fr/appcast_unstable.xml"
#endif

This gets generated by a part of the Makefile in the root directory

Code: Select all

#snip

libhb/hbversion.h:
  echo "#ifndef HB_BUILD" > libhb/hbversion.h
  echo "#define HB_BUILD $(HB_BUILD)" >> libhb/hbversion.h
  echo "#endif" >> libhb/hbversion.h
  echo "#ifndef HB_VERSION" >> libhb/hbversion.h
  echo "#define HB_VERSION \"$(HB_VERSION)\"" >> libhb/hbversion.h
  echo "#endif" >> libhb/hbversion.h
  echo "#ifndef HB_APPCAST_URL" >> libhb/hbversion.h
  echo "#define APPCAST_URL \"http://handbrake.fr/appcast.xml\"" >> libhb/hbversion.h
  echo "#endif" >> libhb/hbversion.h

The errors people were seeing relate to how make interprets this file or how the shell interprets the echo commands it runs. Hope this helps...

[gonza]

Hi all.

I'm back from holidays now and I noticed that Handbrake has released version 0.9.3 with some awesome new features (the most significant to me is the ability to use any file as input).

I'm currently in the process of updating the Qt4 gui for the new version of libhb. I have come up with a list of things I'd like to do (lets call it a todo list) with the gui to prove it ready for wider use and hopefully incorporation into svn:

1. Port the code to the latest svn version of libhb and get it working on Linux
2. Get it to compile on Mac (and provide a binary for people to test)
3. Get it to compile on Windows (and likewise provide a binary for testing)
4. Provide at least one translation to make sure the code is ready for more
5. Make sure the build system is robust
6. Polish the UI and finish off the remaining missing features

Some of these things I can do (1,maybe 2, 6), but most of them require more helpers. If you are interested in turning Handbrake into a killer app that fit's right into a KDE environment then please help out. I was considering making it a full-blown KDE application rather than just a Qt one. Anyone interested in that?

[gonza]

Ok, so I updated my source with the latest changes from svn, made a few changes to my code and got it to compile. By no means does this mean that all of the changes between 0.9.2 and 0.9.3 are working in this gui but at least people can start testing.

The procedure should still be as follows:

Code: Select all

git clone git://repo.or.cz/HandBrake.git
cd HandBrake
git checkout --track -b bonne/qhandbrake origin/bonne/qhandbrake

Compile libhb as you normally would then:

Code: Select all

cd qt4
qmake
make

[hunterk]

Hey gonza, I'll try compiling the new code later today, do some testing, and let you know how it turns out. I too would like to see your additions added to SVN. Even if your code is slightly out of date, at least it's more recent than what's in there right now!

IIRC, having a unified Qt4 GUI that would compile on all 3 platforms used to be a major goal for version 1.0, but it looks like it's been removed from the roadmap. I'm not sure if that's because new features (such as video previews) have made it an impossibility or if everyone is just happy with the current state of having a separate GUI for each system.

I'm of the opinion that a unified GUI would futureproof the project a bit, in case j. stebbins or dynaflash for example have to abandon their GUIs for whatever reason. Then, 1 person could pick up the code and keep it going instead of needing a new person for each platform. However, that's not for me to decide.

[jbrjake]

An 0.9.3 interface wouldn't even compile against SVN head due to the API changes, so how is that futureproof?

This is why maintainers are always told to work against current code, and not play catch-up after a release.

[saintdev]

I was considering making it a full-blown KDE application rather than just a Qt one. Anyone interested in that?

What would you gain from this?

Personally I don't see any reason to have the additional overhead.

[gonza]

Hey gonza, I'll try compiling the new code later today, do some testing, and let you know how it turns out. I too would like to see your additions added to SVN. Even if your code is slightly out of date, at least it's more recent than what's in there right now!

Thanks, that'd be great.

IIRC, having a unified Qt4 GUI that would compile on all 3 platforms used to be a major goal for version 1.0, but it looks like it's been removed from the roadmap. I'm not sure if that's because new features (such as video previews) have made it an impossibility or if everyone is just happy with the current state of having a separate GUI for each system.

Well Qt has a framework for things like video which make it very easy to display video using native backends (Quicktime on Mac, DirectShow on Win, GStreamer or Xine on Linux), without having to write any platform-specific code.

I'm of the opinion that a unified GUI would futureproof the project a bit, in case j. stebbins or dynaflash for example have to abandon their GUIs for whatever reason. Then, 1 person could pick up the code and keep it going instead of needing a new person for each platform. However, that's not for me to decide.

I tend to agree, but I also see no reason to get rid of working GUIs if there are people interested in using and maintaining them. The beauty of open software is that we can have it all.

An 0.9.3 interface wouldn't even compile against SVN head due to the API changes, so how is that futureproof?

This is why maintainers are always told to work against current code, and not play catch-up after a release.

I think what hunterk is trying to say is that a GUI that used a single codebase for all three platforms would be easier to maintain because it requires fewer changes and fewer developers to keep up with the changes in the underlying library. But I think that's getting a bit ahead of ourselves. The Qt GUI needs to catch up with the functionality and stability of the others before that's even worth worrying about.

[gonza]

I was considering making it a full-blown KDE application rather than just a Qt one. Anyone interested in that?

What would you gain from this?

Personally I don't see any reason to have the additional overhead.

There are a few reasons I was considering it. One was to make use of the KDE libraries, so things like notifications and hardware detection were easier to do. Another is to attract the KDE userbase which would bring a large number of potential users and developers so the code could mature more quickly. And another reason is that given there are very good GUIs for Windows, Mac and Gnome (via GTK+) the most likely users of a Qt GUI are KDE users anyway, so it might make sense to make the application integrate fully with a KDE environment.

That said, If there is interest in using a Qt GUI on either Windows or Mac then it probably wouldn't be worth it.

[jbrjake]

An 0.9.3 interface wouldn't even compile against SVN head due to the API changes

Correction: Sorry, I see you made the bare minimum changes necessary to get it compiling against last month's code, in your git repo branch...

[gonza]

An 0.9.3 interface wouldn't even compile against SVN head due to the API changes

Correction: Sorry, I see you made the bare minimum changes necessary to get it compiling against last month's code, in your git repo branch...

You sound [Censored] off that I'm trying to contribute to your project. I've written 5-10 thousand lines of code and I just got back from holidays. Yes, I've made the bare minimum changes to get it to compile so that anyone interested can at least have a look at what I did. So what?
In my opinion there are a large number of potential users and developers for a HandBrake Qt GUI. I probably don't have the time to maintain it completely on my own, but what I'm trying to do is make it as easy as possible for anyone interested in helping out to do so. I don't think that the code I've written should be thrown out just because it's not yet complete.
Once I have an internet connection at my new place I'll be able to interact more with the current devs and make sure this is progressing in a way that's compatible with the existing project.

[jbrjake]

You sound [Censored] off that I'm trying to contribute to your project. I've written 5-10 thousand lines of code and I just got back from holidays. Yes, I've made the bare minimum changes to get it to compile so that anyone interested can at least have a look at what I did. So what?

No one's saying the code should be thrown out. But you've known for months and months now what kind of commitment you need to show to get it in the SVN and it's rather disappointing that you never follow through.

Last July you asked:

So what's the process to get these changes into svn? Should I apply for an account?

And I explained:

Stick around for a few months and show you're committed, and it will be committed.

The project tends to take a "wait and see" approach to interface maintainers, because the only thing worse than no gui is an out of date and unsupported gui.

For comparison:

John Stebbins first shared his GTK GUI with us on IRC in March. It was committed to the SVN repository a little less than three months later. He stays in touch constantly, reacted swiftly to new developments, and contributes tech support as well as libhb patches.

And you replied:

No problems, I'm keen to get it nice and polished for you.

...So why haven't you? I've had to fight off other devs who wanted to kill off the Qt GUI entirely -- remove the whole directory from the SVN instead of updating it to your code, and simply tell people to use GTK as the only recourse for a Linux GUI. I held that off only because you told us you were going to get this code polished up.

In July, when we talked about that stuff, we were working on 0.9.3. We released that in November, after having a feature freeze of several weeks so any and all GUIs could be set in stone for the release, and after a series of snapshot builds all the other GUI developers participated in. We immediately continued work on 0.9.4, along paths laid out in the development forum regarding stuff like live preview encodes.

Your GUI still has yet to catch up with 0.9.3, let alone the current code base. Everywhere I look in the code, I see things that are just *wrong*. Why are you still using 0.9.2's built-in presets? Why do you have widgets for x264 options that no longer exist? Where is the decomb filter? Why is there a checkbox for VFR -- this makes me suspect you never set job->cfr when someone specifies a constant framerate. Why is deblock a checkbox instead of a slider? For that matter, why are filters together with picture settings? Have you even looked into live preview yet? What about queue modification, which is coming up soon? Instead of shooting for where the target will be, or even where the target currently is, you're aiming at where the target was last year...

[gonza]

In my defence I've been on holidays since October. I posted the most recent update a few days after I got back from a friends place and I'm waiting for my internet connection at my new place so I can continue.

Your GUI still has yet to catch up with 0.9.3, let alone the current code base. Everywhere I look in the code, I see things that are just *wrong*. Why are you still using 0.9.2's built-in presets? Why do you have widgets for x264 options that no longer exist? Where is the decomb filter? Why is there a checkbox for VFR -- this makes me suspect you never set job->cfr when someone specifies a constant framerate. Why is deblock a checkbox instead of a slider? For that matter, why are filters together with picture settings? Have you even looked into live preview yet? What about queue modification, which is coming up soon? Instead of shooting for where the target will be, or even where the target currently is, you're aiming at where the target was last year...

Thanks for the feedback. I'm fully aware that the code needs work. Part of the reason for posting here is to let people know that the code exists so that anyone else who wants to help knows where to look. I will take a look at implementing the changes you mentioned above as soon as I can (or if anyone else wants to do it then please post patches here).
If you can point me to a list of other changes I need to make please let me know.
Is the libhb API documented anywhere by the way?

[jbrjake]

If you can point me to a list of other changes I need to make please let me know.

...this is why we have an svn log...

Is the libhb API documented anywhere by the way?

There's doxy comments for a number of the functions you use. Most of non-doxied code is heavily commented as well. The CLI functions as a primer in how the API works. There are technical documents on the wiki explaining some workflow stuff.

[gonza]

Is the libhb API documented anywhere by the way?

There's doxy comments for a number of the functions you use. Most of non-doxied code is heavily commented as well. The CLI functions as a primer in how the API works. There are technical documents on the wiki explaining some workflow stuff.

Cheers

[gonza]

I have just pushed up some changes which bring the Qt GUI a little closer to feature parity with the other GUIs.


Changes:
Fix up x264 options - remove old options and add in new ones.
Fix up filter options

Obviously there are still a bunch of things that need doing. Any help is appreciated.

[JackieBrown]

Thank you gonza for all your work on this.

I think a KDE 4 specific framework would be great, but using QT4 is obviously better than using gtk (for kde users.)

[gonza]

So I've done quite a bit more work on this.
I tried for quite some time to get the GUI to compile on Windows, but since HB doesn't yet build with MinGW that wasn't possible... You can see more info on that here: http://forum.handbrake.fr/viewtopic.php?f=4&t=9786

I have updated the presets to be in line with the current svn code. There are some small bugs with this, but the essential parts are all there, it's just a matter of making sure all the settings get applied when switching presets.
I have also updated the build system so that it will build the Qt GUI, and it now does an out-of-source build like the other parts.

Let me know if you have any problems