Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#8698 closed enhancement (wontfix)

VLC should look for config into its own dir at start

Reported by: rsk82 Owned by: courmisch
Priority: normal Milestone: Features paradize
Component: Core Version: master git
Severity: normal Keywords:
Cc: Difficulty: unknown
Platform(s): all Work status: Not started

Description

The idea is implemented in many programs now, I found it for example in windows version of vim and other unix native apps.

So it should be like it: VLC starts first checks if there is a file of a name vlcrc in its own directory so for example C:\Program Files\vlc\vlcrc, if it's found then load it. If not (as it is default) then fall back to c:\Documents and Settings\Username\Application Data\vlc\vlcrc. It would be great help for testing multiple version. So then I can download nightly builds from several days and test every of them with different settings and not mess with my default stable installation.

Now if I copy vlcrc file to VLC dirs it stays ignorant of it. And yes I know that I can put a command line parameter (--config=vlcrc), or make a shourcut or bath file but then it becomes cumbersome and unelegant for example with *.cmd file and console popping up of with fact that when I move the dir with vlc such shourtcut must be corrected for that since it not supports relative paths.

Such change in the code should be most trivial of all possible features and I wonder why no people has suggested it at the beginning of the project. Anyway If I put a config file in a *.exe dir that is obvious I want the program to get interested in that file.

http://forum.videolan.org/viewtopic.php?f=7&t=111091

Change History (14)

comment:1 Changed 2 years ago by courmisch

  • Component changed from Unknown to Core
  • Milestone changed from Bugs paradize to Features paradize
  • Owner set to courmisch

There is no warranty that the system configuration directory is writable. Besides, multiple users should not be forced to share the configuration.

VLC may gain support for system-specific defaults, but configuration file in the installation directory is not going to happen.

comment:2 Changed 2 years ago by courmisch

  • Resolution set to wontfix
  • Status changed from new to closed

comment:3 Changed 2 years ago by rsk82

I don't get logic behind this. If the directory is not writable then not write to it. In 99% of cases it will be and if wont simply fall back to default behavior. And what is system directory ? What do you mean ? I meant the directory that vlc.exe sits in. It's not the system directory, it might be "program files" but in fact it can be anything that user wants it to be. This has nothing to do with system.

Second. I don't want that the config file would be in program dir as mandatory. It is for advanced user choosing, for people that know what to do the rest would not even bother where the config file is. I do not see forcing anyone to do anything here. The forcing happens now by defaulting users to standard paths to config files.

And why feature that is in gvim cannot be in vlc, I bet they discussed about it also. No I don't get this logic.

comment:4 follow-up: Changed 2 years ago by jb

Then use the --config parameter

comment:5 in reply to: ↑ 4 Changed 2 years ago by mederi

Perhaps a "vlc.ini" near "vlc.exe" for customization of basic behaviour of VLC: Normal = default. / Auto = If not VLC dir, then normal. / Portable = VLC dir only. / No config files at all.

config_path = "%appdata%\vlc" / "auto" / "VLC dir" / "nothing"
menu_language = en
...

comment:6 Changed 2 years ago by rsk82

@jb: if so why can't this by made default behavior as-if that switch would be always on start. It would not force anything on nobody. Ok, I've checked it now and it would need some changes in logic of this command... now when config file is not present it is created. If there would be a command like --config vlcrc --config_default %APPDATA%\vlc\vlcrc . So if first do not exist look for second if second do not exist create it. And then put it as default command if no params was provided by the user. And we're done.

Using parameters when starting application in windows ic cumbersome one must create a *.cmd (ugly console flickers) file or do it from a launcher (you must remember to click the launcher) or from shortcut, but windows shortcuts do not accept relative paths, so when you move folder with the app it breaks or opens other version if you moved it in the place of old app.

@mederi: I don't think there must be an ini file, it's not bad but the sole presence of anything that would indicate the executable that user don't want it to mess with the user data folder is sufficient.

(You realize that big % of people use the "VLC Portable" from portable apps and confuse it with your original app ? Many developers (FOSS or shareware) now implement portable option in their apps since they see that majority of their users suddenly are using some kind of wrappers that enable portability. Now there is a whole genre of "pirated" software done with intention for enabling software being run from usb. There is whole movement of sites and people that are dedicated to this issue but many developers seem to be ... idk... don't understand ? dont want ? don't care ? I understand someone who does paid app and license is per computer and don't want people to be easily copying their work, but such attitude in open source ? So don't you think instead of telling people not to use VLC Portable you should do something about it ?)

comment:7 Changed 2 years ago by mederi

http://portableapps.com/apps/music_video/vlc_portable
I did not know about it. Going to test it.

comment:8 Changed 2 years ago by jb

VLC Portable patches badly VLC. And violates the GPL. Sorry, I'm not interested in working with those guys.

comment:9 follow-up: Changed 2 years ago by rsk82

@mederi: there is no difference in terms of user experience between portable and official versions of VLC, all the difference is a way in which both apps store their settings. The whole case with portableapps.com is that developers can't get to their mindset that there is a large group of people who want these feature of storing settings within app code and not interfere with system registry or other resources like creating folders or files in system structury (but ok to read them), that is concept of "portable and stealth". What they do is a simple wrapper... I don't know if they recompile your code. After I download their app I can download yours latest nightly put it instead of their bundle and it will work. This is nothing diffrent of application virtualization concept. And they are doing it for apps that do not need such treatment like http://portableapps.com/apps/development/gvim_portable but you go to http://sourceforge.net/projects/cream/files/Vim/ extract exe with external unpacker that is bypass normal installation procedure and put vimrc into program dir and it works. Why VLC couldn't have feature like it ?

The second thing is that you are misleading people about portablility of your app by providing zip and 7zip packages here: http://www.videolan.org/vlc/download-windows.html it is assumed when software is distributed without installer it doesn't put his configuration with system resources. There is plenty of apps with portable version not named but implied by way of delivery that is exe or packed user extractable. Even with installers they are aware when user tries to put the program if it is USB key there is setting enabled for not storing settings in system directories.

So jb, there is no need for "working" with those guys there is nothing from their side that you need be concerned of, they write only wrappers for apps and if violate GPL in some way sure is that not only with your project.

comment:10 in reply to: ↑ 9 Changed 2 years ago by jb

Replying to rsk82:

The second thing is that you are misleading people about portablility of your app by providing zip and 7zip packages here: http://www.videolan.org/vlc/download-windows.html it is assumed when software is distributed without installer it doesn't put his configuration with system resources.

This is a lie. We're not misleading anyone.

Those versions are version without installers. Noone said they install configuration in the same folder.

Moreover, YOU assume that version without installer do not install in system resources...

There are very valid reasons why some settings are per Machine, and not per user or per install, like qt-interface settings and fontconfig...

comment:11 follow-up: Changed 2 years ago by rsk82

@jb: It depends what "mislead" means. Of course you're not blatantly lying. Im not saying that. The download section misleads by convention. People are accustomed to that if package is self sufficient like zip file, that there is no additional logic for placing it contents on the system it is implied then that such operations won't be performed by the software inside. It's not a written rule, nobody says it must be that way but it is suggestive situation that's all. Installers exist for a reason and reason is that the changes in system required to software be running are cumbersome for inexperienced users to put out by hand. So if you provide package without such logic it suggest that said logic is not needed. And my assuming of that behavior is based on my experience that most software do it that way. There are few (as here) that do not.

Next. I do not know what qt has to do with this, this lib is bundled with vlc and should not have common settings with other qt installations on the system. We're past this time when disk space was precious. And if there will be a setting when user runs the software from usb on another sytem and said OS hasn't got the font it's trivial to implement some ifs and fall back to some default font.

@courmisch (from first post): if directory is not writable then there is no possibility that config file would be inside, if system policies are preventing creating config files in "Program Files" dir there will be no file to talk about. And if user puts itself a config file then it will be readable but not writable, in such case vlc informs user about that right now without any unpredicted behavior.

There could be even cleverer twist, VLC could check if it is in system "Program Files" and if so prevent from loading file from it's dir assuming that it is followin default system pattern if not do as I suggest in this ticket.

comment:12 in reply to: ↑ 11 Changed 2 years ago by jb

Replying to rsk82:

@jb: It depends what "mislead" means.

Blabla. You're attacking us on YOUR assumptions.

VLC works fine from the .zip, it just writes what it needs in %appdata% folder.

Next. I do not know what qt has to do with this, this lib is bundled with vlc and should not have common settings with other qt installations on the system.

Look at the vlc qt settings file. It depends on the screen size and so on. It is not portable between machines...

comment:13 follow-up: Changed 2 years ago by rsk82

@jb: It is you that used unintelligible word first in this discussion.

Forbidding user to to change this behavior of writing to the %appdata% folder and forcing per-machine settings is not "working fine".

Second. Screen size can be verified at every start from system api, there is no need to trust this setting from config file. How is that if I delete all VLC settings and it starts just fine ? How the program knows even how to run ? If that's so this configuration is not crucial to the extent it must be bundled with system.

comment:14 in reply to: ↑ 13 Changed 2 years ago by jb

Replying to rsk82:

Forbidding user to to change this behavior of writing to the %appdata% folder and forcing per-machine settings is not "working fine".

Noone is forbidding anything. We have this --config option exactly for that.

Second. Screen size can be verified at every start from system api, there is no need to trust this setting from config file. How is that if I delete all VLC settings and it starts just fine ?

You have no idea what you are speaking of, sorry. What about font cache? Those settings must stay per machine, and not per user. Even if you don't like it.

Note: See TracTickets for help on using tickets.