Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Fabioamd87]

what about store .aMule config folder in .config?

[GonoszTopi]

Convince wxWidgets developers that it's a good idea to return ~/.config/appname from wxStandardPaths::GetUserDataDir().

[Fabioamd87]

tell me if is ok: http://wxforum.shadonet.com/viewtopic.php?p=123020#123020

[Stu Redman]

I think that board is about coding with wx, not coding wx itself. Wx take all change requests only through their bugtracker afaik, which is a nuisance. 

[Fabioamd87]

you think is possible to obtain that change?

[Stu Redman]

I'm doubtful. 

[GonoszTopi]

you think is possible to obtain that change?

Just think of backwards compatibility. It's rather annoying if a program suddenly starts to look for its config in a completely different place, without a word.

[Fabioamd87]

yes, but no change no progress.

[Vollstrecker]

We could let it look at the old place, and if it finds it, move it to the new location. And most important: Tell the user that we did.

[GonoszTopi]

We could let it look at the old place, and if it finds it, move it to the new location. And most important: Tell the user that we did.

Sure we could. Right now we use wxStandardPaths::GetUserDataDir() to find out the location to store everything.

From our side, we'll have to decide for each file we currently store in ~/.aMule whether it's a "user specific configuration file" or not, and in the latter case store them elsewhere. And this decision is not always easy. For example, should preferences.dat be considered a config file or not?

[Fabioamd87]

imho we should just move the whole folder aMule into .config, because for example if we move .part file in .cache file, it can be considered deletable, but it isn't.

[Vollstrecker]

The only problem I see, or better the only decision I would make, is where to place the temp and incoming dirs. Everything else can be considerred as config file.

[franz1789]

I sincerely can't see the point in this feature..

[lfroen]

The only problem I see, or better the only decision I would make, is where to place the temp and incoming dirs.

Groundbreaking news: files (or directories) starting with "." are considered "hidden" on *nix systems; user is not expected to look there. So, placing "Incoming" into ".aMule" is wrong and violates every HIG in existence.

But, oh, I forgot ... aMule don't care about stinky HIG

[Vollstrecker]

The only problem I see, or better the only decision I would make, is where to place the temp and incoming dirs.

Groundbreaking news: files (or directories) starting with "." are considered "hidden" on *nix systems; user is not expected to look there. So, placing "Incoming" into ".aMule" is wrong and violates every HIG in existence.

So no news.

But, oh, I forgot ... aMule don't care about stinky HIG

So no decision to make. Let's make the changes to satisfy a standard we don't really care about. Let's change a running system, let's fix what's not broken.

But seriously, it can be done (technically), but would it change something? Where's almost in line with LSB, and we're almost in line with POSIX, xdg is maybe a benefit for apps that are designed from start, and maybe a benefit for apps that need or want to share their config with other apps for a reason I can't imagine. And IMHO we can benefit from some tools and technics xdg provides, and I still wait for 3.0 to start implementing some of these I think of they would be a benefit, but implementing this wouldn't change anything.

All apps that need to use the configs, are part of our source. All apps that want to use our configs, have to use them where we place them. Not talking about cas or plasmamule (maybe fileinfo, too), that don't use the headers that implement the filepath saerching and would need to be adjusted additionally.