[patch] New Qt4 GUI

[gonza]

Ok, so I have implemented a very crude "live preview" feature. It's not yet live, and there are no options available to the user.
Basically there's a checkbox "Preview" which will tell HB to encode only a minute of the video instead of the whole thing, and outputs it as though it is the real deal. You can then just play it using an ordinary video player.

I'll take a look into Phonon now to see if I can get a built-in player working.

[gonza]

I've made a basic player window which will play the preview encode using Phonon. Still no options etc. but it should allow for live preview on Linux, Mac and Windows using the same codebase. With a bit of polish this should be a very nice feature

[JohnAStebbins]

gonza, you were asking recently on irc how presets are stored. I don't know if you got the answer you were looking for. On the mac, the defaults are in code and then get written to a plist file (xml). In the gtk gui, I use the same plist format that the mac saves it's presets in. There may be minor differences still, but we've been converging the formats. My original format was an ini style file (key=value pairs). Instead of coding the presets, I have an xml file that contains the standard presets which gets compiled into the code as a string. Whenever jbrjake updates the presets, I ask him to supply me with the plist output from the mac, and I simply replace my xml file. This makes staying in sync much easier.

[gonza]

gonza, you were asking recently on irc how presets are stored. I don't know if you got the answer you were looking for. On the mac, the defaults are in code and then get written to a plist file (xml). In the gtk gui, I use the same plist format that the mac saves it's presets in. There may be minor differences still, but we've been converging the formats. My original format was an ini style file (key=value pairs). Instead of coding the presets, I have an xml file that contains the standard presets which gets compiled into the code as a string. Whenever jbrjake updates the presets, I ask him to supply me with the plist output from the mac, and I simply replace my xml file. This makes staying in sync much easier.

Thanks, that sounds like a good plan. Qt has support for ini files on all platforms and plist files on the Mac as well. I tried using the plist xml file you're using but Qt doesn't support the array type, and only likes string types for the data. So I created an ini file from the xml file manually for testing and I'll come up with a better way to integrate soon. A compromise might be to settle on the simpler plist format that Qt uses. This should be easy to use for all GUIs with only minor modifications.

[gonza]

Live preview is much nicer now.
There are pause, play and stop buttons, a position slider and a volume slider. What more do you need?

[gonza]

I got the new code (with live preview) to work on mac!

[gonza]

For anyone trying to compile the gui there are a few things you should know:

• The build system has changed significantly (both in svn and in the git sources for the new Qt4 Gui). You will need to reconfigure the build for this new system by following the instructions in 00-Building--*.txt.
• The Qt4 Gui uses the new build system and it works beautifully on Linux
• The Qt4 sources have moved inside the source to the qt directory (used to be qt4). If you are looking at code in the qt4 directory you don't have the latest version
• Building using the default build system works fine up to a point on Mac, then you have to open qtHB.xcodeproject in XCode and hit "Build" to finish it off
• Building on Windows hasn't been figured out yet since libhb doesn't yet compile with MinGW.

[gonza]

I've just completed a massive overhaul of the Qt GUI code so that it has some more of the features of the other GUIs.

New features:
Encodes are stored in your settings so that if there is a crash or you want to turn your computer off and come back later, they're all still there.

Soon to come:
Reloading an encode from the queue back to the GUI so you can edit it
Changing the order of the queue

The code is in much better shape now, and after finishing off some of the finer details of this change it should be much better than before.

There will still be bugs, though, so please let me know what you find.

Cheers

[gonza]

Hi all,

