aMule Forum
English => Feature requests => Topic started by: Fabioamd87 on July 26, 2010, 05:02:33 PM
-
what about store .aMule config folder in .config?
-
Convince wxWidgets developers that it's a good idea to return ~/.config/appname from wxStandardPaths::GetUserDataDir().
-
tell me if is ok: http://wxforum.shadonet.com/viewtopic.php?p=123020#123020
-
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. :(
-
you think is possible to obtain that change?
-
I'm doubtful. :-\
-
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.
-
yes, but no change no progress.
-
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.
-
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() (http://docs.wxwidgets.org/stable/wx_wxstandardpaths.html#wxstandardpathsgetuserdatadir) 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?
-
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.
-
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.
-
I sincerely can't see the point in this feature..
-
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
-
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.
-
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.
Yeah. And what if there is data in both places? And what if the user tries the new version (which moves the data), dislikes the new gui and rolls back to the old version? And who will answer the zillion new help threads about that?
So, placing "Incoming" into ".aMule" is wrong and violates every HIG in existence.
Funny, you never seemed to care while you were a dev.
I sincerely can't see the point in this feature..
This sums it up pretty well.
-
So, placing "Incoming" into ".aMule" is wrong and violates every HIG in existence.
Funny, you never seemed to care while you were a dev.
Everyone and his priorities, shell we?
aMule GUI and overall "user experience" is awful, but since I used daemon and can use shell, I didn't care then and don't care now. So, it's only "FYI".
-
please save amule config in .config.
-
Oh well, now that you said please we'll surely do it.
-
You'd even give him your clothes, your boots and your motorcycle, huh?
-
I may even throw in a bottle of wine.