VLC.app Directory Path

[Peter]

I am new to this forum as well as to HandBrake. Today is the first time I launched it. After searching the WIKI, I realize that HanBrake is coded to recognize VLC.app, only if it is in the root of the "applications" (Mac) folder.

I'm one of those people who likes to use sub-directories to organize my applications, combined with FruitMenu, or even ClassicMenu, I can easily find things like; communications; multimedia, system utilities, disc utilities, and so on, when they are grouped in in such sub-directories. Hence, being forced to keep apps in the Applications:root directory is contrary to the organizational habits I have.

As I am not yet qualified to tweak the code, perhaps someone more familiar with the source code could assemble a standard GUI to map the path to the VLC.app when it is kept in a sub-directory of the Applications folder? I'm sure there are a lot of users, especially newbies, who would find this addition extremely welcome, and from my past experiences with programming, I think it is a relatively simple sub-routine call.

I am posting this to the "Bugs" topic because I presume anyone interested in debugging is also writing code.

My best to you all. And, thank you for making HandBrake possible. I love open source, but am just now learning Unix.

Peter

[s55]

This requires integrating VLC more tightly with HandBrake and we are not prepared to do this. In other words, it won't happen.

There is a patch kicking around the development forum that allows this (Not sure if it'll still apply cleanly) for those who can compile code and work out issues with old patches that may not apply cleanly to the current SVN repo.

[jbrjake]

This is *not* a bug.

[nightstrm]

Moved.

[diamondsw]

This IS a bug. If you can't locate VLC (installed, but moved elsewhere at the user's discretion), that is your bug. VLC does not have to be located at /Applications/VLC.app . This is not Windows, this is not Linux - hardcoded paths have no place here.

There is likely a supported way to locate an application by its bundle ID (org.videolan.vlc) using LaunchServices, but in the meantime this will work in 99% of scenarios:

Code: Select all

locate VLC.app | head -n 1

On my system, this yields:

Code: Select all

/Applications/Extra/VLC.app

If it doesn't find it, fall back on the default location.

Oh look, five minutes of GoogleFu located this:

"The Launch Services function LSFindApplicationForInfo locates an application based on its name, creator signature, bundle ID, or any combination of these characteristics. "

The API call is detailed here.

But do not tell a user who is reporting incorrect behavior that it is not a bug. VLC is installed, but your app claims it's not and refuses to use it. Your app is wrong.

[s55]

VLC being hard coded is by design. This is not a bug.

This has *already* been explained several times.

Take your attitude problem somewhere else.

[realityking]

Guess what, the devs found that info too. The problem is that when you have multiple copies of VLC on your system it seems like one copy is randomly selected wich is not desired, that's why the devs chose to use a hardcoded path.
Since this is an open source project feel free to patch it yourself, but you have next to no chance of getting it into SVN.

[s55]

There is already a patch. http://forum.handbrake.fr/viewtopic.php ... 579#p52095

It's not going in.

[diamondsw]

VLC being hard coded is by design. This is not a bug.

Okay, I can't say I really understand this. First of all, which is the more common case:
1) Users with multiple copies of VLC
2) Users that moved their copy of VLC (because having 100+ apps in one folder doesn't scale at all)

Beyond this, why is it a bad thing to "pick one at random"? Why should I care what copy of VLC you're using? It's a utility being used behind the scenes. It could be in /usr/local/wtf for all I care.

Or when you don't find it, you could offer to let the user find it. That way they get to keep it where they want, you always get the same copy. Not as good as doing it silently and seamlessly, but better than a misleading error message that it's not installed.

This issue has clearly come up before, based on the hostile response. Perhaps the fact that it keeps coming up indicates that it's a somewhat frequent issue that many people are running into? I point out the code that would fix the problem. Others submit a patch. And the response:

Since this is an open source project feel free to patch it yourself, but you have next to no chance of getting it into SVN.

Oh yes, I really want to contribute now.

[diamondsw]

There is already a patch. http://forum.handbrake.fr/viewtopic.php ... 579#p52095
It's not going in.

As has been said before, this won't change. We don't want to tie VLC more deeply into HB.

Based on what I've seen in other threads (that this is tied into "libdvdread, libhb and the gui"), seems like pretty poor factoring to me. If you can load it from hardcoded location "X", you should be able to load it from user-specified location "Y". Maybe this is a nigh impossible feat for you to accomplish, but it sounds like you've coded yourself into a corner of your own making.

Meanwhile, your forum search feature is broken when searching for "VLC", "VLC.app", and several other similar searches returns nothing, despite evidence to the contrary. So don't blame your users for not finding your other threads when search doesn't work in the first place.

Take your attitude problem somewhere else.

Oh yes. My attitude problem.

If having vlc in your /Applications folder is just so painful you cannot bear it, then I guess prerip your stuff or use Fairmount. I mean for cripes sake, its not like we chose some obscure directory where 99% of the people would not likely have it anyway. Get over it.

You have absolutely no f u c k i n g clue what you are talking about.
Here, again, since you are apparently too lazy to search, is the patch that would be required to achieve this functionality. How in God's name is this not tying VLC's libdvdcss more deeply into HB?

[dynaflash]

Of course its not impossible. Don't be ridiculous. It more a matter of a decision made by the project devs. jbrjake showed exactly why we do not *want* to do it (obviously we *can* because he shows the patch).

I suggest you quit gnawing on this old bone. All projects have parameters they set, period. This is one of those parameters.

I have to say I am constantly amazed at what big deal it is to have vlc.app in your root applications directory for some users. Of course thats only if you want to read encrypted sources, preripping or fairmount is always an option as well. Just let it go.

[caek]

I have to say I am constantly amazed at what big deal it is to have vlc.app in your root applications directory for some users.

It's not a big deal for me. It's simply impossible. I can't put VLC.app in /Applications because I don't have write access to that directory. I don't have admin privileges. Macs have become common in academic/corporate environments, and this is not as rare as it used to be.

[JohnAStebbins]

A suggestion from the #handbrake irc logs

[KonaB2end] k so without patching dvdread,
*** dynaflash scrolls through buffer
[KonaB2end] in your home directory, mkdir "lib"
[KonaB2end] copy VLC's css.dylib in there.