Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

"Apple Computer" needs to be changed to "Apple" in the xml dtd. #17

Closed
tomandersen opened this Issue Feb 12, 2013 · 8 comments

Comments

Projects
None yet
5 participants

But this is a small bug considering the whole thing fails if your values have any return characters in them.

AknEp commented Jun 25, 2015

+1, may I PR?

musl commented Dec 2, 2015

How about honoring the original DTD if present and using the Apple version if not?

Consider the case where you want to load a plist file, pass the data up a chain of observers, and you only want to replace the original file (and trigger other actions) only if the plist file actually changed. If parsing and then immediately dumping a plist file yields the same file, that case would be trivial.

Also, if folks are using this gem for non-apple plists (Does that even happen?) it'd be nice.

Owner

patsplat commented Jan 26, 2016

Hi all,

Yes a PR would be appreciated. Please include tests.

FYI for those involved: this library was originally created to help me
export iPhoto libraries. @bleything got the project moved from sourceforge
to github and maintained it for some time.

Since then there have been many changes to the plist format including a
binary format etc. Pull requests for any of these features will be
appreciated.

Thank you for your use of the library.

Cheers,

Patrick
On Tue, Jan 26, 2016 at 4:56 AM Daniel Galasko notifications@github.com
wrote:

+1


Reply to this email directly or view it on GitHub
bleything#17 (comment).

Looks like this is actually done in 81bba1b I think what we need is a version bump

Owner

patsplat commented Jan 28, 2016

version bumped. it doesn't really matter all that much, if you inspect a MacOS X you'll see plenty of plists with both DTDs in use

@patsplat patsplat closed this Jan 28, 2016

I don't see a version bump? The reason why this matters is that other dependencies that use this spec to update plists (Fastlane is one such) cause Xcode generated plists to be modified unnecessarily. After a commit action, a subsequent open with Xcode triggers the plist to be modified again. You can read more about this issue here fastlane/fastlane#1180

So once the version is bumped and the gem spec updated I can go ahead and update Fastlane's spec to use the latest version:)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment