Date   

Re: zoomed attribute of tabbed fullscreen windows

Jean-Christophe Helary <jean.christophe.helary@...>
 

On Oct 15, 2017, at 20:54, Jean-Christophe Helary

BBEdit's weirdness: regardless of whether the window is new (default size) or fullscreen BBEdit's windows keep the same bounds ({0, 22, 1009, 800} on my screen). Position is thus {0, 22} regardless of the state of the window.
This returns 0,0 only when in full screen here:

tell application "BBEdit"
window 1's position
end tell
You're right. It looks like there is a lag between the moment the window changes status and the moment Script Debugger's Explorer gets the value, at leat on my machine...

Jean-Christophe
Well, it looks like I was either wrong or not looking at the right thing, or maybe SB was busy and did not update the values right away, but now that I am checking, there is no significant lag between the modification and the display...

Jean-Christophe


Re: zoomed attribute of tabbed fullscreen windows

Jean-Christophe Helary <jean.christophe.helary@...>
 



On Oct 15, 2017, at 19:48, 2551phil <2551phil@...> wrote:


On 15 Oct 2017, at 15:49, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

BBEdit's weirdness: regardless of whether the window is new (default size) or fullscreen BBEdit's windows keep the same bounds ({0, 22, 1009, 800} on my screen). Position is thus {0, 22} regardless of the state of the window.

This returns 0,0 only when in full screen here:

tell application "BBEdit"
window 1's position
end tell

You're right. It looks like there is a lag between the moment the window changes status and the moment Script Debugger's Explorer gets the value, at leat on my machine...

Jean-Christophe 


Re: zoomed attribute of tabbed fullscreen windows

2551phil
 


On 15 Oct 2017, at 15:49, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

BBEdit's weirdness: regardless of whether the window is new (default size) or fullscreen BBEdit's windows keep the same bounds ({0, 22, 1009, 800} on my screen). Position is thus {0, 22} regardless of the state of the window.

This returns 0,0 only when in full screen here:

tell application "BBEdit"
window 1's position
end tell




Best


Phil
@sqwarq


Re: zoomed attribute of tabbed fullscreen windows

2551phil
 


On 15 Oct 2017, at 16:46, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

It seems to use accessibility wizardry

AXFullScreen isn’t much use to use for reasons the poster points out - it’s too limited. I don’t see anything else in the scripts there that we haven’t already established here. 

It may well be that a full answer here is going to have to combine all the various different strategies that we’ve been discussing, including using NSScreen to get the display size(s) and comparing that to window frame sizes.


Best


Phil
@sqwarq



Re: zoomed attribute of tabbed fullscreen windows

2551phil
 


On 15 Oct 2017, at 16:02, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

Windows that are not in fullscreen have a "Enter Fulls Screen" menu item. Windows that are in Fullscreen have a "Exit from Full Screen" menu item.


Yes, I noticed that yesterday, but I assume that property changes depending on which window is front most. 

I haven’t had a look at the SO page yet, but thanks for pointing it out. I’ll look into it later on.


Best


Phil
@sqwarq


Re: zoomed attribute of tabbed fullscreen windows

2551phil
 

Yes, I see that now. I have my Dock set vertically on the left hand side and that prevented me from seeing the false positives. One could test for the size of the display and the size of the window and see fi there’s a regular correlation across apps in full screen, as well as whether the Dock is visible or not.

I’ll have a bit more of a play around with it later.


Best


Phil
@sqwarq



On 15 Oct 2017, at 15:41, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

Phil,

Your script doesn't work for windows that are just zoomed on screens where the menu is automatically hidden. Also I had false positives with position = {n, 0} for windows that just happened to be in the top corner.

I had the same problem with Terminal. With the menu hidden I still have the window chrome that takes 1 row, in fullscreen I have the extra row.

Jean-Christophe 

On Oct 15, 2017, at 17:05, 2551phil <2551phil@...> wrote:


On 14 Oct 2017, at 18:41, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

I think I found a simple solution


Cool, but I’d like to explore this is a bit further as it’s a specific example of a more general problem that could do with a solution: how to determine which apps/windows are in full screen across multiple displays?

As a proof of concept, the following works here on a dual display setup with multiple spaces. It correctly returned the full screen windows for all my running apps. It also appears to cope with split screen situations, too. 

I’m sure Shane or others can improve upon my sloppy scripting style though. :p





use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

#######################
-->> VARIABLES
#######################
set fullScreenApps to {}
set msg to "None"

#######################
-->> HANDLERS
#######################

on hasFullScreen:theApp forWindow:aWin
set theReply to {false, 0, missing value}
tell application theApp
try
set yPos to item 2 of (get bounds of window aWin)
on error
set yPos to 1
end try
if yPos is 0 then
try
set winName to window aWin's name
on error
set winName to missing value
end try
set theReply to {true, aWin, winName}
end if
end tell
return theReply
end hasFullScreen:forWindow:


on getVisibleProcs()
set visibleProcs to {}
tell application "System Events"
set procs to every application process
repeat with i from 1 to count of procs
set this_proc to item i of procs
try
if this_proc's visible is true then
set end of visibleProcs to this_proc's name
end if
end try
end repeat
end tell
return visibleProcs
end getVisibleProcs

#######################
-->> COMMANDS
#######################

set currentApps to getVisibleProcs()
repeat with a from 1 to count of currentApps
set this_app to currentApps's item a
try
tell application this_app
set wc to count of its windows
repeat with w from 1 to wc
set hasFs to (my hasFullScreen:this_app forWindow:w)
if hasFs's item 1 is true then
set end of fullScreenApps to {this_app, hasFs's item 2, hasFs's item 3}
end if
end repeat
end tell
end try
end repeat

if (count of fullScreenApps) is greater than 0 then
set msg to ""
repeat with i from 1 to count of fullScreenApps
set this_item to item 1 of item i of fullScreenApps as text
set this_item to this_item & "'s Window " & item 2 of item i of fullScreenApps as text
set this_item to this_item & ":  " & item 3 of item i of fullScreenApps as text
set msg to msg & this_item & return
end repeat
end if
display dialog msg with title "Windows that are in full screen" buttons "OK" default button "OK"







Best


Phil
@sqwarq



Re: zoomed attribute of tabbed fullscreen windows

2551phil
 

Back to the drawing board. Looks like BBEdit doesn’t play by the 0 bounds rule for either position.



On 15 Oct 2017, at 15:23, 2551phil <2551phil@...> wrote:


On 15 Oct 2017, at 15:05, 2551phil <2551phil@...> wrote:

It correctly returned the full screen windows for all my running apps.


With the exception of Script Debugger and Script Editor, I see now. 

Interestingly, both these have item 1 of their bounds set to 0 when in Full Screen rather than item 2. I’ll need to do a bit more testing, but perhaps testing for either item 1 or item 2 being 0 might solve that, so long as it’s not possible for either to be 0 when not in full screen.



Best


Phil
@sqwarq




On 15 Oct 2017, at 15:05, 2551phil <2551phil@...> wrote:


On 14 Oct 2017, at 18:41, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

I think I found a simple solution


Cool, but I’d like to explore this is a bit further as it’s a specific example of a more general problem that could do with a solution: how to determine which apps/windows are in full screen across multiple displays?

As a proof of concept, the following works here on a dual display setup with multiple spaces. It correctly returned the full screen windows for all my running apps. It also appears to cope with split screen situations, too. 

I’m sure Shane or others can improve upon my sloppy scripting style though. :p





use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

#######################
-->> VARIABLES
#######################
set fullScreenApps to {}
set msg to "None"

#######################
-->> HANDLERS
#######################

on hasFullScreen:theApp forWindow:aWin
set theReply to {false, 0, missing value}
tell application theApp
try
set yPos to item 2 of (get bounds of window aWin)
on error
set yPos to 1
end try
if yPos is 0 then
try
set winName to window aWin's name
on error
set winName to missing value
end try
set theReply to {true, aWin, winName}
end if
end tell
return theReply
end hasFullScreen:forWindow:


on getVisibleProcs()
set visibleProcs to {}
tell application "System Events"
set procs to every application process
repeat with i from 1 to count of procs
set this_proc to item i of procs
try
if this_proc's visible is true then
set end of visibleProcs to this_proc's name
end if
end try
end repeat
end tell
return visibleProcs
end getVisibleProcs

#######################
-->> COMMANDS
#######################

set currentApps to getVisibleProcs()
repeat with a from 1 to count of currentApps
set this_app to currentApps's item a
try
tell application this_app
set wc to count of its windows
repeat with w from 1 to wc
set hasFs to (my hasFullScreen:this_app forWindow:w)
if hasFs's item 1 is true then
set end of fullScreenApps to {this_app, hasFs's item 2, hasFs's item 3}
end if
end repeat
end tell
end try
end repeat

if (count of fullScreenApps) is greater than 0 then
set msg to ""
repeat with i from 1 to count of fullScreenApps
set this_item to item 1 of item i of fullScreenApps as text
set this_item to this_item & "'s Window " & item 2 of item i of fullScreenApps as text
set this_item to this_item & ":  " & item 3 of item i of fullScreenApps as text
set msg to msg & this_item & return
end repeat
end if
display dialog msg with title "Windows that are in full screen" buttons "OK" default button "OK"







Best


Phil
@sqwarq



Re: zoomed attribute of tabbed fullscreen windows

2551phil
 


On 15 Oct 2017, at 15:05, 2551phil <2551phil@...> wrote:

It correctly returned the full screen windows for all my running apps.


With the exception of Script Debugger and Script Editor, I see now. 

Interestingly, both these have item 1 of their bounds set to 0 when in Full Screen rather than item 2. I’ll need to do a bit more testing, but perhaps testing for either item 1 or item 2 being 0 might solve that, so long as it’s not possible for either to be 0 when not in full screen.



Best


Phil
@sqwarq




On 15 Oct 2017, at 15:05, 2551phil <2551phil@...> wrote:


On 14 Oct 2017, at 18:41, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

I think I found a simple solution


Cool, but I’d like to explore this is a bit further as it’s a specific example of a more general problem that could do with a solution: how to determine which apps/windows are in full screen across multiple displays?

As a proof of concept, the following works here on a dual display setup with multiple spaces. It correctly returned the full screen windows for all my running apps. It also appears to cope with split screen situations, too. 

I’m sure Shane or others can improve upon my sloppy scripting style though. :p





use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

#######################
-->> VARIABLES
#######################
set fullScreenApps to {}
set msg to "None"

#######################
-->> HANDLERS
#######################

on hasFullScreen:theApp forWindow:aWin
set theReply to {false, 0, missing value}
tell application theApp
try
set yPos to item 2 of (get bounds of window aWin)
on error
set yPos to 1
end try
if yPos is 0 then
try
set winName to window aWin's name
on error
set winName to missing value
end try
set theReply to {true, aWin, winName}
end if
end tell
return theReply
end hasFullScreen:forWindow:


on getVisibleProcs()
set visibleProcs to {}
tell application "System Events"
set procs to every application process
repeat with i from 1 to count of procs
set this_proc to item i of procs
try
if this_proc's visible is true then
set end of visibleProcs to this_proc's name
end if
end try
end repeat
end tell
return visibleProcs
end getVisibleProcs

#######################
-->> COMMANDS
#######################

set currentApps to getVisibleProcs()
repeat with a from 1 to count of currentApps
set this_app to currentApps's item a
try
tell application this_app
set wc to count of its windows
repeat with w from 1 to wc
set hasFs to (my hasFullScreen:this_app forWindow:w)
if hasFs's item 1 is true then
set end of fullScreenApps to {this_app, hasFs's item 2, hasFs's item 3}
end if
end repeat
end tell
end try
end repeat

if (count of fullScreenApps) is greater than 0 then
set msg to ""
repeat with i from 1 to count of fullScreenApps
set this_item to item 1 of item i of fullScreenApps as text
set this_item to this_item & "'s Window " & item 2 of item i of fullScreenApps as text
set this_item to this_item & ":  " & item 3 of item i of fullScreenApps as text
set msg to msg & this_item & return
end repeat
end if
display dialog msg with title "Windows that are in full screen" buttons "OK" default button "OK"







Best


Phil
@sqwarq


Re: zoomed attribute of tabbed fullscreen windows

2551phil
 


On 14 Oct 2017, at 18:41, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

I think I found a simple solution


Cool, but I’d like to explore this is a bit further as it’s a specific example of a more general problem that could do with a solution: how to determine which apps/windows are in full screen across multiple displays?

As a proof of concept, the following works here on a dual display setup with multiple spaces. It correctly returned the full screen windows for all my running apps. It also appears to cope with split screen situations, too. 

I’m sure Shane or others can improve upon my sloppy scripting style though. :p





use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

#######################
-->> VARIABLES
#######################
set fullScreenApps to {}
set msg to "None"

#######################
-->> HANDLERS
#######################

on hasFullScreen:theApp forWindow:aWin
set theReply to {false, 0, missing value}
tell application theApp
try
set yPos to item 2 of (get bounds of window aWin)
on error
set yPos to 1
end try
if yPos is 0 then
try
set winName to window aWin's name
on error
set winName to missing value
end try
set theReply to {true, aWin, winName}
end if
end tell
return theReply
end hasFullScreen:forWindow:


on getVisibleProcs()
set visibleProcs to {}
tell application "System Events"
set procs to every application process
repeat with i from 1 to count of procs
set this_proc to item i of procs
try
if this_proc's visible is true then
set end of visibleProcs to this_proc's name
end if
end try
end repeat
end tell
return visibleProcs
end getVisibleProcs

#######################
-->> COMMANDS
#######################

set currentApps to getVisibleProcs()
repeat with a from 1 to count of currentApps
set this_app to currentApps's item a
try
tell application this_app
set wc to count of its windows
repeat with w from 1 to wc
set hasFs to (my hasFullScreen:this_app forWindow:w)
if hasFs's item 1 is true then
set end of fullScreenApps to {this_app, hasFs's item 2, hasFs's item 3}
end if
end repeat
end tell
end try
end repeat

if (count of fullScreenApps) is greater than 0 then
set msg to ""
repeat with i from 1 to count of fullScreenApps
set this_item to item 1 of item i of fullScreenApps as text
set this_item to this_item & "'s Window " & item 2 of item i of fullScreenApps as text
set this_item to this_item & ":  " & item 3 of item i of fullScreenApps as text
set msg to msg & this_item & return
end repeat
end if
display dialog msg with title "Windows that are in full screen" buttons "OK" default button "OK"







Best


Phil
@sqwarq


Re: zoomed attribute of tabbed fullscreen windows

2551phil
 


On 14 Oct 2017, at 13:45, 2551phil <2551phil@...> wrote:


On 14 Oct 2017, at 09:38, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

Is there a way that does not involve using "bounds"… ?

We can use origin and position instead, so long as you have only one monitor, this should work. 

If you have an external display connected, you’ll have to test for the orig/pos of that display as well.



A slightly less-rough ’n’ ready version:


set fs to ""
set fsList to {}
set msg to "No windows in full screen."
tell application "Terminal"
repeat with i from 1 to count of its windows
set this_win to item i of its windows
if this_win's position is {0, 0} then
if this_win's origin is {0, 0} then
set fs to this_win's name
set end of fsList to fs
end if
end if
end repeat
end tell
if (count of fsList) is greater than 0 then
set msg to ""
repeat with i from 1 to count of fsList
set msg to msg & fs & return
end repeat
end if
display dialog msg with title "Terminal Full Screen Windows" buttons "OK" default button "OK"




Best


Phil
@sqwarq


Re: zoomed attribute of tabbed fullscreen windows

2551phil
 


On 14 Oct 2017, at 09:38, Jean-Christophe Helary <jean.christophe.helary@...> wrote:

Is there a way that does not involve using "bounds"… ?

We can use origin and position instead, so long as you have only one monitor, this should work. 

If you have an external display connected, you’ll have to test for the orig/pos of that display as well.

set wps to {}
set fs to ""
set fsList to {}
set msg to ""
tell application "Terminal"
repeat with i from 1 to count of its windows
set this_win to item i of its windows
if this_win's position is {0, 0} then
if this_win's origin is {0, 0} then
set fs to this_win's name
set end of fsList to fs
end if
end if
set end of wps to {this_win's origin, this_win's position}
end repeat
end tell
repeat with i from 1 to count of fsList
set msg to msg & fs & return
end repeat
display dialog msg with title "Terminal Full Screen Windows" buttons "OK" default button "OK"



Best


Phil
@sqwarq


How to auto open disk image

Brian Christmas
 

G’day folks.

The other day I wrote how the latest Sierra Security Update broke auto opening Zipped folders.

Turned out what it really broke was my Safari preferences. Unticking and re-ticking the ‘open safe’ box fixed it.

However, I now cannot get the unzipped dmg’s to display automatically. I’ve tried attaching a folder action, and ‘blessed' the opened disk image, before zipping it, but where it just all used to download and pop the dmg open, it stops at an unopened dmg in the Downloads folder. I wondered if zipping now does something different?



bless --openfolder /Volumes/Art\ Archiver




Any guidance, please?

Regards

Santa


Sierra update, another broken script!

Brian Christmas
 

G’day folks.

I thought I’d finished my App, but the latest Sierra has broken my Scroll Field scrolling.

The present script takes 1 minute to trim excessive paragraphs, and a whopping 10 minutes or more to simly scroll to the end.

Used to be lightning fast.

I’ve found this recommended method to now use, but canot work out how to re-write it for ASObC.

- (void)textDidEndEditing:(NSNotification *)notification {
    NSTextView *text = [notification object];
    unsigned whyEnd = [[[notification userInfo] objectForKey:@"NSTextMovement"] unsignedIntValue];
    NSTextView *newKeyView = text;
 
    // Unscroll the previous text.
    [text scrollRangeToVisible:NSMakeRange(0, 0)];
 
    if (whyEnd == NSTabTextMovement) {
        newKeyView = (NSTextView *)[text nextKeyView];
    } else if (whyEnd == NSBacktabTextMovement) {
        newKeyView = (NSTextView *)[text previousKeyView];
    }
 
    // Set the new key view and select its whole contents.
    [[text window] makeFirstResponder:newKeyView];
    [newKeyView setSelectedRange:NSMakeRange(0, [[newKeyView textStorage] length])];
}

My old script is below, and the handler ’ScrollToEnd’  literally freezes on lines 2 & 3. Up to 15 minutes.

AnyBody kind enough to decipher the above, please?

As well, is there a faster way of removing excess lines from the top of the field, leaving rthe first 4 lines alone?

Regards,

Santa

This  takes 1 minute

if (my reDrawTheText) then
set p to 1
set (my theYear) to year of (current date)
set adjustRange to (((my clientMax as integer) * 10) + 5) as integer
set textStorage to mainMessagesView's textStorage()
set textStorageString to mainMessagesView's |string|()
set theRange to (count of (textStorageString's paragraphs)) as integer
set theOffset to (count of paragraph 1 of textStorageString) + (count of paragraph 2 of textStorageString) + (count of paragraph 3 of textStorageString) + 4
if theRange > (adjustRange + 40) then
set c to current date
set theCount to 0
 try
set y to (theRange - adjustRange - 8)
if y > 14 then
repeat with x from 5 to y
try
set theCount to theCount + (count of characters of paragraph x of textStorageString) + 1
on error errmsg
if (my runForOz) then tell application "System Events" to display dialog errmsg giving up after 20
exit repeat
end try
end repeat
end if
end try
set textStorage to mainMessagesView's textStorage()
tell textStorage to replaceCharactersInRange:{theOffset, theCount} withString:""
set textStorageString to mainMessagesView's |string|() as text
set theRange to (count of (textStorageString's paragraphs)) as integer
end if
set textStorageString to mainMessagesView's |string|() as text
set theRange to (count of (textStorageString's paragraphs)) as integer
 if theRange > adjustRange then
repeat
set textStorage to mainMessagesView's textStorage()
set textStorageString to mainMessagesView's |string|() as text
set theRange to (count of (textStorageString's paragraphs)) as integer
set textStorageLength to ((count of paragraph 5 of textStorageString) + 1) as integer
set theText to (paragraph 5 of textStorageString) as text
try
if ((word 1 of theText) as text) is in {"eMail", "ftp"} and theRangeadjustRange then exit repeat
end try
tell textStorage to replaceCharactersInRange:{theOffset, textStorageLength} withString:""
end repeat
end if

This takes 10-15 minutes, for 2000 paragraphs

on scrollToEnd()
try
say 1
set textStorage to mainMessagesView's textStorage()
say 2
set newTextLength to textStorage's |length|() as integer
say 3
if newTextLength > 40 then mainMessagesView's scrollRangeToVisible:{location:newTextLength, |length|:0}
say 4
end try
end scrollToEnd


Re: Important question, please?

2551phil
 

On 22 Sep 2017, at 07:54, Shane Stanley <sstanley@myriad-com.com.au> wrote:
FWIW, I believe the latter is now hello_world.count.
That’s a Swift 4.0 change, I see; different from Swift 2 & 3, which were themselves different from how to get the length of a string in Swift 1.2 and later, which wasn’t the same way to do it in Swift 1.0.

Wonder what it’ll be next year in Swift 5…


Best


Phil
@sqwarq


Re: Important question, please?

Shane Stanley
 

On 22 Sep 2017, at 10:38 am, 2551phil <2551phil@gmail.com> wrote:

Objective C: hello_world.length
AppleScript: hello_world’s length
Swift: hello_world.characters.count
FWIW, I believe the latter is now hello_world.count. And perhaps more to the point, it matches what AppleScript returns (the number of grapheme clusters), as opposed to what Objective-C returns (the number of uniChars or 16-bit values).

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Re: Important question, please?

2551phil
 


Considering all the shortcomings of Swift that you described, why did you expend the time to rewrite such a major program in Swift? Was there a benefit offsetting the shortcomings, or was it merely a learning experience?

I have had an iOS project on the backburner for a couple of years. I thought it’d be (as you say) a good learning experience to update an app I’d already written in Objective-C into Swift as prep for starting on my iOS project. In hindsight, I should have learned the language from the ground up and saved myself a lot of pain.

I do like some parts of the language’s syntax (those parts where it’s sort of python-esque), and I do like the absence of header files and the ease with which you can “talk” to other classes. I think it’s primarily all the extra type casting that I don’t like and the constant irritation of unwrapping optionals left, right, and centre. Collection classes like Arrays and Dicts are no fun to work with, and String is no equivalent to NSString, IMO. Using all three requires more typing than doing the equivalent in Objective-C and a lot more than it would in Python. It’s frustrating to see the Python-influence in some places and not others where it would have made so much sense.

Python: len(hello_world)
Objective C: hello_world.length
AppleScript: hello_world’s length
Swift: hello_world.characters.count

I don’t doubt Swift aficionados will argue it’s just different and has many benefits I’m not aware of, and I’m inclined to agree that with more familiarity I might love it a little more and hate it a little less. However, the point would still remain, bringing this back to Brian’s scenario, that you don’t want to be learning Swift by trying to rewrite something as complex as his project, especially not when the motivation is only speed of execution. Swift won’t help with that. Reducing the AppleScript calls wherever possible will though, and I believe he can do that with much less brain hurt in Objective-C - a language he’s already partially familiar with - than in Swift.



Best


Phil
@sqwarq


Re: Important question, please?

Bob Stern
 

On Sep 20, 2017, at 6:49 AM, 2551phil <2551phil@gmail.com> wrote:

I’ve spent the last two months (re-)writing one of my Objective-C apps in Swift, and it was far from easy.

@Phil: Considering all the shortcomings of Swift that you described, why did you expend the time to rewrite such a major program in Swift? Was there a benefit offsetting the shortcomings, or was it merely a learning experience?

Bob Stern


Re: Important question, please?

2551phil
 


On 20 Sep 2017, at 07:22, Brian Christmas <ozsanta@...> wrote:

I’ve read this link below, and the procedure seems straightforward.

I don’t believe there’s an AppleScript-Swift bridge, so you’ll have to translate your ASObjC and vanilla AppleScript code directly into Swift. That will not be straightforward.

I’ve spent the last two months (re-)writing one of my Objective-C apps in Swift, and it was far from easy. Quite besides the fact that similar sounding Swift classes like String and Array do not behave like NSString and NSArray (although you can bridge to the Objective-C versions if you want), Swift is by design far more intolerant than Objective-C. It was made for iOS devices, where crashing is preferable to having an app performing inefficiently on hardware where memory, disk space and particularly battery life are in short supply. So you’ll find that things that wouldn’t have crashed before will crash now. Of course, that’ll make you a better programmer; it may not do much for your head and the wall nearest to it, though.

But put all that aside. You’re tenacious. If you want to do it, I’m sure you’ll do it. A far more important consideration is why Swift? The name is a misnomer. It’s got nothing to do with speed, whatever Apple might say, and in many places it is interwined and reliant on Objective-C under the hood (one unpublicized reason why Apple confidently say ‘Objective-C isn’t going anywhere anytime soon’).

If you’re looking for speed increases, by all means get away from AppleScript, but a better choice would be to  put as much of your code into Objective-C as you can. You’ll also be far more comfortable with it, as the syntax will both look and behave in familiar ways. 

You’ll also find it easier to get help with Objective-C than Swift (Swift 1, Swift 2, Swift 3, Swift 4 - changes abound). About the only good thing I can think about Swift is that Xcode’s codesense / static analyser is far more helpful for Swift than it is for Objective-C. Oh, and it sounds cooler, of course. 


Best



Phil
@sqwarq


Important question, please?

Brian Christmas
 

G’day Scripters.

Apart from several weeks of thorough testing, it appears my 10-years-in-the-making App is ready for Public release. I might actually be able to stop annoying you all!!!

Thank you to a whole bunch of people in these lists, in particular Shane Stanley, and Yvan Keonig. Apologies to anyone else who feels they deserve a mention.

However, it’s operational scope has grown so much that I’m a bit disappointed in the amount of overhead processing time each email takes. Each image in an Email prints in about 10 seconds, but 35-50 seconds minimum is added for each Emails background processing and Data saving.

I’m wondering, now I’ve got nothing to do, would converting much of the code to Swift in the main Apps Part 1 speed it up much? (The main Apps in 3 parts, which work together; part 1 is 14,000+ lines, running 24/7). Swift simply wasn’t around when I started this whole thing.

Lots of file reading and writing. Disk intensive. Lots of RAM minimizes this. 32GB recommended. It uses over 12GB without extra caching.

I’ve read this link below, and the procedure seems straightforward. I just thought I’d ask the Guru bunch if I’d be wasting my time.


Regards

Santa


Re: Tearing my bloody hair out.

Shane Stanley
 

On 16 Sep 2017, at 9:05 pm, Brian Christmas <ozsanta@gmail.com> wrote:

I’ve Googled, found nothing.
Did you check MacScripter.net? Here's a thread that was active only this week: <http://macscripter.net/viewtopic.php?id=42971>. The topic: "Parsing JSON files". Read *it all*. The answer is in there, both as a one-liner and unfolded and commented by Nigel.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>

201 - 220 of 275