text ruler still missing in 1.8.2.260

[v_kyr]

General NOTE:  There are several infos & docs on Apple's website and MacOS about their property list format and how to use it.

• The manpage of "plutil -- property list utility"
  > man plutil
• The manpage for the "plist -- property list format" (will tell you more about the format)
  > man 5 plist     or just    man plist
• Introduction to Property List Programming Topics for Core Foundation
• Apple's older Property List Programming Guide
• macOS property list files (from the Lazarus Wiki)
• ...etc.

 

Related to BBedit, they (Bare Bones) know how to handle Apple property list files and so the format. They do use plist files a lot themselves for their editor modules and enhancements too, like for example for their syntax highlighters etc. (see: Codeless Language Modules, BBEditLanguageMods, etc.)

 

[R C-R]

1 minute ago, v_kyr said:

Related to BBedit, they (Bare Bones) know how to handle Apple property list files and so the format. They do use plist files a lot themselves for their editor modules and enhancements too, like for example for their syntax highlighters etc.

Thanks for the confirmation about BBEdit's ability to handle plist files. I only use a tiny fraction of its free mode features but (so far) it has not caused any problems with anything I have used it for. 

[v_kyr]

1 hour ago, LondonSquirrel said:

I would consider the version edited by plutil to be the standard to measure against, as that is the tool designed for the job.

That's right, since this tool is sort of Apple's reference implementation for their property list format handling, beside Xcode which may reuses the one or other code part from the plutil, or at least from Apple's related API routines for their plist format.

Most MacOS related third party tools, which deal with the creation/reading/writing/editing etc. of plists under MacOS, do either way (re)use Apple MacOS API functions, or implemented own routines for handling Apple's plist format.

[R C-R]

7 minutes ago, v_kyr said:

Most MacOS related third party tools, which deal with the creation/reading/writing/editing etc. of plists under MacOS, do either way (re)use Apple MacOS API functions, or implemented own routines for handling Apple's plist format.

So basically, they may or may not use the same API calls that plutil uses? Either way, when all is said & done does it matter as long as they deal with them properly?

[v_kyr]

27 minutes ago, R C-R said:

So basically, they may or may not use the same API calls that plutil uses?

It depends, for pure MacOS only apps & tools sure, why should they reinvent the wheel and not reuse Apple's APIs. - Other third party tools, those who have to support multiple platforms, may instead reuse for their MacOS support calls to "plutil" instead then. - See for example ...

• vim-plist
• Emacs OSXPlist
• ...etc.

27 minutes ago, R C-R said:

Either way, when all is said & done does it matter as long as they deal with them properly?

If any tool does what it should and finally generates what one needs, namely valid & correct working plist-files, then it doesn't matter at all what/which tool you use. You then just take what is the most comfortable or practicle for you.

[v_kyr]

It seems I've forgotten above to mention and point to an "plutil"-independent plugin-solution for creating/modifing/altering plist-files. 

Another very popular, powerfull and fast operating multi-platform available editor is "Sublime Text". There is a nice add-on BinaryPlist package available for Sublime, which works without the need of "plutil", since it's Python based (Sublime comes with a build-in Python for extending the editor) and thus has cross platform support for plists. - See:

• BinaryPlist

 

[v_kyr]

Ok so far we discussed more what MacOS binary PLIST based Affinity app related prefs settings are, how they look like, where those are stored and how we can change values for certain keys in those etc.

Now it's time to make things slightly easier here for MacOS users, in order to list and change such app related prefs settings then. Thus we will now use instead the MacOS defaults system (see in a terminal window also: > man defaults) to alter the specific "ShowFrameTextRuler = YES | NO" plist key/value pair. - I will in the following only briefly describe the steps to do here, the rest can be seen by reading the defaults man pages or some internet articles about the MacOS defaults system.

1. To read out all the Affinity Designer prefs settings (the contents & settings of it's binary plist file) we can inside a terminal call ...

   Quote

   > defaults read -app "Affinity Designer"

   ... this will list ALL the ADe prefs settings inside the terminal window.

2. Since we are only interested to see the actual "ShowFrameTextRuler" key/value pair assigned setting, we call defaults instead this way ...
    

   Quote

   > defaults read -app "Affinity Designer" ShowFrameTextRuler
   0

   ... the returned 0 indicates that the value (a boolean for ShowFrameTextRuler) is 0 = False|No, so this option isn't enabled yet.

3. Now we will change the ShowFrameTextRuler option to True/Yes = 1, in order to enable it for ADe ...
    

   Quote

   > defaults write -app "Affinity Designer" ShowFrameTextRuler -bool TRUE
         ... or altenatively ...
   > defaults write -app "Affinity Designer" ShowFrameTextRuler -bool YES
       ... or as another altenative ...
   > defaults write -app "Affinity Designer" ShowFrameTextRuler '<true/>'

    

4. And in order to set it back again to ShowFrameTextRuler option to False/No = 0, disabling it again then ...

   Quote

   > defaults write -app "Affinity Designer" ShowFrameTextRuler -bool FALSE
         ... or altenatively ...
   > defaults write -app "Affinity Designer" ShowFrameTextRuler -bool NO
       ... or as another altenative ...
   > defaults write -app "Affinity Designer" ShowFrameTextRuler '<false/>'

 

This way the whole enabling/disabling of that ShowFrameTextRuler option value can be eased. - Of course this way it can also be used in shell scripts or applescripts, in order to automate and toggeling the switching here then.

ONE final NOTE: the corresponding Affinity app has of course to be closed (not running), when altering the settings via the Apple default system here!

[walt.farrell]

As this is being discussed in two topics, I thought it might be worthwhile to point to a posting in the other one by @Patrick Connor, as it's equally relevant here

 

[v_kyr]

Yes, usage is on an users own risk here and nothing which is supported by Serif at all then. - People should be aware of that, especially unexperienced Mac users and the like!

[R C-R]

3 hours ago, v_kyr said:

Of course this way it can also be used in shell scripts or applescripts, in order to automate and toggeling the switching here then.

ONE final NOTE: the corresponding Affinity app has of course to be closed (not running), when altering the settings via the Apple default system here!

I am not going to do this myself since should I want to enable this 'try-at-your-own-risk' hack as I have mentioned earlier I will just do it using BBEdit, but for those interested in the script method it should be relatively easy to create an AppleScript app that first reports the current setting for showing or hiding the Frame Text ruler, if set to the app default warns that changing it is entirely at the user's risk & invalidates Serif's support, & then if the user elects to go ahead & change it to show the ruler then makes sure the Affinity app is not running before continuing & warns that it should be quit before continuing.

This could also have an option to apply to both AD & AP or to just one or the other.