OpenXTalk Forums

I got some work done on OXT (in-between things like my niece graduation party, and repainting my bathroom and my mom returning to hospital care) this weekend. Also I did a bit research into a few OXT related things.

I had certain ancient stacks that HyperCardPreview was claiming were not valid Stack files. However If added .stak to the filename, then HyperCardPreview would display them just fine. The problem it turns out, is that in the initial state HC Preiew only seems to check for Mac Classic related WILD/STAK Creator and Type codes for HC Stack validity, which is a long deprecated by Apple thing but still in used sometimes. OXT doesn't have this problem because I have it so when you try to open a non-LC or OXT stack it will reads the first 8 bytes of that file and check to see if it contains "STAK" 'magic number' and if true then, if HyperCardPreview.app is available, OXT will launch the HyperCard stack file with HyperCardPreview.app for examination. But sometimes HCP wouldn't open them and now I know why.
Fortunately (and for good reasons) Apple has seen fit to keep the Creator/Type Codes attributes around in modern macOS/APFS as HFSCreator and HFSType attributes. However there was no way to set those from OXT other than perhaps rewriting the entire contents for the stack file out from our engine after setting those properties. So I've added a few NSFilemanager things to OXT's Mac-os-native tools for setting the retro HFS Type/Creator codes attributes. It works here, I was able to create a handler to set the HFS Creator to 'WILD' (HyperCard was originally called WildCard). You may have permissions issues if you try to use it as a non-admin or on a foreign volume type or something like that. I've done minimal beta-testing. This obviously is mostly only useful for retro purposes, at this point very old files and old mac apps like HC, and it was done basically as an experiment in using NSFileManager from builder.

That NSFileManager (https://developer.apple.com/documentati ... attributes) can do all sorts of things though, and those NSAttributes (NSDictionary type) that I'm setting the 4-char creator OStype with, contains a bunch more attributes that can be read and some can be written to, so I could theoretically add handlers to change file/folder creation dates or modification timestamp (not just 'touch'), or read/write a files Posix permissions (as long as have user rights to). As well as the rest of NSFileManager, create those URL .*loc files (like .fileloc, .afploc .webloc, .vncloc, etc.), Mac aliases, abstract file reference objects, or Posix symbolic links, iCloud files and more!

Now this has me thinking again about wrapping more NS* and doing that in a cross-platform way.
What I mean is GNUStep Base contains a LOT of what I'm using from Apple in some of these 'native' Builder extensions I've worked on. GNUStep is a FOSS cross platform framework that contains open-source versions of NextSTEP/OpenSTEP APIs, the 'Base' parts of which are rough equivalents to Apple's 'CoreFoundation' stuff ... the bottom line is that there is a bunch of really useful methods and object types in GNUStep for working with URLs, Files, Arrays, Images, and all sorts of data. We could expand OXTs capabilities a lot, and in cross-platform way if GNUStep can be tapped! Hopefully using Objective-C FFI on non-Apple platform (Linux/Win) isn't a problem for the Builder VM...

Nice find! Don't take this the wrong way... if it's not stealing (seems not,) use it. I won't comment on stealing except a little "good artists copy, great artists steal." Which is a no bueno double bad, of course and shouldn't be OXT philosophy, IMO.

overclockedmind wrote: ↑Tue Jun 28, 2022 4:41 am Nice find! Don't take this the wrong way... if it's not stealing (seems not,) use it. I won't comment on stealing except a little "good artists copy, great artists steal." Which is a no bueno double bad, of course and shouldn't be OXT philosophy, IMO.

GNUStep libs should be ok to use, license-wise anyway, but I will have to test this theory out on Linux/Win before I get too excited about it.

------------------------------------------------------------------------------------------------------------------------------------------------

I could use some help tracking this problem down...
I'm trying to find this bug related to the revMenuBar/toolbar. It's one of those bugs that irks me and one that I initially wanted to fix when I started working on OXT. That bug is this: on macOS when you place certain IDE palettes over top of the revMenuBar's Toolbar, mouse clicks get offset by some 20 - 40 pixels so you have to click about 3/4ths inch below what you actually wanted to click or just move the palette away from on top of the toolbar. The IDE is supposed to automatically reposition any stack placed above the toolbar, but that only fires some of the time! I've read there is also likely related problems with multiple monitors and the revMenubar toolbar being positioned at the bottom of the screen. Anway, for the life of me I can not find where in the IDE stack or behavior scripts where this broken feature is exactly, so I can fix it or remove that behavior all together.

The alternative idea I was thinking could be to replaced the revMenuBar's 'toolbar' entirely, replacing it with a new, separate, user-positionable, toolbar palette. Perhaps it would be something similar Andy Paddock's TinyIDE add-on, but in a palette window, with some font tools, color/style swatch tools, alignment tools, and no redundant (on macOS at least) copy of the IDE's menus.

I'm considering adding GLX2 Script Editor (https://github.com/mwieder/glx2ScriptEditor) and then adding a Script Editor selector menu in the revPreferences. The current maintainer Mark Wieder said go for it, so that' good.
It has some really nice feature, user handler grouping (by adding specifically formatted comment marks), auto-completion with 'clairvoyance' (GLX2 SE's take on auto-complete 'Snippets'), hyperlink handlers with breadcrumbs trail and more!

It also lacks some things that the built-in script editor has, specifically it lacks the 'available handlers' list under the used handlers list on the left side panel of SE windows and nor does GLX honor the default scripts folder that is part of the IDE and can also be part of a Widget package.

Maybe the two editors could be merged into one that is the best of both, and then add new features (it would be great to have an 'Extension Builder' code editor included in the IDE)

Bottom line is, at a minimum I'd like to add some autocompletion and/or a choice of script editors (perhaps allowing for external code editors too, such as VSCode or Atom).