$XDG_CONFIG_HOME support

[etosan]

Hello,

some of us are pretty anal about having their $HOME as clean as possible.
I know this is pretty controversial topic, but as PaleMoon is aimed at power users and some power users like to be anal, I would like to know if this profile storage scheme could be supported.

Eg. PaleMoon would check for existence of it's dirs in $HOME first, then in $HOME/.config and finally in $XDG_CONFIG_HOME. Whichever is found first wins.

[Moonchild]

but as PaleMoon is aimed at power users

I think you're assuming things, here
The fact that a larger percentage of the Pale Moon user base is above average IT-savvy doesn't mean Pale Moon is aimed at power users.

If you're being "anal" about things, then you're going to have to adjust your handling of software.
i.e.: Use Pale Moon's profile manager to put your profile in a different location, or use the "-P {profile}" command-line switch in your shortcut to always use a specific location, and your problem of "wanting the profile somewhere else" is solved.

[Night Wing]

Off-topic:
I've been using Pale Moon for a over three years now. Started with Windows Pale Moon in October of 2011 and and then after dabbling with some linux distros in November of 2012 (because of Windows 8 which I despised), began using linux Pale Moon when it was officially released last January of 2014. I'm no power user and I seriously doubt I'll ever be one either. I just consider myself a non technical computer user.

[etosan]

I think you're assuming things, here ;)

Sorry. Yeah, I made mistake with that assumption, I was wrong :D.

Use Pale Moon's profile manager to put your profile in a different location, or use the "-P {profile}" command-line switch in your shortcut to always use a specific location, and your problem of "wanting the profile somewhere else" is solved.

Actually I am using that switch already in my shell aliases, but as far as I know it it references profiles under "~/.moochild productions/pale moon/". Did you mean -profile instead?

Well anyway although I don't like freedesktop.org standards very much, I do think "~/.config" is one of few good ones. I also noticed many software authors have extreme problems with it, why is that? It's just several lines of code to add, and even mere user like me understands that. Hell there are several locations even on various windows versions. The point I want to make is that with proliferation of fedora tech and their standards aka gnomeos, "~/.config" is here to stay, so in that case I suggest: let's make use of it!

Palemoon would then store it's data in "~/.config/moonchild productions/pale moon" like other "modern" programs do. In case user has old dirs present, it would just use those.

Or that is 100% no go Moonchild?

[Moonchild]

~ is the normal place to store user data. A browser profile is much more than configuration (which is what the .config name suggests is stored there) so putting it in ~/.config sounds illogical.

You're also simplifying things -- using multiple default locations for a user profile is not by any means trivial if the program has not been designed to handle multiple default profile locations. Also, contingencies: what is a good priority rule? What is a user prefers home over .config? What if both exist? What if a partial profile is found in a higher priority location and a full in a lower priority one? etc. etc. -- that's not "just adding a few lines"...

I'm not saying it's a definite no-go, but I'm also not seeing this change any time soon. Exchanging ~ for ~/.config is still putting it in home, just in a hidden subdirectory, instead. Pale Moon's folder is already hidden, as it is, so for normal use there would be no difference at the surface and no clear gain from adding a lot of complexity. As said you can already specify profile location from the command-line, and yes, that would be path based with -profile, not name-based, if you are insisting that Pale Moon does not use a location directly under home.

[etosan]

Well priority ordering is defined here http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html.

Also I run regularly with multiple profiles using -no-remote plus -profile directory option.

The thing is, PaleMoon like all Mozilla based browsers still goes on and creates "~/.moonchild\ productions" ("~/mozilla" in case of mozilla browsers) so I was hoping to get it under the "~/.config".

Of course you won't be first developer oposed to this spec. From my observation it's actually quite common to not do this. More "hip" projects switch over, less "hip" ones will defend their right to store watever "~/.dotstuff" in users home as they see fit.

I am okay with your decision, anyway you decide, I just hoped I could get one less .folder in my home. That is all. Thanks for consideration.

[Moonchild]

It sounds to me like what you are looking for is a corporate setup. It has nothing to do with being "hip" or not, it has also nothing to do with being opposed to a de facto standard. You have to understand that that kind of configuration and handling of profiles is akin to treating those Linux setups as a different operating system, because you're asking for a special treatment of the default storage locations on Linux. In turn, that means (a lot of) added complexity for something that can already be done with current configurations and options and isn't considered worth the cost of creating and maintaining for each update.

it may be easy to do for smaller applications, but not something as big and complex as a Mozilla based browser that has a lot of asynchronous access and locking mechanisms in the profile. The profile location is used in many places and overrides are already in place even if not available as default. It might be possible to do what you want, but it's not a simple "change a few paths in the source" to accommodate for it.

You should look into corporate configuration, using e.g. mozilla.cfg, a custom .ini file with -app or an automated way of always initializing with a specific -profile. If set up properly, nothing will be created in ~/.moonchild productions
Note that you need to configure all path locations properly if you want to avoid creation of the directory, including cache location and the likes.