Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000251All Inform front-end applications[IDEs] Installation and Platform Issuespublic2010-08-16 07:112015-05-10 17:47
Assigned Topchimento 
Platformx86OSMac OS XOS Version10.6
Product Version6E72 
Target VersionFixed in Version6G60 
Summary0000251: Settings.plist lossily modified between OS X and Windows IDE
DescriptionSettings.plist gets immediately modified (possibly replaced - see the change in the doctype declaration) on project open, not respecting existing keys, apparently by both the OS X and the Windows I7 GUIs.

This makes sharing the entire .inform via source control more difficult than needed, since simply opening the file causes a change; not including the settings.plist in source control is problematic because of the need for certain actual preferences such as the z-code version to compile to.

Applications should ideally respect the existing settings file, adding new keys but not removing unknown keys.
Additional InformationDiff of an example glulx project between OS X (a) and Windows (b):

diff a/Example.inform/Settings.plist b/Example.inform/Settings.plist
--- a/Example.inform/Settings.plist
+++ b/Example.inform/Settings.plist
@@ -1,26 +1,19 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ""> [^]
+<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" ""> [^]
 <plist version="1.0">
+ <key>IFSettingNobbleRng</key>
+ <false/>
- <key>IFInform6Extensions</key>
- <dict/>
- <key>IFMiscSettings</key>
- <dict>
- <key>IFSettingElasticTabs</key>
- <true/>
- <key>IFSettingInfix</key>
- <false/>
- </dict>
@@ -28,7 +21,5 @@
- <key>IFRandomSettings</key>
- <dict/>
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
EmacsUser (manager)
2010-08-17 16:40

Confirmed, in part.

For me, both IDEs use the document type -//Apple Computer//DTD PLIST 1.0//EN, the same string used in the plist documentation at [^]

Similarly, I cannot get the Mac OS IDE to remove a key from the plist.

I can, however, get the Windows IDE to delete keys by opening the project, clicking ``Go!,'' and closing the editor.

One caveat: From what I know, the IDEs keep this data in RAM, not on disk, while the project is open. As a consequence, if you update the plist from version control while the IDE is editing the story, overwrites are to be expected.
DavidK (developer)
2010-12-11 09:32

I've changed the Windows front-end to use all the same keys as the OSX front-end, and also to only actually write a new settings file if the old one has changed.
jmcgrew (administrator)
2010-12-11 18:47

Is that sufficient to mark this resolved? Are there any similar issues with the Linux IDE?
vimes (reporter)
2010-12-12 07:44

My only question regarding the fix is "is it future-proof?" (That is, will the current Windows front-end maintain unknown keys that the Mac front-end might add in the future?) Other than that, it sounds like a sufficient solution to resolve it as I have presented it.

I have no experience with the linux IDE, but I can set up an environment to do a test there if need be.
DavidK (developer)
2010-12-15 01:40

The Windows front-end won't maintain unknown keys: I'd rather ensure that there are no unknown keys. I think this is as done on Windows as it's going to get: I'll re-assign to Philip so he can check on Linux.
pchimento (developer)
2010-12-15 02:46

The Linux IDE maintains unknown keys, as of the upcoming version. It might shuffle the order around when writing them back out to a file though, compared to how the other platforms do it. We should probably standardize this too, to assist in collaborating via source control. Right now, my code writes entries in <dict> elements in alphabetical order of the keys.
pchimento (developer)
2011-01-06 08:42

Any thoughts on standardizing this, or should I close it?
DavidK (developer)
2011-01-10 08:35

I think that the OSX front-end relies on OSX library code to write out the file, so specifying the order of entries might be difficult there. I think that given the work done, we can close this one.
jmcgrew (administrator)
2015-05-10 17:47

Closing all resolved issues from 2014 and earlier.

- Issue History
Date Modified Username Field Change
2010-08-16 07:11 vimes New Issue
2010-08-16 14:44 jmcgrew Status new => acknowledged
2010-08-17 16:40 EmacsUser Note Added: 0000397
2010-08-17 16:40 EmacsUser Status acknowledged => confirmed
2010-09-03 14:27 graham Assigned To => DavidK
2010-09-03 14:27 graham Status confirmed => assigned
2010-12-11 09:32 DavidK Note Added: 0000896
2010-12-11 09:32 DavidK Assigned To DavidK =>
2010-12-11 18:47 jmcgrew Note Added: 0000897
2010-12-11 18:47 jmcgrew Status assigned => feedback
2010-12-12 07:44 vimes Note Added: 0000899
2010-12-12 07:44 vimes Status feedback => new
2010-12-13 19:55 jmcgrew Assigned To => DavidK
2010-12-13 19:55 jmcgrew Status new => assigned
2010-12-15 01:40 DavidK Note Added: 0000902
2010-12-15 01:40 DavidK Assigned To DavidK => pchimento
2010-12-15 02:46 pchimento Note Added: 0000903
2011-01-06 08:42 pchimento Note Added: 0000944
2011-01-10 08:35 DavidK Note Added: 0000959
2011-02-25 04:18 pchimento Status assigned => resolved
2011-02-25 04:18 pchimento Fixed in Version => 6G60
2011-02-25 04:18 pchimento Resolution open => fixed
2015-05-10 17:47 jmcgrew Note Added: 0003755
2015-05-10 17:47 jmcgrew Status resolved => closed

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker