Mac read_defaults?

slbaumgartner

how do you return a string from SU using the API method...

I can't retrieve this without using a system call

      mac_window = %x(defaults  read  com.sketchup.SketchUp.20#{Sketchup.version.to_i}  "NSWindow Frame SketchUpDoc").chomp!.split(' ').each{|n| n.to_i}     
>

returns **["38", "613", "512", "565", "0", "0", "1920", "1178"]**

but every concievable version of

Sketchup.read_default("NSWindow Frame SketchUpDoc", "")

returns nothing...

if I escape the spaces I can return nil, but no values...

I've tried single quote, double quotes, %20 escapes...

I can get back other, keys values, but none like this one, how can it be done?

john

@john, I don't believe that the SU API's Sketchup.read_default is equivalent to the Mac OS command. Instead, it reads back values stored using Sketchup.write_default. They are actually kept in a plist file specific to SU, and you can only read values from there, not the system defaults.

Steve

driven

@slbaumgartner said:

Instead, it reads back values stored using Sketchup.write_default. They are actually kept in a plist file specific to SU, and you can only read values from there, not the system defaults.

so it's a hidden, additional plist?

when you use SU.write_defaults you can retrieve them using both SU read or System read?

and if you change the document size the user/lib/plist is instantly updated...

I can't follow what's occurring...
john

Dan Rathbun

The Ruby standard library has PStore class.

Also you can try the Plist Gem (Doc LInk)

driven

@dan

it's not a problem to read the exposed plist using system calls, it's more the frustration of having a useless API method...

I shouldn't need system to read an SU stored preference, from SU...

john

slbaumgartner

@driven said:

@slbaumgartner said:

Instead, it reads back values stored using Sketchup.write_default. They are actually kept in a plist file specific to SU, and you can only read values from there, not the system defaults.

so it's a hidden, additional plist?

when you use SU.write_defaults you can retrieve them using both SU read or System read?

and if you change the document size the user/lib/plist is instantly updated...

I can't follow what's occurring...
john

I don't think it is hidden, it is in ~/Library/Preferences/

SU 2014 keeps a couple of plists there. I believe that the one accessed by read/write_defaults is
com.sketchup.SketchUp.2014.plist.

It was intended for plugins to remember their settings until another session.

The thing is that the SU API's read/write_default methods are wired specifically to this file. They can not read or write defaults from plists belonging to other apps or from the system in general.

Steve

driven

@slbaumgartner said:

The thing is that the SU API's read/write_default methods are wired specifically to this file. They can not read or write defaults from plists belonging to other apps or from the system in general.
Steve

Steve this is in the com.sketchup.SketchUp.20#{Sketchup.version.to_i} plist; that's why I can't understand not being able to read it...

slbaumgartner

@driven said:

@slbaumgartner said:

The thing is that the SU API's read/write_default methods are wired specifically to this file. They can not read or write defaults from plists belonging to other apps or from the system in general.
Steve

Steve this is in the com.sketchup.SketchUp.20#{Sketchup.version.to_i} plist; that's why I can't understand not being able to read it...

I looked and found that you are right about this key being there, so I did some poking around and came to the conclusion that the API methods are designed only to deal with two-level entries: (section, variable). If you try to omit one, you get a wrong number of arguments error, and if either is an empty string, you get nothing.

In the plist file this means there is a dict entry in the Root with the section name, and this dict has a key entry with the variable name. But "NSWindow Frame SketchUpDoc" is a single-level key directly in the Root, with no other enclosing dict. I tried using "Root" as the section, but that didn't work either. It seems that the API methods have no way to write or read a Root-level non-dict entry (whether by design or oversight I don't know...).

driven

@slbaumgartner said:

...I tried using "Root" as the section, but that didn't work either.

been there, done that, got the post card... [ as we say ]

@unknownuser said:

It seems that the API methods have no way to write or read a Root-level non-dict entry (whether by design or oversight I don't know...).

not sure either, but in the past I have written lots of pref's I couldn't retrieve, although they were written, possibly at root level, honestly can't remember...

it's been bugging me for years...
john

Dan Rathbun

Well humor me, and try the Plist Gem here:
http://rubygems.org/gems/plist
.. and you no longer have to use %x strings.

Doc: http://plist.rubyforge.org

driven

@dan,

result = Plist;;parse_xml("/Users/johns_iMac/Library/Preferences/com.sketchup.SketchUp.2014.plist")
Error; #<ArgumentError; invalid byte sequence in UTF-8>
/Users/johns_iMac/Library/Application Support/SketchUp 2014/SketchUp/Gems/gems/plist-3.1.0/lib/plist/parser.rb;91;in `scan'

I don't think its been updated for Ruby 2...

john

Dan Rathbun

Well if you search Rubygems.org, you'll see quite a few plist reader gems.

Dan Rathbun

@driven said:

@dan,

result = Plist;;parse_xml("/Users/johns_iMac/Library/Preferences/com.sketchup.SketchUp.2014.plist")
> Error; #<ArgumentError; invalid byte sequence in UTF-8>
> /Users/johns_iMac/Library/Application Support/SketchUp 2014/SketchUp/Gems/gems/plist-3.1.0/lib/plist/parser.rb;91;in `scan'

I don't think its been updated for Ruby 2...

It was supposed to be 1.9.x compatible (since it's v3.0.0)

Try on a simpler plist. Perhaps SketchUp corrupted it's file ?

driven

I think it's actually failing on the binary image chunks stored in some of the keys...

the thing is there are many built in plist tools that can be used in any plugin, on any mac...

Gem support from SU Ruby is broken for many things, so I'd favour %x() over failure...

result = %x( plutil -p "/Users/johns_iMac/Library/Preferences/com.sketchup.SketchUp.2014.plist") returns a human readable string...

point is I only want the one item and it should be available from Sketchup.read_defaults
john

tt_su

@driven said:

but every concievable version of

Sketchup.read_default("NSWindow Frame SketchUpDoc", "")

returns nothing...

Sketchup.read_default is not a generic method to read anything from a plist. It's a simple method to read simple values for an extension.

What you try to do I have done using a shell command (backticks I think). (Don't have the sample snippet on my home machine right now.)

Dan Rathbun

@driven said:

I think it's actually failing on the binary image chunks stored in some of the keys...

Well it's Doc did say it would choke on data elements.

driven

@tt_su said:

...
Sketchup.read_default is not a generic method to read anything from a plist. It's a simple method to read simple values for an extension.

I haven't ever suggested it reads random plist's, I think the API should be able to read SketchUp's own plist items...

@unknownuser said:

What you try to do I have done using a shell command (backticks I think).
It will be similar to my first, working example, it works with `` or %x(), I just find %x() more obvious when reading the code...

john

slbaumgartner

@driven said:

I think it's actually failing on the binary image chunks stored in some of the keys...

The property you sought looks like this in XCode on my Mac:

Screen Shot 2014-05-11 at 3.14.04 PM.png

It's a string key and value, So I don't think the issue is with binary chunks, it is as TT says simply that read_defaults wasn't designed to read values that weren't written by write_defaults.

Steve

driven

@slbaumgartner said:

So I don't think the issue is with binary chunks, ...

@steve...
that comment was referring to the plist gem, it appears to fail on the "BigBrowser" image buttons values that are stored in binary... [but what is BigBrowser??]

Now I know it only reads what it can write, I'll continue using defaults for anything else...

john

Dan Rathbun

Well on the PC, we have been in the same boat. The API can read only string registry values. Many things are DWORD binary values. Often holding only 1 or 0 for true/false, on/off, etc. Such a simple thing that can not be read.

A long time ago, I thought I filed a Feature Request for an application level options hash interface.