So the new GUI code is looking much better. Now you can reload an encode from the queue back to the GUI to change it. I have fixed all of the major issues (as far as I'm concerned). There are still missing features (like the activity log) but these are simple to fix. There are probably also bugs and other improvements but I really need some feedback to be able to fix these.

I think it's time to import this code into svn to give it a wider audience. Thoughts?

[jbrjake]

I have fixed all of the major issues (as far as I'm concerned). There are still missing features (like the activity log

IMO not having an activity log counts as a major issue...not sure how you expect to get useful feedback without one.

[gonza]

IMO not having an activity log counts as a major issue...not sure how you expect to get useful feedback without one.

jbrjake: Please give me a definitive list of all the things you need me to do before you will allow my code into svn. I see no reason why I shouldn't be working on the code directly in svn now. The code should not need to be perfect. I'm not asking that this GUI become an officially supported part of the project yet, just that the code is put in a more visible place.

[jbrjake]

Understand this is not just me standing in your way. In fact, of the administrators, I'm the one who's most enthusiastic about adding yet another GUI.

I only mentioned the activity log thing after another admin said he, too, felt it was absolutely critical to have that.

The main concern, though, is your lack of communication. Our current active developers -- that is, the people who have SVN access and have used it since 0.9.3 -- consists of:

dynaflash
jstebbins
jbrjake
sr55
ritsuka
konablend
van
saintdev
eddyg

What they all have in common is that they all communicate. Constantly. With the exception of van, we all make the sacrifice of staying in the IRC channels all the time. And van, who can't because of work firewalls, makes an effort to read the logs.

Some comments from our discussion about giving you SVN access yesterday. Comments in bold are from the people who actually decide whether or not to add you to the authentication file:

"i don't exactly feel all warm and fuzzy about the notion of letting someone who doesn't communicate regularly have access to the svn"

"Well, at current level of communicaitons, I would not be comfortable doing any release with it [....] If it goes in and we don't end up releasing it, whats the point?"

"fwiw, i think it would be valid to gate QT4 merge and svn access based on participation and presence in this dev channel. it's one of those things that requires team presence."

"imo this project should require that a gui maintainer be avail a reasonable amount of time on irc ... and I would be really [Censored] if it went into the svn and he disappears again. like we need more dead wood. as well as irc he needs to be available imo to support it on the forums, bugs and what not. Just like the rest of us."

[gonza]

jbrjake: Thanks for filling me in. I had thought for a while that IRC was an important part of this project, but a number of times I've gone on there and there's been very little activity (especially on the dev channel). Also I don't have the ability to post to the dev channel. I didn't realise it was the main communication path for devs.

I respond to emails (which includes responding to forum threads/bug reports etc. since they can email out a notice) very quickly because I use email all day at work, but it's not feasable for me to be on IRC during work hours. I am constantly contactable by email which has been more than sufficient for other projects I've worked on. Since the project has made allowances for van, perhaps the same could be made for me.

p.s. Activity Log is now done.

[rhester]

Since nobody asked me, I'm going to weigh in here.

We've had outdated/outmoded code in svn for literally *years*. No, it wasn't exposed to users, and no, it wasn't maintained, but it was there (and finally and mercifully removed only in the past six months or so).

gonza has put a lot of work into this. It's not as if he wrote 30 lines of patch and expected to be granted SVN access, as many others have/did.

I agree that communication is critical, but I can't accept the "what if he bails later?" argument. What if *ANY* of us bail? What happens next? Either someone eventually picks up the baton or the code stagnates and dies, just like any other open-source project. If it affects core, HandBrake is screwed. If it affects a single, non-mainstream GUI...so what?

I sincerely appreciate what the developers are doing to try to protect the project, but you need to equally appreciate that the 80/20 rule applies here...if the guy has done 80% of the work and just wants to feel like he hasn't wasted his time by at least having his code checked into svn so that he's better motivated to begin the REALLY difficult climb of finishing the remaining 20%, what's so wrong with that?

HandBrake was pulled out of the ashes out of a spirit of openness and comradeship. It has endured for exactly those reasons. I'm fine with the occasional bickering and pestilence brought down upon (l)users that can't be bothered to click on a URL and read a few lines of documentation, but can we please show a little support for someone who has made very strong and sincere efforts to contribute?

Yes, I know there's history here, and yes, I understand the concerns. But I put my foot down that HandBrake had to remain open for a reason, right down to the IRC logs being publicly available in near-real-time, and my definition of "open" goes beyond the source code itself. If HandBrake truly does begin to turn elitist *against developers willing and making an effort to contribute*, it deserves the neglectful death it will eventually endure.

My word is hardly law - but try to give it some thought.

Rodney

[s55]

I didn't realise it was the main communication path for devs.

prod one of us and we'll voice you.

No-one expects you to be on IRC 24/7. Just regularly enough so that you can see what's going on. We've got both channels logged so you can keep up to date with the latest talk.

[jbrjake]

We've had outdated/outmoded code in svn for literally *years*. No, it wasn't exposed to users, and no, it wasn't maintained, but it was there (and finally and mercifully removed only in the past six months or so).

gonza has put a lot of work into this. It's not as if he wrote 30 lines of patch and expected to be granted SVN access, as many others have/did.

I agree that communication is critical, but I can't accept the "what if he bails later?" argument. What if *ANY* of us bail? What happens next? Either someone eventually picks up the baton or the code stagnates and dies, just like any other open-source project. If it affects core, HandBrake is screwed. If it affects a single, non-mainstream GUI...so what?

I sincerely appreciate what the developers are doing to try to protect the project, but you need to equally appreciate that the 80/20 rule applies here...if the guy has done 80% of the work and just wants to feel like he hasn't wasted his time by at least having his code checked into svn so that he's better motivated to begin the REALLY difficult climb of finishing the remaining 20%, what's so wrong with that?

Understand that our worst nightmare isn't that his GUI sits at its current level of completeness in our SVN. It's that he gets it up to 100%, pushes us to do a release with it, and *then* disappears for half a year again, just as bug reports start to roll in. What we're trying to avoid is having unsupported, unmaintained work end up in Linux distro packaging repositories, leaving us to deal with the support mess.

While Linux users are a definite minority of our userbase, they are a very *vocal* and *demanding* minority and dealing with them requires a significant investment of time. They do not respect whether or not a project does an "official" release of particular code. Someone will grab the code from our repo, compile it, and stick it in a packaging system. And unless we're very very lucky, they'll make serious modifications to the build system in the process. The only way these situations have been sorted out with the GTK interface is that John Stebbins is constantly around to deal with them. No one wants another RippedWire.

[s55]

No one wants another RippedWire.

or ghb (Not John's one)

[rhester]

Conversely, you can't make every part of the build system dependent on a single person, lest you face exactly the same issue with devs who have been strong contributors for years but then choose to go their own way. How are any other HandBrake developers supposed to become familiar with the Qt code if it isn't part of the repository?

Single points of failure abound. Treating one differently from the others as a result of history doesn't seem like a good solution, but it's not my call. jbrjake, when you leave someday (and you will - we all will), if there isn't someone to 'backfill' for your code, the project team left behind will face exactly the same problem magnified many times over. Solve for that, and the Qt GUI isn't a problem anymore.

Rodney

[gonza]

Hi all,
The Qt GUI code is still being developed, but I will admit rather slowly. I have enabled libdvdnav and added the appropriate configuration options for it.
Saving custom presets now works, and the whole saved encode feature is working very nicely.
I'm currently looking into changes so the presets can be easily imported from the Mac GUI (and should also work with the gtk GUI).
The new anamorphic changes are also on the list of things to do.

Anything else you would recommend? At the moment I'm just fixing the things that affect me first, but if anyone has any preferences I'd happily work on something else.

At the moment I'd say the code is quite stable and definitely ready for people to test/comment/patch. Not yet in svn, so see the first post of this thread for instructions on where to get it.

Cheers

[hunterk]

Glad to hear it's still coming along well.

If any Kubuntu/Ubuntu users want to try it out without compiling it themselves, I have working binaries in my PPA repository: https://launchpad.net/~hunter-kaller/+archive/ppa

[s55]

Hunterk please don't call them 0.9.4. They are not version 0.9.4! They need to be named to the SVN rev that they were built on.

You have no idea how many problems this sorta thing causes us.

[hunterk]

Right. As I understand it, the Ubuntu naming convention relies on the ~ppa[number] to denote that it's less than the actual version number (in this case, 0.9.4). It's confusing, but I don't mean that they *are* 0.9.4, but rather that they are between 0.9.3 and 0.9.4 (i.e., dev code). When an actual 0.9.4 release comes out, the package manager *should* automatically supersede these packages when they're encountered.

Edit: to further clarify, if I were to name them, say 2268svn, I believe the package manager would see those as version 2268.0.0 and, if someone were to try and install the real-deal 0.9.4 from you guys at a later date, it would throw up an error about it being "an older version than the currently installed version."

I've included notes in the packages expressing that they are not supported by you guys, as they are unofficial builds from unstable code. I've also included the svn checkout version in the changelogs to further clarify which versions they are (though I know not many people read changelogs...).

I did these things to stay as closely in-line with official Ubuntu packaging rules as possible, but if you guys prefer it, I'll switch to a different process.

[s55]

I feel it's misleading to use a version number in a file. Users generally don't read anything. They'll see 0.9.4 and get the wrong impression.
Ideally use svnxxxx or xxxx in place of 0.9.4


I really don't get why these package systems are designed to make life so difficult for developers. (not blaming you of course)

It would also be ideal not to have this in the official ubuntu repo. It's too early at this stage to be doing this. Not fussed over the unoffical binaries.

[hunterk]

That's cool and I totally understand where you're coming from. I'll switch to the svn number in the name instead.

[s55]

Thanks