Amazingly screwed-up installation experience
-
@morbiuswilters said:
@anotherusername said:
@morbiuswilters said:
Your statement is the exact opposite of awesome. For example, when I want to go to TDWTF forums, I simply type "for" into Chrome and it auto-completes to the full URL. Simple.
Do that in Firefox and it's going to give you 500 nonsense results.
Just for fun I tried that in the Awesome Bar. I typed "for" and sure enough, there was "ums.thedailywtf.com/" up there, highlighted, waiting for me to hit enter.
You haven't been searching for Fords, forests and chloroform, then.
Preparing to take your "girlfriend" for a camping trip in your pickup truck?
-
Here's your random "revert a change done by Mozilla to restore Firefox to baseline usability and prevent it from fucking shit up" tip for today.
1) about:config
2) browser.urlbar.trimURLs = false
You're welcome.
-
@Lorne Kates said:
Here's your random "revert a change done by Mozilla to restore Firefox to baseline usability and prevent it from fucking shit up" tip for today.
1) about:config
2) browser.urlbar.trimURLs = false
You're welcome.
Thank you.
-
@Lorne Kates said:
Yeah, that's a goodie. It's the only way I've found to insist on connecting to something via HTTP when it's previously been connected to via HTTPS.Here's your random "revert a change done by Mozilla to restore Firefox to baseline usability and prevent it from fucking shit up" tip for today.
1) about:config
2) browser.urlbar.trimURLs = false
You're welcome.
-
@morbiuswilters said:
It doesn't even fucking anchor the search to the beginning of terms, so you'll end up with results for that time a year ago when you were searching for a used Ford car, results from you search for an abandoned forest and results for chloroform.
My first result for "for" is "forums.thedailywtf.com", as well as various other forums I visit. Should also be the case for you.
Unless that website where you look up chloroform uses is more often visited by you. Obviously.
@morbiuswilters said:
when I want to go to TDWTF forums, I simply type "for" into Chrome and it auto-completes to the full URL. Simple. Do that in Firefox and it's going to give you 500 nonsense results.
They're not nonsense, they're prioritized by recentness and visit count.
@morbiuswilters said:
you go to it a few times then Chrome should offer it at the top of the auto-complete list; just start typing "proj" and it will be there and you can select it. If you tried that in Firefox the first 5000 results would have nothing to do with the URL you were trying to type.
This is untrue, thankfully. I suspect it's because you don't use FFX as your primary browser, so you don't go to any page often to have it return useful results.
-
@El_Heffe said:
History
History takes just as much strokes and clicks as activating the address bar, so ok, point there.
@El_Heffe said:
There's no need to remove a useful feature
What was removed?
(apart from the ability to place some toolbar buttons wherever the fuck you wanted in a browser that increasingly pays lip service only to customisability, that is)
-
@dhromed said:
My first result for "for" is "forums.thedailywtf.com", as well as various other forums I visit. Should also be the case for you.
Unless that website where you look up chloroform uses is more often visited by you. Obviously.
I don't really use Firefox anymore, but even when I did it returned completely random bullshit. Maybe they fixed it since the Awesome Bar first came out, but that was the camel that broke the straw's back and I left Firefox and never looked back.
Besides, even if I visit the chloroform site more, I don't want it at the top of the results. The URL doesn't start with "for" so it absolutely should not be anywhere near the top of the list. Page titles are often chock full of words that nobody in their right mind would be searching for.
@dhromed said:
They're not nonsense, they're prioritized by recentness and visit count.
They're nonsense because the URLs don't start with "for" and the page titles only contain the string "for" somewhere in them. If you're going to show me that garbage, fine, but at least put it lower than the actual URLs that start with what I'm typing.
@dhromed said:
This is untrue, thankfully. I suspect it's because you don't use FFX as your primary browser, so you don't go to any page often to have it return useful results.
Back when the AB came out, Firefox was my primary browser. As I said, the Awesome Bar was the pile of retardity that made me look for a better browser. Suddenly, trying to type a URL just yielded hundreds of completely useless pages. Some I hadn't visited in months, some I visited frequently but the only reason they came up was because the three letters I typed were in the middle of some word in their 50-word title.
tl;dr The Awesome Bar is shit UX made by fucking idiots who ruined an otherwise good browser.
-
@morbiuswilters said:
The URL doesn't start with "for" so it absolutely should not be anywhere near the top of the list.
Using the word "absolutely" doesn't make false things more true. That is not to say that the workings of the bar are "absolutely true & good", but it's two ways of doing things, and simply searching everywhere is handier by far for most people in most situations.
Your desired autosuggest/complete method seems rather strict to me. Perhaps IE9's address bar is more to your liking. It usually autocompletes nothing at all even though you type something that you know is in the url. Man. That's so great. Typing something and not getting anything. Really lets me quickly visit to those pages I'm not finding. Amazing.
@morbiuswilters said:
Page titles are often chock full of words that nobody in their right mind would be searching for.
I don't think you're ready for UX discussions if you're going to type random bizarro things.
Examples!
Title: Two-Fluid Coalescence
URL: https://www.youtube.com/watch?v=ZTtjZ5hwbWw
Title: Amazingly screwed-up installation experience
URL: http://forums.thedailywtf.com/forums/t/31447.aspx?PageIndex=2Wow, you're right! Page titles are full of crap and the url clearly is far better.
@morbiuswilters said:
Some I hadn't visited in months, some I visited frequently but the only reason they came up was because the three letters I typed were in the middle of some word in their 50-word title.
So... You got results that matched your query? I don't quite understand the problem.
@morbiuswilters said:
tl;dr The Awesome Bar is shit UX made by fucking idiots who ruined an otherwise good browser.
I'm sorry, I can't hear you over the sound of me visiting pages. Awayyyyyy!
-
@dhromed said:
Your desired autosuggest/complete method seems rather strict to me. Perhaps IE9's address bar is more to your liking. It usually autocompletes nothing at all even though you type something that you know is in the url. Man. That's so great. Typing something and not getting anything. Really lets me quickly visit to those pages I'm not finding. Amazing.
Don't be a jackass. I already clearly said I preferred the old way Firefox worked, and the way Chrome currently works. That is the Right Way.
@dhromed said:
I don't think you're ready for UX discussions if you're going to type random bizarro things.
Examples!
Title: Two-Fluid Coalescence
URL: https://www.youtube.com/watch?v=ZTtjZ5hwbWw
Title: Amazingly screwed-up installation experience
URL: http://forums.thedailywtf.com/forums/t/31447.aspx?PageIndex=2So you want your browser to autocomplete forum thread titles? Really? Meanwhile, if I want to go to, say, Richard Stallman's personal site (stallman.org) and I start typing "s-t-a-l-l", guess what I'm going to get in my results: "Amazingly screwed-up installation experience".
Great. That's just fucking great. Because clearly when someone types "stall" they meant "installation". And when they start typing "escape" they're intending to get "Two-Fluid Coalescence" That's exactly what people fucking want. I don't think you should be trusted with any UX work if you think that makes any goddamn sense.
@dhromed said:
Wow, you're right! Page titles are full of crap and the url clearly is far better.
So you're too lazy/moronic to use Google, bookmarks or history, my address bar has to be ruined? Fuck you, jackass.
@dhromed said:
So... You got results that matched your query? I don't quite understand the problem.
Obviously you are incapable of understanding, which is why you shouldn't be allowed to do anything software-related. Giving me results from the title (which quite frequently won't contain much useful information) of a page I visited one time six months ago in the address bar is absurd. Oh, hey, I have hundreds of pages whose titles contain "Forums" in my history, guess what the first twenty pages of useless results are going to be! Meanwhile, an actual URL that I am trying to autocomplete which starts with "forums" is completely lost in the noise.
It's terrible UX design. You being too stubborn to admit you are wrong does not change that.
@dhromed said:
I'm sorry, I can't hear you over the sound of me visiting pages. Awayyyyyy!
Well, enjoy using a shit browser that everyone sane now realizes is garbage made by fey little retards. Enjoy the crashes, the memory leaks and revel in the failure.
-
@morbiuswilters said:
So you want your browser to autocomplete forum thread titles? Really?
Absolutely and completely yes at all times definitely.
@morbiuswilters said:
Meanwhile, an actual URL that I am trying to autocomplete which starts with "forums" is completely lost in the noise.
lies
-
FWIW, for me typing "stall" brings a few "installations", but they're further down than titles with words that start with the stall prefix; which makes sense.
On the other hand typing "stat" brings up static.howstuffworks.com, a nonsense result, as well as LinkedIn's authorization page (which as a 'state' URL parameter).
So it's pretty hit or miss.
In any case, I'm lazier about using history than scrolling down a bit, yes. And as for bookmarks I have too many already. So I'm with dhromed one this one. The only thing about the Awesome bar that annoys me is the name.
-
@dhromed said:
Absolutely and completely yes at all times definitely.
I don't know what to say. Have you tried the LeapPad? It might be more suited to your needs..
@dhromed said:
lies
Soo.. it doesn't search titles, then? But you just said it does. Are you saying the couple of hundred forum pages won't be returned?
-
@Zecc said:
as well as LinkedIn's authorization page (which as a 'state' URL parameter).
Oh Jesus, that's another thing about the Asshole Bar I hated. I mean, who the fuck searches URL query parameters? WHEN IS THAT EVER USEFUL, MOZILLA??
@Zecc said:
In any case, I'm lazier about using history than scrolling down a bit, yes. And as for bookmarks I have too many already. So I'm with dhromed one this one. The only thing about the Awesome bar that annoys me is the name.
So you refuse to use a computer correctly and we have to suffer? And it's not like getting to the history is any slower than typing in the address bar.
-
@morbiuswilters said:
@Zecc said:
as well as LinkedIn's authorization page (which as a 'state' URL parameter).
Oh Jesus, that's another thing about the Asshole Bar I hated. I mean, who the fuck searches URL query parameters? WHEN IS THAT EVER USEFUL, MOZILLA??
I use that too sometimes.
Freedom!
-
@morbiuswilters said:
I mean, who the fuck searches URL query parameters? WHEN IS THAT EVER USEFUL, MOZILLA??
With all too many sites, that's very useful. You know, those pages which have the address of the real content passed in as a query parameter so that they can do all sorts of wrapping of rubbish around it. Because having bonus advertising around the outside is just peachy for users.Sometimes this sort of thing is even used to handle useful stuff like authorization tokens (this is part of OpenID and Shibboleth actually work). Most of the time not though.
-
@dkf said:
With all too many sites, that's very useful. You know, those pages which have the address of the real content passed in as a query parameter so that they can do all sorts of wrapping of rubbish around it.
What?? So you're saying you're going to type in a URL but it's actually a URL-encoded query parameter on a site that is wrapping the site you want in an iframe? I don't even understand.. I mean, is this a real thing or are you just trying to come up with bullshit rationalizations for bad UX design? Have you ever been like "Oh, yeah, I want to go to Reddit but I want that page that loads Reddit in an iframe and wraps it in ads. Let's start typing "R-E-D", ah there we go!" I mean, is this really a real thing?
@dkf said:
Sometimes this sort of thing is even used to handle useful stuff like authorization tokens (this is part of OpenID and Shibboleth actually work). Most of the time not though.
So, uh, what? You're typing in the address bar because you want to find authorization tokens? WTF?
-
@morbiuswilters said:
You're typing in the address bar because you want to find authorization tokens?
No. Specific places in the Google Code SVN tree browser, except they put the thing of interest in the fragment, which is even madder. The putting of the real address in the query part is a technique I've seen a few times though. (I vaguely remember it being a common thing with MSDN URLs at one stage.)SVN? Because I'm migrating the whole damn mess to something not crazy, that's why.
-
@dkf said:
SVN? Because I'm migrating the whole damn mess to something not crazy, that's why.
What's less crazy than SVN?
-
@morbiuswilters said:
What's less crazy than SVN?
Something that doesn't conflate tags and branches? Something that doesn't allow putting a trunk below a branch below a tag? (It's like a sewer, but with fewer pet alligators.)Though the client attempts to discourage you, SVN lets you be very evil indeed.
-
@morbiuswilters said:
So you refuse to use a computer correctly and we have to suffer? And it's not like getting to the history is any slower than typing in the address bar.
Not so much refuse as not bother to, at the lack of good enough reason to use it.Pre-post edit:
Ok, I actually gave history another try and I have a few reasons not to use it:
- While I can call the history sidebar just as fast as I can focus the awful bar (it's Ctrl+H vs Ctrl+L and Ctrl+H does focus the history's search input), pressing the down arrow while on the search box doesn't give focus to the results, so it is slower. Pressing tab gives focus to the View dropdown first and pressing enter does nothing *;
- The history sidebar is narrower than the asshole bar dropdown. I get to see more text in the latter, even if I resize the former to its maximum size;
- The assbar's dropdown shows URLs and page titles, and bolds whatever matches what I typed. History only shows page titles even when matching on URLs, leaving me wondering what the match is **;
- History shows me lots, and I mean lots, of repeats;
- Opening the sidebar changes the page's dimensions and triggers a re-render. This is a pretty lame argument, but I'll just throw it in there as well.
- Oh yes, searching in history also matches page titles and not just URLs. So it's all indifferent in the end ***.
* Chromium seems to be even worse in this aspect. I can't seem to navigate history using just keys.
** As a quick test I typed "vi" and the first results are: "Gmail", "Google Accounts", "Google Accounts", "Redirecting", "Activity Information", "Git Source Code Review", "Git Source Code Review", "mail.google.com/mail/?auth=...", "Google Accounts", "Google Accounts", ... Results that include the word "video" only start about halfway down.
A bunch of other two- or three-letter tests gave me, in most cases, seemingly nonsensical results. So I'm declaring that search in both history and awkward bar sucks, but at least in the latter case I can see what their rationale for a match was.*** Ignoring bookmarks, I suppose. And btw, I happen to bookmark pages I haven't visited yet, as a reminder to visit then later. That's another point to the amateur bar.
-
@dkf said:
Filed under: there are many choices, we chose git and github
@dkf said:
Something that doesn't conflate tags and branches?
Who cares? Is this really a problem for you? Meanwhile, git has a completely flat tag namespace so have fun when you have 5000 tags.
@dkf said:
Something that doesn't allow putting a trunk below a branch below a tag?
If you're doing something stupid like this, then you shouldn't be using a computer. And yet git will let you do plenty of stupid shit, too.
I'm not saying SVN is good--it's terrible--but for everything git fixes about SVN it breaks at least one other thing.
-
@Zecc said:
@morbiuswilters said:
So you refuse to use a computer correctly and we have to suffer? And it's not like getting to the history is any slower than typing in the address bar.
Not so much refuse as not bother to, at the lack of good enough reason to use it.Pre-post edit:
Ok, I actually gave history another try and I have a few reasons not to use it:
- While I can call the history sidebar just as fast as I can focus the awful bar (it's Ctrl+H vs Ctrl+L and Ctrl+H does focus the history's search input), pressing the down arrow while on the search box doesn't give focus to the results, so it is slower. Pressing tab gives focus to the View dropdown first and pressing enter does nothing ;
- The history sidebar is narrower than the asshole bar dropdown. I get to see more text in the latter, even if I resize the former to its maximum size;
- The assbar's dropdown shows URLs and page titles, and bolds whatever matches what I typed. History only shows page titles even when matching on URLs, leaving me wondering what the match is ;
- History shows me lots, and I mean lots, of repeats;
- Opening the sidebar changes the page's dimensions and triggers a re-render. This is a pretty lame argument, but I'll just throw it in there as well.
- Oh yes, searching in history also matches page titles and not just URLs. So it's all indifferent in the end .
Chromium seems to be even worse in this aspect. I can't seem to navigate history using just keys.
As a quick test I typed "vi" and the first results are: "Gmail", "Google Accounts", "Google Accounts", "Redirecting", "Activity Information", "Git Source Code Review", "Git Source Code Review", "mail.google.com/mail/?auth=...", "Google Accounts", "Google Accounts", ... Results that include the word "video" only start about halfway down.
A bunch of other two- or three-letter tests gave me, in most cases, seemingly nonsensical results. So I'm declaring that search in both history and awkward bar sucks, but at least in the latter case I can see what their rationale for a match was.Ignoring bookmarks, I suppose. And btw, I happen to bookmark pages I haven't visited yet, as a reminder to visit then later. That's another point to the amateur bar.
So in your mind, Firefox's history not being very good justifies making a duplicate history and shoving it into the address bar instead of fixing it? I'm honestly baffled how people can continue to justify this madness. It's like you're chicks in an abusive relationship..
"Firefox really loves me, you wouldn't understand. Sure, sometimes he comes home reeking of booze and stripper grease and starts dumping out my drawers of history all over the address bar... but he doesn't really mean it, he loves me.. he's so wonderful when he's sober.."
"Where did you get that shiner?"
"That was my fault. I, uh.. I hit it on one of those rounded tabs while trying to customize Australis... Don't jump to conclusions, you don't know him like I do!"
-
@morbiuswilters said:
So in your mind, Firefox's history not being very good justifies making a duplicate history and shoving it into the address bar?
Though I disagree with your good/bad judgement, I must admit that this is an accurate representation of reality.
-
@dhromed said:
@morbiuswilters said:
So in your mind, Firefox's history not being very good justifies making a duplicate history and shoving it into the address bar?
Though I disagree with your good/bad judgement, I must admit that this is an accurate representation of reality.
Yeah, but my good/bad judgement did save us from that amputee strip club, so there's that.
-
@morbiuswilters said:
Yeah, but my good/bad judgement did save us from that amputee strip club, so there's that.
Why is there a problem when there's less clothing to take off? Clearly it's a timesaver for the skeeve on the go.
-
@morbiuswilters said:
Yeah, but my good/bad judgement did save us from that amputee strip club, so there's that.
Saved us? I'd pay extra to see one twirling around the pole by their teeth, or kicking their nubs into the air and giggling, or crawling across the stage by their chin to take the dollar bill I licked and stuck to my forehead....
-
@DrakeSmith said:
@morbiuswilters said:
Nominated for the Good Ideas thread.Yeah, but my good/bad judgement did save us from that amputee strip club, so there's that.
Saved us? I'd pay extra to see one twirling around the pole by their teeth, or kicking their nubs into the air and giggling, or crawling across the stage by their chin to take the dollar bill I licked and stuck to my forehead....
-
Sorry to interrupt with this on-subject reply. Feel free to skip it if you just want to continue with the current discussion; I won't be offended.
@anotherusername said:
@Scarlet Manuka said:
I changed its installation path to [b]the standard place for programs to be installed[/b], running elevated (as one does to install software) so that it could put its important files there where they could be safe. And yes, I expected it to work just fine because [b]that's how Windows software is supposed to work[/b]. It clearly knew what AppData is since it suggested to install there, so I'd expect that regardless of the program installation directory, user-specific files would be created in AppData where they belong.Slightly bemused, I changed it to Program Files.
You changed its installation path to a location with drastically different permissions and you expected it to work just fine? You are TRWTF.
@ais523 said:
(discussion of general issues porting Linux software to Windows)
As has been pointed out, porting issues should not have been relevant in this case because the software is Windows-only. However:This isn't so much a problem with doing the security properly, as problems finding the appropriate directories. {...} The problem is, on Linux, you can correctly and safely hardcode all the paths
The usual "solution" in my experience is the same one used by lazy Windows devs: hardcode all the paths regardless of correctness. And if that was the only issue, it would have worked for me too. If the installer had hardcoded C:\Program Files rather than looking it up from CSIDL or KnownFolder values I wouldn't even have known.
-
@Scarlet Manuka said:
@anotherusername said:
@Scarlet Manuka said:
I changed its installation path to the standard place for programs to be installed, running elevated (as one does to install software) so that it could put its important files there where they could be safe. And yes, I expected it to work just fine because that's how Windows software is supposed to work. It clearly knew what AppData is since it suggested to install there, so I'd expect that regardless of the program installation directory, user-specific files would be created in AppData where they belong.Slightly bemused, I changed it to Program Files.
You changed its installation path to a location with drastically different permissions and you expected it to work just fine? You are TRWTF.
@ais523 said:
(discussion of general issues porting Linux software to Windows)
As has been pointed out, porting issues should not have been relevant in this case because the software is Windows-only. However:This isn't so much a problem with doing the security properly, as problems finding the appropriate directories. {...} The problem is, on Linux, you can correctly and safely hardcode all the paths
The usual "solution" in my experience is the same one used by lazy Windows devs: hardcode all the paths regardless of correctness. And if that was the only issue, it would have worked for me too. If the installer had hardcoded C:\Program Files rather than looking it up from CSIDL or KnownFolder values I wouldn't even have known.I've actually been trying to work out just how you're supposed to create an installer for Windows that allows users to customize the install location (this is something I actually want to do, and I'm hoping that the "bitch about shortcomings of Linux until a bunch of Linux fanboys turn up and tell you 10 different ways to do it in Linux to prove its superiority" works for Windows too). Say a user wants to install to their Documents folder (maybe they're just trying out the program and don't want to give it admin rights); how does it know to look there for its data, rather than in the normal place on Windows (which I assume is an application-specific subdirectory under FOLDERID_ProgramData, formerly CSIDL_COMMON_APPDATA)? Getting the installer to write the path into the executable would be awkward, but I think it's wrong anyway; it should convert the path to a relative path to FOLDERID_Documents, in case the documents folder moves. (This is something that my installer gets wrong under Linux at the moment, actually; it would be nice to fix that at the same time.) I guess one possibility is for the application to determine the path to its own executable, see if it's in FOLDERID_ProgramFiles, use the known folders mechanism if it is, and otherwise assume that the user is doing something weird and custom and just use files relative to the directory containing the executable, on the basis that if the user is installing it somewhere weird, they should know what they're doing. You'd write the actual relative paths to use into the executables, in case the user wants to customize the locations of some things but not others (e.g. they want to move the data files but not the executables, for just the one program; this is a scenario I've actually seen people ask about).
OK, that wasn't so bad. I should try rubber-ducking on forums more often.
-
@ais523 said:
@Scarlet Manuka said:
@anotherusername said:@Scarlet Manuka said:
Slightly bemused, I changed it to Program Files.
You changed its installation path to a location with drastically different permissions and you expected it to work just fine? You are TRWTF.
I changed its installation path to the standard place for programs to be installed, running elevated (as one does to install software) so that it could put its important files there where they could be safe. And yes, I expected it to work just fine because that's how Windows software is supposed to work. It clearly knew what AppData is since it suggested to install there, so I'd expect that regardless of the program installation directory, user-specific files would be created in AppData where they belong.@ais523 said:
(discussion of general issues porting Linux software to Windows)
As has been pointed out, porting issues should not have been relevant in this case because the software is Windows-only. However:This isn't so much a problem with doing the security properly, as problems finding the appropriate directories. {...} The problem is, on Linux, you can correctly and safely hardcode all the paths
The usual "solution" in my experience is the same one used by lazy Windows devs: hardcode all the paths regardless of correctness. And if that was the only issue, it would have worked for me too. If the installer had hardcoded C:\Program Files rather than looking it up from CSIDL or KnownFolder values I wouldn't even have known.I've actually been trying to work out just how you're supposed to create an installer for Windows that allows users to customize the install location (this is something I actually want to do, and I'm hoping that the "bitch about shortcomings of Linux until a bunch of Linux fanboys turn up and tell you 10 different ways to do it in Linux to prove its superiority" works for Windows too). Say a user wants to install to their Documents folder (maybe they're just trying out the program and don't want to give it admin rights); how does it know to look there for its data, rather than in the normal place on Windows (which I assume is an application-specific subdirectory under FOLDERID_ProgramData, formerly CSIDL_COMMON_APPDATA)? Getting the installer to write the path into the executable would be awkward, but I think it's wrong anyway; it should convert the path to a relative path to FOLDERID_Documents, in case the documents folder moves. (This is something that my installer gets wrong under Linux at the moment, actually; it would be nice to fix that at the same time.) I guess one possibility is for the application to determine the path to its own executable, see if it's in FOLDERID_ProgramFiles, use the known folders mechanism if it is, and otherwise assume that the user is doing something weird and custom and just use files relative to the directory containing the executable, on the basis that if the user is installing it somewhere weird, they should know what they're doing. You'd write the actual relative paths to use into the executables, in case the user wants to customize the locations of some things but not others (e.g. they want to move the data files but not the executables, for just the one program; this is a scenario I've actually seen people ask about).
OK, that wasn't so bad. I should try rubber-ducking on forums more often.
The generally accepted way is to use the registry.
-
@Buttembly Coder said:
The generally accepted way is to use the registry.
Then how could the same user possibly install two copies of the application at once? Half the reason you'd want to customize the install paths is to do that.
-
@ais523 said:
@Buttembly Coder said:
The generally accepted way is to use the registry.
Then how could the same user possibly install two copies of the application at once? Half the reason you'd want to customize the install paths is to do that.
They'd use two computers.
-
The way that kind of thing usually works in Unix is that you have optional global config for your thing in /etc/yourthing/whatever.conf, and optional per-user config for your thing in ~/.config/yourthing/whatever.conf, and conflicts are resolved in favour of the per-user settings. I can see no reason why the same scheme shouldn't work for Windows: have your app look for config in both CSIDL_COMMON_APPDATA and CSIDL_APPDATA regardless of where the executables are installed, and resolve any conflicts in favour of the per-user config.
For modifying system-wide config after installation, your application's config editor would need to elevate first. There's Windows UI precedent for this kind of arrangement: the compatibility settings tab of the property sheet for executables has a button allowing you to make config changes that apply to all users. Click that and you get asked for permission to elevate; if you don't give it, you can only make changes that apply to you.
-
If having a single user run multiple independent instances of your thing is a normal use case, it would probably makes sense to keep the per-user config inside the application's own folder rather than using CSIDL_APPDATA. Or you could do as Firefox does and let the user create multiple profile folders independently of the application installation folder, which gives you your multiple independent instances without a hard necessity to duplicate binaries and libraries.\
Keeping config in files rather than in the Registry, especially if one of the possibilities is to keep it in the same folder as the application itself runs from, makes it easy for your users to create portable installations that run off USB sticks as well as making recovery from failed installs and uninstalls easier.
-
@Buttembly Coder said:
@ais523 said:
Each user account has its own HKCU subtree. This is layered on top of HKLM.@Buttembly Coder said:
The generally accepted way is to use the registry.
Then how could the same user possibly install two copies of the application at once? Half the reason you'd want to customize the install paths is to do that.
They'd use two computers.
-
@joe.edwards said:
Each user account has its own HKCU subtree. This is layered on top of HKLM.
I was aware of that (which is why I said "the same user"); not having HKCU would mean that you couldn't have two different users each install for their own use, which would be such a mistake in designing a configuration system that it's hard to imagine any OS making it.
That said, all this thinking about corner cases is mostly just an attempt to make sure I don't do something stupid, like half the programs on here do. (That said, doing better than the average installer doesn't seem to be hard, given how bad the average installer is.)
-
@joe.edwards said:
@Buttembly Coder said:
@ais523 said:
Each user account has its own HKCU subtree. This is layered on top of HKLM.@Buttembly Coder said:
The generally accepted way is to use the registry.
Then how could the same user possibly install two copies of the application at once? Half the reason you'd want to customize the install paths is to do that.
They'd use two computers.What're ya tryin' t'do, troll the guy?
-
@ais523 said:
Say a user wants to install to their Documents folder (maybe they're just trying out the program and don't want to give it admin rights); how does it know to look there for its data, rather than in the normal place on Windows (which I assume is an application-specific subdirectory under FOLDERID_ProgramData, formerly CSIDL_COMMON_APPDATA)?
Why would installing an app to an unusual place change where the app looks for its configuration files? Why wouldn't it still use AppData? I do not understand your question.
@ais523 said:
Getting the installer to write the path into the executable would be awkward, but I think it's wrong anyway; it should convert the path to a relative path to FOLDERID_Documents, in case the documents folder moves.
Write the path "into" the executable? What path? The path to AppData? Why would you want to do this? Why would moving the documents folder change the path to AppData?
@ais523 said:
I guess one possibility is for the application to determine the path to its own executable, see if it's in FOLDERID_ProgramFiles, use the known folders mechanism if it is, and otherwise assume that the user is doing something weird and custom and just use files relative to the directory containing the executable, on the basis that if the user is installing it somewhere weird, they should know what they're doing.
Wha... wha... why... what the fuck?
There's some really weird-ass unspoken idea you're working with here, I can't even hope to glean it. Or you're overthinking the problem to an epic degree. You use the known folders API calls no matter where the app is. There's no reason not to. Ever.
@ais523 said:
You'd write the actual relative paths to use into the executables, in case the user wants to customize the locations of some things but not others (e.g. they want to move the data files but not the executables, for just the one program; this is a scenario I've actually seen people ask about).
Ignoring the "why" angle for a moment, how would you even write the paths into the executables? Haven't you ever heard of DEP? That's a big security no-no in the Windows world, and the OS ain't gonna let you do it, bud. Maybe you could write it in an NTFS attribute, but I still don't get why.
@ais523 said:
OK, that wasn't so bad. I should try rubber-ducking on forums more often.
I think you just made like 8,000 Windows developers' brains explode.
-
@ais523 said:
Then how could the same user possibly install two copies of the application at once? Half the reason you'd want to customize the install paths is to do that.
They just install one copy and double-click the icon twice.
Is this seriously the problem you were over-thinking? How does the user run two instances of the same application?! Because, uh, you know Windows just does that by default, you know.
And guess what, like magic, the named folders API calls work in both copies.
-
@blakeyrat said:
@ais523 said:
Say a user wants to install to their Documents folder (maybe they're just trying out the program and don't want to give it admin rights); how does it know to look there for its data, rather than in the normal place on Windows (which I assume is an application-specific subdirectory under FOLDERID_ProgramData, formerly CSIDL_COMMON_APPDATA)?
Why would installing an app to an unusual place change where the app looks for its configuration files? Why wouldn't it still use AppData? I do not understand your question.
He's trying to support "portable installations" I think (where you install on a USB drive and the settings are carried along with it). Most applications I've seen that support this scenario ask the user at installation if they want a normal or portable installation.
-
@flabdablet said:
The way that kind of thing usually works in Unix is that you have optional global config for your thing in /etc/yourthing/whatever.conf, and optional per-user config for your thing in ~/.config/yourthing/whatever.conf, and conflicts are resolved in favour of the per-user settings. I can see no reason why the same scheme shouldn't work for Windows: have your app look for config in both CSIDL_COMMON_APPDATA and CSIDL_APPDATA regardless of where the executables are installed, and resolve any conflicts in favour of the per-user config.
... or use the Registry, which is built specifically to solve this problem and resolves the settings automagically. And as an added bonus, when you use the Registry, your application can be controlled by the Active Directory administrator. It's almost as if... it's almost as if Microsoft thought about all these problems and solved them decades ago.
-
@ais523 said:
That said, all this thinking about corner cases is mostly just an attempt to make sure I don't do something stupid, like half the programs on here do. (That said, doing better than the average installer doesn't seem to be hard, given how bad the average installer is.)
Overcomplicating a solved problem to a comically ridiculous degree instead of just using the simple, clean solution that's worked for decades is something stupid.
-
@joe.edwards said:
He's trying to support "portable installations" I think (where you install on a USB drive and the settings are carried along with it). Most applications I've seen that support this scenario ask the user at installation if they want a normal or portable installation.
Oh. Then his insane rambling makes some tiny sort of sense. Imagine how less confused we'd all be if he's typed like 4 words to actually COMMUNICATE WHAT PROBLEM HE WAS TRYING TO SOLVE.
ais523 is one of those programmers who, if I met in real life, I'd be really tempted to punch in the face all the fucking time. You know the type. The kind who have never read Alex's little essay on how horrible programmers are. YOU START BY DESCRIBING THE PROBLEM YOU ARE TRYING TO SOLVE, IDIOT.
Anyway, the best/only way to handle this is to get the path to your own executable (not as trivial as it seems) and have a folder called something like "thisapp_config" at the same level in the filesystem and create your own little mini-AppData and mini-Registry in there in the form of files. Or just don't fucking do it at all, because the only point to doing that is to help middle-schoolers override their school's internet filter and surf for porn.
-
@blakeyrat said:
Ignoring the "why" angle for a moment, how would you even write the paths into the executables? Haven't you ever heard of DEP? That's a big security no-no in the Windows world, and the OS ain't gonna let you do it, bud. Maybe you could write it in an NTFS attribute, but I still don't get why.
DEP is irrelevant; he's talking about the installer modifying an executable file it's writing. And resources are probably the easiest way to do that.
(I agree that the premise is brain-splodey-worthy, though.)
-
@heterodox said:
DEP is irrelevant; he's talking about the installer modifying an executable file it's writing.
Well his pointless rambling got into how to change the path if the path to Documents change-- look whatever, my brain already hurts from trying to understand this retard.
@heterodox said:
(I agree that the premise is brain-splodey-worthy, though.)
Oh no. His novel-sized solution so much simpler than "find the path of the executable, and see if there's a "programname_settings" folder in the same path and read configuration from it if so". Sooooo much simpler.
Seriously though, if you go this route just keep in a mind a couple things: 1) the path of the executable could be somewhere weird (like on a network drive for example), 2) there's no guarantee even if the "programname_settings" folder exists that it's writable, 3) portable applications are stupid, stop helping middle-schoolers surf porn at school.
-
@blakeyrat said:
portable applications are stupid, stop helping middle-schoolers surf porn at school.
Why do you hate users?
-
@boomzilla said:
Why do you hate users?
Because none of the fuckers love and revere advertising like they should, the fucking sociopaths. And they say radiation is bad for you! Pernicious nonsense. Everybody could stand a hundred chest X-rays a year. They ought to have them, too. When they canceled the project it almost did me in.
-
@flabdablet said:
And they say radiation is bad for you! Pernicious nonsense. Everybody could stand a hundred chest X-rays a year. They ought to have them, too.
Where the fuck did that come from? Jesus, I think your psychosis is leaking out into all of your posts now..
-
@blakeyrat said:
Alex's little essay on how horrible programmers are
@Alex's Essay said:
This is quite possibly the worst way you could store this data in a database. No, seriously. They had better ways of doing this over thirty years ago. You have created a horrible problem that is only starting to rear its ugly head. It will only continue to get horribly worse, costing your company more and more money to maintain.
You need to drop everything your doing right now and take a trip to your bookstore to get a database book. I recommend INTRODUCTION TO DATABASE SYSTEMS by DATE, but at this point anything should do. For the sake of everyone who will maintain your future code, don't touch a database until you understand how big of a mess you've created.
Oh My God, Blakey is a sockpuppet of Alex.
-
