Re: [email] RE: [GD-General] A portable preferences library
Brought to you by:
vexxed72
Menu
▾
▴
Re: [email] RE: [GD-General] A portable preferences library
|
From: Dan T. <da...@ar...> - 2003-12-04 21:33:07
|
I'd say it stumbles, but doesn't *quite* fall down. Since with Colin's scheme you can move games/apps around as entities freely, you could (in theory), just move the whole thing somewhere where little johhny *does* have access. Actually the windows LUA compatibility stuff under XP does this exact thing in the registry to anyone who tries to write to HKLM - just copies it to HKCU and lets them do whatever they want to it. -Dan ----- Original Message ----- From: "Andrew Grant" <ag...@cl...> To: <gam...@li...> Sent: Thursday, December 04, 2003 1:14 PM Subject: [email] RE: [GD-General] A portable preferences library > >> I think multi-user systems is an antiquated concept. > > You're joking right? > > Also your scheme falls down the minute somebody without write access to the > games folder attempts to play it. Something that's pretty common these days > where Dad has to install the games little Johnny wants to play on the family > PC. I'd be surprised if your approach makes it through QA of any publisher > worth their salt. > > I agree the registry isn't the place to store the data, but neither is the > game install folder. Anything you need to save from your game and that > doesn't ask the user for a path should go into the whatever's returned by > SHGetFolderLocation(.., CSIDL_APPDATA, ..); > > > _____________________________________ > andrew grant | programmer | climax brighton > ag...@cl... - www.climax.co.uk > > > > > > > > -----Original Message----- > > From: Colin Fahey [mailto:cp...@ea...] > > Sent: 04 December 2003 20:42 > > To: gam...@li... > > Subject: Re: [GD-General] A portable preferences library > > > > > > 2003 December 4th > > Thursday > > > > I have used the following scheme for storing user preferences > > for an application: > > > > [1] A plain text file in the same directory as the executable, > > with the extension *.txt rather than something else (like > > *.ini); > > > > [2] The application, when launched, can determine the path of its > > executable file, and thus the location of the corresponding > > user preferences text file; > > > > [3] All aspects of reading the user preferences text file are > > fault-tolerant; re-ordering, adding, removing fields will > > have the least possible effect -- and field values are > > similarly checked and clipped to sane limits. > > > > Security of the preferences is not an issue for my use of this scheme. > > > > Benefits of this scheme: > > > > [a] One can have many independent instances of the application > > on a single machine, each with different preferences; > > > > [b] The user can edit preferences if the application malfunctions, > > which is impossible in a scheme where the application itself > > is the only entity that can manipulate the preferences file; > > > > [c] Users can send or receive preferences files, or disucss > > specific named settings, via e-mail or web pages; > > > > [d] Settings in the preferences file can correspond to an > > application's scripting system -- so that the preferences > > file is nothing more than a batch of scripting commands > > that can otherwise be entered at run-time in the > > application itself (as in a console window for a video > > game); > > > > [e] Settings persist after clean install of operating system; > > > > [f] Application and settings can be stored on a CD-ROM or > > portable disk or flash-memory device, and one can > > take it to someone else's computer and operate the > > application without doing an "installation" or > > polluting their computer with any files whatsoever; > > (I bring my prototype applications to a friend's house > > for demonstration on my keychain USB memory device, > > and execute directly from the keychain!) > > > > Basically, I'm a strong believer of the settings following > > the application around. I think the old MacIntosh operating > > system hid a kind of directory system behind the application > > icon -- with the "resource fork" and "data fork", which was a > > pretty good idea because it allowed data associated with a > > program to be bound to the program. Thus, moving or copying > > the icon would assure that all settings and data moved with > > it. It was a nice abstraction that simplified the notion of > > "application" and reduced confusion when moving it around. > > > > Maybe I'm hard-core, but I think everything an application > > needs to operate, short of the absolutely guaranteed > > resources of the operating system, should be packaged with > > the application -- and totally portable. I should be able to > > run any application on anyone's computer from my keychain > > memory device, without adding any files to their computer! > > > > I think multi-user systems is an antiquated concept. But if > > I must support multiple users of a single application (as > > opposed to each user installing his or her own copy of the > > application), then individual preferences files can be stored > > with the application. "preferences_bob.txt", > > "preferences_joe.txt", etc. Putting these preferences > > anywhere else but with the application leads to > > potential pollution that might never go away. Lots of > > irresponsible developers don't do a good job of > > un-installation -- or somehow the application disappears from > > the computer without un-install ever happening, leaving tons > > of scattered junk behind. > > > > I always thought the Windows registry was a disaster; it > > encouraged people to centralize critical information, and it > > has been a source of confusion and annoyance for users. > > Protecting the integrity of this single trash heap is silly. > > > > Okay, I sympathize with the idea that putting everything in > > one place somehow seems more organized. I dislike the idea > > of things being scattered around. But I think it's perfectly > > good to put things in self-contained bundles that do not rely > > on any centralized thing or on scattered things. It's very clean. > > > > I think rather than pushing itself upon one's computer (like > > a formal installation procedure), applications should be > > passive and the > > operating system should instead scan for applications upon > > boot-up. Thus, the "Start" menu is populated at boot time and > > is 100% in sync with available applications. Applications > > can contain > > preferences about placement in the "Start" menu hierarchy, > > much like an application can propose its own icon. The key > > is to eliminate the idea of "installation". > > > > Okay, some of these ideas are radical, but I just wanted to > > share my own thoughts about preferences files. > > > > --- Colin > > > > cp...@ea... > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us > > help YOU! Click Here: http://sourceforge.net/donate/ > > _______________________________________________ > > Gamedevlists-general mailing list > > Gam...@li... > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
