Show & hide file extension programmatically

[MattM]

There are all sorts of OSC commands (see Workspace methods) that require you to address a particular workspace by name.  

The exact name you have to use depends on whether the workspace's file extension is "shown" or "hidden" in the Finder.  So, using the example in the QLab documentation, if your workspace filename is "hamlet", when you address it in OSC, your commands will have to be either, e.g.: 

/workspace/hamlet.qlab4/go

if the extension is shown in the Finder, or

/workspace/hamlet/go

if it's hidden.  

For a number of reasons not relevant here (the least of which is that I have a lot of cues already written to do so), I run my workspace with the extension hidden.

Now, here's the problem.  I use Dropbox as a central repository for my shows.  I don't keep Dropbox open while the actual show is running, but during editing and development time, it makes it easy to move between different machines and ensure you're looking at the current version of the show.  

Dropbox, it turns out, has a nasty habit of fiddling with the shown/hidden state of particular files in macOS.  It seems to prefer to show the extension, even if it's been set to "hidden" elsewhere.  I assume this has something to do with Finder states, .plists, .ds_store files, etc. not being cleanly tracked by Dropbox across network shares.

Whatever Dropbox's reason is, because QLab's OSC workspace methods depend on the filename being stable (and because OSC fails silently), I'm trying to write a quick AppleScript check into an "on startup" cue that will ensure that the file extension is properly shown or hidden.

Any script that's going to be incorporated into a QLab workspace, obviously, has to run the script with the workspace open.  So, say your extension is hidden and you want to show it.  On startup, assuming your workspace "hamlet.qlab4" is in your Dropbox, you could run a cue that looks something like this:

tell application "Finder"

set some_file to alias "Macintosh HD:Users:[myaccount]:[Dropbox Folder name]:hamlet.qlab4"

set extension hidden of some_file to true

end tell

When you execute this script with hamlet.qlab4 open, QLab seems to cleanly detect that the shown/hidden state has changed, and will update the workspace name in the title bar to SHOW the extension.

Now suppose the workspace's file extension is showing, and you want to hide it.  The script for that is simply:

tell application "Finder"

set some_file to alias "Macintosh HD:Users:[myaccount]:[Dropbox Folder name]:hamlet.qlab4"

set extension hidden of some_file to false

end tell

Here's what's funky.  QLab does NOT update its displayed workspace name in response to the "hide extension" script.  Sometimes it will continue working, albeit with the wrong display title still showing the extension; sometimes you get a SWOD and have to force quit.

I would also note that this behavior seems to be similar if you just simply open the "Get Info" window and check/uncheck the "hide extension" box.  If the extension is currently hidden, and you unhide it, QLab seems to immediately pick up on that change and will immediately update the name of the workspace in the title bar.  If you are showing the extension and check the box to hide it, QLab does not seem to ever update the name in the title bar.

Is this a fixable thing?  Or does this fall under the category of "things you shouldn't do while the workspace is open, because QLab gets confused"...?  

I guess I can always run a startup check that merely checks to confirm that the state of the show/hide flag is set properly, and if it isn't, throw a dialog to warn the user to close the workspace, correct it in the Finder, and then reopen the workspace.  Given that QLab seems to do a remarkable job of tracking changes to file names in the file system on the fly, I thought it was worth asking if this is just an oversight.

[Chris Ashworth]

Hi MattM,

In this particular case, if the document has been saved to disk, we call straight to the Apple code for the display name, and also rely on the Apple frameworks to track when a document has been changed externally and needs to be refreshed.  So, it sounds like your excellent investigation has uncovered some oddities about how the document frameworks function in macOS.

It’s conceivable that we might investigate trying to enhance or tweak this behavior, but candidly I think it’s probably best to leave it as-is, using the baked-in behavior. 

That said, it seems to me that we could back up to the motivating reason for the question, which is addressing a workspace by name.  Right now the incoming OSC address string is used to search whatever names the current open documents display. However, it strikes me that it would be easy and friendlier for us to add another pass to search the list of current document names with any file extensions removed.  

I’ll file an issue in our tracker to look into tweaking this.

-C

[Chris Ashworth]

Ha, turns out that issue already existed in our tracker; adding a note to it now about a specific approach to take, and bumping the priority.

-C

[MattM]

funny!  Although I know we've talked about this on the forum before -- the need to be specific about the presence or absence of the extension.  Having some flexibility about whether this preference is set or now would certainly be a welcome thing when we're dealing with OSC and file paths,.  

Thanks for the response!

Matt

[Richard Williamson]

