Here are the items that I’m using currently in macoslib:
NSStatusBar
NSImage
NSMenu
NSMenuItem
NSUserNotificationCenter
MacPListBrowser
Among other things, I’m using NSPopover.
[quote=184807:@Charles Yeomans]@Michel Bujardet Congratulations for your idea.
I guess Jason King and Ulrich Bogun who each went through that transition can probably tell what you have to look for. I remember also posts from Norman explaining what was necessary to make code 64 bit safe.
Yep; 64-bitness would be of course part of the plan.[/quote]
To be honest, I started to write a similar library like iOSLib for OS X a time ago to have it 64bit savvy and a bit easier to work with. I have switched to iOS a few weeks ago but will return soon now that iOSLib SpriteKit is almost done (and waiting for comments and hints where it could be made easier to handle), I’d love to see it on OS X when 64 bit comes out too. I don’t know if what I have so far could be any help for you, Charles, but I’d gladly share it.
NSStatusBar, NSMenu, NSMenuItem, NSUserNotificationCenter, NSWindow, NSPopover, NSSearchField, System Icon extensions and various items from the Additional Modules.
Thanks. All of the NS* items are working in 64-bit except where there are (known) framework issues. I have not yet decided what to do about most of the Additional Modules code.
The hope is for some of the Additional Modules to remain, especially those relying on Declares and (of course) not covered by Xojo, like pushbutton.image, popupmenu.pullsdown, popupmenu.settitle, GZip/Gunzip, macSpeechSentithizer.
Will TT’s SmartPreferences be migrated to 64 bit? I hope so since it works so well.
I’d suggest using the CFPreferences in MacOSLib directly as they use the OS API’s to read / write the plist which is truly the correct sanctioned way to do it
Just to be a stickler in the mud here… Yes, using CFPreferences or NSUserDefaults is the Apple recommended way to read and write preferences on OS X.
However; because of the way the system now works, you cannot reset the preferences by simply deleting the preferences file. In fact, if you do delete the preferences file, it breaks the application preferences until the cfrprefs daemon is killed or you restart Windows, I mean OS X. I’ve even found that simply modifying the plist file in Xcode can break the apps prefs also.
You need to use either APIs or the defaults terminal command to reset the preferences.
Apple have always advised against manually editing or removing the plist file, its just that now there are consequences if you do.
The alternative is to use your own system and write the preferences file to the application support folder.
I can confirm (more or less):
I modify a Finder preferences file, but I start to quit the Finder, then run XCode and modify that prefs file, then quit XCode and run the Finder.
Why must I do that (why the Finder or OS X create crashy plist file is a different matter that I hope will be changed with 10.11 (and so the hard disk contagion at Utilities repair time)…
Simply put, as a developer you should be using the APIs to modify the preferences, this allows Apple the freedom to move from individual files to say a SQL database or even a Windows Registry type thing.
I don’t see it getting easier with 10.11, if anything they’re probably working on making it harder to manually edit the preference files.
As for the permissions issues, heck these have been around ever since ACLs got introduced (effectively hidden settings to the end user). For all most all users, permissions are hassle. A better system is needed and that’s what ‘Rootless’ was rumored to be, I guess we’ll find out when 10.11 is mainstream enough to have a significant user base.
@Sam: I simply delete all values of a plist files. Works very well. There is no need to delete the file itself. Thomas Tempelmann has an app called Prefs Editor (see http://www.tempel.org/PrefsEditor), which can do this with a couple of clicks.
I was under the impression that TT’s SmartPreferences in the additional modules of MacOSLib used CFPreferences?
Also, I thought that the other advantage of using TT’s SmartPreferences was to have cross platform compatibility as well.
I was hesitant to use MacOSLib from the beginning since it is so large. I have tried to carve out just the part needed for TT’s SmartPreferences with little success (ended up being a large portion of the library). I really hope that this capability is not dropped.
I really, really hope that a future version of Xojo provides an easy to use preferences capability that is cross platform.
[quote=198581:@William James]I was under the impression that TT’s SmartPreferences in the additional modules of MacOSLib used CFPreferences?
[/quote]
Had a more thorough look & it LOOKS like my initial comment was wrong & it is using cfpreferences when you do not force it to store preferences in the app support folder
There’s a bunch of feedback requests, a quick search revealed the following.
<https://xojo.com/issue/18346> Excuse my terrible spelling mistakes there!
<https://xojo.com/issue/34747>
<https://xojo.com/issue/19082>
I agree with Charles - the macoslib has become too big and convoluted. Too many dependencies between parts that shouldn’t be necessary. I maintain my own lighter version and use Arbed to merge improvements from the main version into mine.
Though I do not understand why converting CGFloat related code is still a problem. Didn’t we conclude many months ago that we need a smart float type that adjusts its size for this purpose, just like Integer does? Has Xojo denied us this request or did I misunderstand the usefulness of such a type?
[quote=213356:@Thomas Tempelmann]I agree with Charles - the macoslib has become too big and convoluted. Too many dependencies between parts that shouldn’t be necessary. I maintain my own lighter version and use Arbed to merge improvements from the main version into mine.
Though I do not understand why converting CGFloat related code is still a problem. Didn’t we conclude many months ago that we need a smart float type that adjusts its size for this purpose, just like Integer does? Has Xojo denied us this request or did I misunderstand the usefulness of such a type?[/quote]
They have denied any such request, and I can see the point of doing so.
I have rewritten the core of macoslib over the last months, and it is now 64-bit compatible, except for anything I’ve overlooked. It now includes a plugin for controls and blocks, and a start on documentation to be built using sphinx. I’ve held off getting it available in part because the plugin uses the new SDK.
What’s the issue with the new SDK? I am not up-to-date on that.
The main issue is that it’s part of 2015r3, which remains in beta.
Ah, that makes sense.