Unified GUI Interface

[johnallen]

Now that HB is build on Windows, maybe we should consider unifying the HB and IHB interface and make is cross-platform.

I've been doing some reading on java JNI. JNI is the java answer to .Nets PInvoke. This gives us the ability to have one GUI for all platforms, and the HB lib built for each platform seperately.

One issuse I've found during my reading:

JNI does not work with static libs (this is what we currently build). JNI wants dynamic libs. We could probably overcome this with some mods to the JamFiles.

Anyone else have thoughts or interests in this?

[rhester]

Just plain, random, hopefully-not-discouraging thoughts:

- Shared libraries = DLLs on Windows. Oy.
- You now run the very real risk of a disconnect between GUI and library - what happens when they get out of sync for some reason? How do we easily diagnose that?
- It's a lot to bite off. Sure, I'd love to see a Windows GUI too, and a cross-platform one would certainly be ideal, but I think I'd prefer to see solutions to sticker-but-less-visible problems like the "100% hang" or the "mystery 1-second-short-track" defects myself.

Then again, what makes open source thrive is people working on what interests them - so if this is your bag, in complete and total sincerity, go for it. =) I'm sure we'll all be impressed by the results.

Rodney

[johnallen]

You raise some good points. The 100% hang thing is killing me. Personally I usually start the rip at night and come back in the morning. So by the time I get back to it. It's done. Of course I can imagine for those people who are "watching the water boil" as it approaches 100%, probably hate us for not fixing the problem.

I am going to tackle this one myself. (maybe I'll get to a java GUI later).

[s55]

I'm going to release the source to my gui for u guys to play with as soon as i finish the recode. It's done in vb.net which isn't ideal but at the time i started it was the best option. ( basically i was too lazy to write a java gui as there is alot more work involved. )

THe current code for GUI 1.6.2 is rather messy atm and would probabily just confuse the heck out of u.

It would be great if we could get better integration with handbrake as atm it just sort of sits on top of it and reads off the data

If u havn't seen it. Link Removed No longer available is the link.

over 3200 downloads since 17/12/06

I sorta wish i had used java from day 1 but meh, its done now and i cba rewriting everything in java.

[mirkwood]

One issue with a Java GUI is that you now have to maintain 2 interfaces, the libhb API and the JNI API.

Another option would be a wxWidgets GUI, written in C or C++. wxWidgets is a cross-platform GUI library available for many languages. But since libhb is in C, writing the GUI in C/C++ will make it easy to use libhb. Unfortunately I don't know how many good, maintained, wxWidgets GUI builder/IDE's exist (there is at least one GUI builder for Windows though, but I haven't used it). I mean you don't need a GUI builder, but it makes it easier.

I think the dynamic library issue can be dealt with as long as you ship the library with the GUI and perferably make it so that the GUI always loads the library from the directory where the GUI was installed. So if you're into maintaining a JNI interface (maybe it isn't all that hard) then go for it!

But let's please make sure that the HBTest CLI interface doesn't fall behind the curve as much as we can.

[dynaflash]

Now that HB is build on Windows, maybe we should consider unifying the HB and IHB interface and make is cross-platform.

Okay, I am in no way intending to step on any toes here, but, it seems to me, that the obvious thing to do is incorporate a "Basic" and "Advanced" setting into the HB gui where "Basic" is really IHB and "Advanced" has every thing that the current HB gui has (and more ie. jbrjakes advanced h.264 etc.).

Personally, it makes sense in my mind at least, to start with the HB gui and add the IHB features to it as IHB is much simpler and frankly alot less work.

Throw an if/else into Controller.mm PrepareJob function and we are good to go (of course, am sure it will not be quite that simple, but you know what i mean)

Benefits:
One app for all HB users.
Mundane dev stuff (versioning, build testing, etc.) easier with just one target.
Easier to maintain.

Drawbacks: (you guys feel free to insert here).

Anyway, just my vision and my .02 cents worth.....

[rhester]

Now that HB is build on Windows, maybe we should consider unifying the HB and IHB interface and make is cross-platform.

Okay, I am in no way intending to step on any toes here, but, it seems to me, that the obvious thing to do is incorporate a "Basic" and "Advanced" setting into the HB gui where "Basic" is really IHB and "Advanced" has every thing that the current HB gui has (and more ie. jbrjakes advanced h.264 etc.).

Personally, it makes sense in my mind at least, to start with the HB gui and add the IHB features to it as IHB is much simpler and frankly alot less work.

Throw an if/else into Controller.mm PrepareJob function and we are good to go (of course, am sure it will not be quite that simple, but you know what i mean)

Benefits:
One app for all HB users.
Mundane dev stuff (versioning, build testing, etc.) easier with just one target.
Easier to maintain.

Drawbacks: (you guys feel free to insert here).

Can whatever language the "mm" files are in on the Mac be compiled and have runtime support on Windows, Linux, etc.? If not...small drawback, given one of the proffered requirements above is cross-platform compatibility. =)

Rodney

[s55]

Ok, well can we make a decision here because there is no point in me re-writing my GUI if were gonna end up building another from scratch...

The way i see it we have 3 options.

a) write something new from the ground up
b) take what we already have and bring it up to spec in comparison to the the OSX GUI. It does actually appear that you can run .Net 2 Applications under Wine with a few hacks. (bit of a disadvantage to linux users although theres no reason you can't port the macos GUI or write 1 for it i guess.) How many users actually use Linux? OSX and Windows seems to be our main OS Versions so thats were i recon we should concentrate. I'm not saying ignore linux by any means.
c) run for the hills.

[prigaux]

Perhaps should we play with the jamfiles to build the libhb as a dylib (dll, dylib and so) so one could use the dylib in any language.

ie realbasic can output put executable out of one code to windows, linux and even mac os-x

My 2 cts..

Philippe

[dynaflash]

maybe we should consider unifying the HB and IHB interface and make is cross-platform

My mistake, my mind blanked out the "cross-platform" I now realize when we say that, we are talking Linux, Mac, Windows. My bad. I was just referring to the act of unifying HB and IHB Mac GUI.

I agree that with all of these targets, things are getting complicated. Heck, mac alone has three different HB experiences: HBTest (CLI), HB, IHB. It is getting a bit cumbersome to be sure.

I think should really consider a short term goal, and a longer term goal. I really feel that , at least for short term (public release), sr55's "b" option is best.

I do think we try to get down to just one gui per platform. I don't have much experience with it, but I think that one gui codeset to provide a great gui for both Windows and Mac is going to be a steep hill to climb, to be sure.

Sounds like sr55 has a good handle on the Win gui, and I think we are close on the mac gui (remember, short term, public release).

I think this may be a good time to initiate some discussion of a roadmap for the the next release as well as longer term goals, etc.

Now that I look at it, sr55's option "c" might be the best bet !