Mac GUI for 0.7.1 SE Thread

Archive of historical development discussions
Discussions / Development has moved to GitHub
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Post Reply
dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Mac GUI for 0.7.1 SE Thread

Post by dynaflash »

Edited for 0.7.1 SE According to Roadmap on Trac.
Just wanted to start a thread related to the mac HB gui for our new plan according to the latest developments in the "Roadmap to 0.7.2" thread. So, if we are basing the HB gui on svn rev 48 (which I think jbrjake suggested and seems like sound reasoning) , the existing m0k gui (0.7.1 gui) is broken in a couple places (namely ScanController) as well as still retains the "/rdev/rdisk" in the menu to select an optical drive even when it works (this exists in 0.7.1)

So, I am working on retrofitting the existing m0k gui with our fixes as well as propose that we go ahead and introduce a couple of improvements.

I went ahead and provided some screenshot to hopefully stimulate some ideas and thinking along these lines. Everything in the screenshots is totally wired up and functioning great.

The fixes are in my UniGui, dont get excited :) , I am not saying we use that gui, the fixes and features I am suggesting are totally compatible with the existing m0k gui, this is jut the one i had wired up so I am using it for demonstration purposes.

Fixed initial selection if there is no physical dvd detected (in our existing revs, file field is selected, but so is the dvd checkbox at the top):

Image

If there is a disk present (or one is inserted while the scan panel is open) disk selection is activated (as is currently the case, lets use the dvd name instead of the "rdev/rdisk" or whatever is in the current m0k gui):

Image

Couple notes on this one, as we currently are, use the dvd name in the "DVD" field, also instead of the m0k default output movie name "~Users/...Movie.mp4" use the dvd name as the default and, I got tired of changing the .mp4 extension to .m4v for itunes friendly files, so I created a pref which changes the output file name extension for Mpeg4 files according to the users choice.

Image

Here is the prefs pane. There are some prefs here that are likely not to be in this release obviously (jbrjakes Constant Rate Factor, Advanced on Launch is only for UniGui, etc), but they work well. Maybe we decide to keep "Use iPod/iTunes file extension..." and pri's Default Audio Language.

Image

Anyway, just wanted to get some thoughts on this. Again, the fixes/mods here discussed here regress nicely to the 0.7.1 m0k gui.

Note: once we get a branch or figure out what we are doing with the svn to address this potential release, I can submit a modded 0.7.1 gui into the svn.

Thoughts/Ideas/Criticisms ?
Last edited by dynaflash on Sat Jan 20, 2007 3:07 am, edited 1 time in total.
prigaux
Regular User
Posts: 94
Joined: Mon Jan 01, 2007 3:25 pm

Post by prigaux »

Seems to be cool, create a branch in the svn for that :)

Phil
dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Post by dynaflash »

Just checked out a clean copy of rev 48. HB gui not an issue. But, remember, back then, IHB was called "Handbrake Express" and I think was quite a bit behind what was officially released as "Instant Handbrake".

My point is, I think that the binary download of Instant Handbrake that everyone is using is likely, from a quick scan of the svn, up closer to rev 69 well after libmp4v2 -> libavformat switch. There were several other changes after that to get to the public Instant Handbrake distro.

So, in the final analysis, if we are going to also release a 0.7.1SE Instant Handbrake, I think there will be alot more work to be done there to get svn rev 48 up to speed with where the current public IHB is.

Now I am to thinking, if its true that the currently distributed IHB from the m0k site is from an svn rev well past the point where we think the mem leak developed, shouldnt that binary exhibit the same leak? And if so, why hasnt anyone complained? In other words, the leak we are so worried about should already be present in the widely distributed m0k IHB?
prigaux
Regular User
Posts: 94
Joined: Mon Jan 01, 2007 3:25 pm

Post by prigaux »

Well, for me the memory leak doesn't keep me from using our last SVN version (trunk) and it runs very stable...

So I don't think that it is very critical...

Phil
dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Post by dynaflash »

Apparently the many people out there using IHB from the m0k site dont have a problem either.

Not that its technically okay, I just wonder how we should handle this for the SE release, my test from the m0k IHB binary that everyone has downloaded exhibits the same mem characteristics as our trunk does.
prigaux
Regular User
Posts: 94
Joined: Mon Jan 01, 2007 3:25 pm

Post by prigaux »

I think we should release stable running versions, but underwood technical problems (such as speed up, memory management, etc..) must not be an "handbrake" for version release.

One thing I see is that we should change the name before releasing anything to avoid confusion..

Phil
Post Reply