Also to add to this, as far as I can see qlab doesn’t issue an osc update when the user changes the file name of the current workspace (through file-save as) which feels like an omission 

Sent from my iPhone

On 5 Mar 2020, at 16:43, 'MattM' via QLab <ql...@googlegroups.com> wrote:



--
Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/e8dc9a7f-032a-4b15-9b9d-d72c1fc94377%40googlegroups.com.

[MattM]

A bit more weirdness I've just discovered...

Say you have a file called <Some Audio File.aif> on the root level of your hard drive.

At the moment, you've got it set to SHOW the file extension.

Run this script:

tell application "Finder"

set thisFile to alias "Macintosh HD:Some Audio File.aif"

open thisFile

end tell

Assuming you have iTunes set to be the application associated with .aif files, this will cause the file to open in iTunes and start playing.

Now, having changed nothing else, take the .aif off the alias declaration in the above script, so that it now reads:

tell application "Finder"

set thisFile to alias "Macintosh HD:Some Audio File"

open thisFile

end tell

This will throw a compile error.  AppleScript looks for the file, and not finding it, will not even compile this script.

Now comes the weirdness.  In the Finder, select your audio file and choose "Get Info."  Click the check box to "hide file extension" so that it now displays as just "Some Audio File" in the Finder.

Run the first script above, with the file extension included in the alias:

tell application "Finder"

set thisFile to alias "Macintosh HD:Some Audio File.aif"

open thisFile

end tell

Even though we've changed the display name of the file to NOT show the extension, this script will still compile and run.  It's as if macOS gives the user a free pass and allows you to specify the extension, even if it's hidden.

NOW, try running the second script again -- the one that failed above when the extension was showing:

tell application "Finder"

set thisFile to alias "Macintosh HD:Some Audio File"

open thisFile

end tell

with the extension hidden in the Finder -- surprise!  The above script now compiles and, if you run it, iTunes will launch and start playing the file.

So, to review:

1) If the extension is visible in the Finder, the extension is required and you cannot reference the file in an AppleScript alias without including the extension in the alias declaration.  Otherwise, the script will not even compile.

2) If the extension is hidden in the Finder, it doesn't matter whether you include the extension or not.  MacOS pattern-matches on both, and both will compile and execute without incident.

My initial thought after we were chatting about this earlier today was to suggest that "well, macOS always requires you to include the extension, so, for maximum "mac-like" behavior, and for consistency's sake, in QLab's implementation of AppleScript and OSC, we should always be required to include the extension as well."  

But it turns out that macOS is actually surprisingly inconsistent on this point, too.  

My next thought was, if the F53 folks are going to add, as Chris says, an extra pass to search the current document names with any file extensions removed, would that mean that QLab's OSC queries would pattern-match on both, e.g. "hamlet" and "hamlet.qlab4", but AppleScript would not?  Are you able to do the same kind of extra pass on AppleScript statements passed to QLab, though?  Or is an AppleScript statement passed to QLab going to fail according to the same criteria I've laid out above?

Ideally macOS would be consistent about this; it's not.  I guess the question is whether the fix -- adding an extra pattern-matching pass -- is going to fix OSC but break AppleScript (or have no effect on AppleScript's default behavior, because it's a file system call?) on this point.  

So my other thought/observation was -- if macOS will *always* accept references to a file if the extension is included, at the very least, maybe QLab should follow the same policy?  That is, if you've got your workspace set to hide the extension -- "hamlet" -- you can still specify "hamlet.qlab4" in your OSC statements (and, as shown above, your Applescripts) -- and they will always work.  

Having QLab ignore "hamlet.qlab4" when the extension is hidden has always felt like the wrong behavior to me, more so than the other way around.

[Rich Walsh]

I think it's more a quirk of scripting the Finder than the macOS itself – it's not 100% clear whether the Finder is using "name" or "displayed name" as the property for identifying a Finder item and it seems to be allowing you to be inexact in your address if the extension is hidden by trying both (as Chris has suggested for QLab). If the extension isn't hidden then neither property matches the name without the extension.

If you don't put the alias inside a Finder tell block it will not accept anything other than the precise name of the file (including the file extension). I think.

Whether or not the extension is shown is purely a Finder concept. Drag and drop (or alt-right-click) a file to get its path and the result doesn't care what the Finder shows.

Rich

[MattM]

This issue is FIXED in QLab 4.6.3, released today!  Thanks for jumping on this, guys!

Matt

On Thursday, March 5, 2020 at 9:43:07 AM UTC-5, Chris Ashworth wrote: