Re: Zip file problem on Mac

[Neville Smythe via use-livecode]

> On 8 May 2022, at 2:00 am, Brian Milby wrote:
> 
> It is a bug somewhere. See this big report:
> https://quality.livecode.com/show_bug.cgi?id=21447 
> 
> 
> I actually think it is related. The zip should be created as a Unix variant 
> and not Fat and file attributes should be stored. One thing that could be 
> tried is to manually set the executable bit when creating the archive. I was 
> able to store a link in a zip using this method, but there is no way to read 
> the file attributes in LC.
> 

Brian, utter genius!

Not only do you pinpoint the bug — revZip is creating a ‘fat’ zip not a ‘unx’ 
zip and not adding the external attributes – but it looks like you have 
provided the workaround (for my problem of execute permissions at least)

I tried the implausible trick of using the undocumented revZipSetItemAttributes

put 0x8000 into tExtAttributes -- regular file
add 0x01ED to tExtAttributes -- rwxrwxr-x -- modify as per file (and may 
only do for Mac,Linux?)
revZipSetItemAttributes pArchive, pName, 3, tExtAttributes  — 3 for unix system

for each file as it is added to the archive. I didn’t really expect this to 
work as the file is already added to the archive in ‘fat’ format.

Not only does unzip -Z report that the archive items are now in ‘unx’ format 
with permissions rwxrwxr-x, but astonishingly the zip actually decompresses to 
a working executable – well, only so far briefly tested on a Mac but it seems 
likely this is going to work on all platforms. 

As you point out in your bug 21447 report, revZip probably won’t be able to 
decompress the archive correctly because of other deficiencies, but I only need 
the user's system to unpack it. And I will have to modify the permissions for 
each individual file in the archive. 

I never thought I would use the expression, but, like , awesome! OK sorry I 
went there, but jolly well done, that man!

Neville


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Re Pulldownmenu button bug on Windows

[Bob Sneidar via use-livecode]

Well put. I wonder what the real world effect of the order of messages is, and 
whether or not it could be compensated for by send in time?

Sent from my iPhone

> On May 7, 2022, at 13:44, Richard Gaskin via use-livecode 
>  wrote:
> 
> It's definitely an inconsistency, but the bug's status as requiring "EXPERT 
> REVIEW" prompts us to consider why these differences exist, and which, if 
> any, should be considered "wrong" or "right".  It may not be as simple as it 
> seems at first glance.
> 
> 
> Background:
> --
> MetaCard (the engine we now call LiveCode) was born on Unix, later ported to 
> Windows, Linux, and then MacOS.
> 
> On all platforms menus are implemented as selector buttons, buttons which 
> provide the appearance and behavior of OS-provided menu objects.
> 
> And until the port to MacOS, all platforms behaved consistently.
> 
> So why the Mac change?
> 
> Mac is unique among popular GUI OSes in its use of a global menu bar, 
> attached to the top of the display; other OSes place the menu bar attached to 
> the top of the window.
> 
> Internally, LC menus are implemented as temporary dynamically-instantiated 
> nameless stacks, which may seem counterintuitive until you realize that a 
> menu is in essence a highly specialized form of window, a viewport 
> independent of other windows with its own buffer, contents, and like all 
> windows needs to use a common compositor for rendering them all together. 
> (Indeed you can even use stacks as menus explicitly when you need a 
> non-standard look, like a graphical picker, but that's another topic).
> 
> So the engine's method of using a subclass of the stack object for rendering 
> menus worked well and consistently for a great many years - until the port to 
> MacOS.
> 
> The Mac global menubar required a deep rethink on how menus are handled, not 
> only in terms of detaching them from the window but also in terms of the 
> nuances of display and interaction.
> 
> So Dr Raney special-cased menus on MacOS, so the engine uses OS routines to 
> render those, fed by the menu button properties for things like the menu name 
> as parameters to those OS routines. On every other platform you're 
> interacting with a LiveCode object, but on Mac you're interacting with a 
> system object into which the engine has inserted some hooks to tie it in with 
> your scripting so you can at least know when an item has been selected.
> 
> This rewiring of properties and messages is no small feat, and has pervasive 
> effects.  So from time to time you'll find Mac-specific things needed to 
> conform to that platform like adding an "About" item to a menu that doesn't 
> exist in your stack (the Mac's "Application" menu belongs to the OS).
> 
> It's not surprising that messages related to menu objects also have some 
> inconsistencies along with everything else.
> 
> If we consider that on all other platforms the menu object we're interacting 
> with is a button, and the menus that appear are a stack, the messaging you 
> see with Windows and Linux is consistent with other button object messaging: 
> once the mouse leaves the control the mouseLeave message is sent.
> 
> On Mac we have an exception to LC's normal button messaging because we're not 
> interacting with an LC button at all, but with a system object, into which 
> the engine devs have grafted just enough messaging to trigger actions from 
> scripts.
> 
> I have no opinion on qualitative labels like "right" or "wrong" on this; that 
> seems a matter of personal familiarity and taste. It may even be somewhat 
> philosophical: is a menu a single thing that expands, or two things (menu and 
> items) where one triggers the appearance of the other?
> 
> All I can do is help describe the under-the-hood parts to help makes sense of 
> how the difference came about.
> 
> 
> 
> The Here-And-Now:
> 
> Whether or not we prefer it, the menu architecture is what it is, at least at 
> the moment. Changing the behavior on all other platforms to be like Mac, or 
> Mac to be like all other platforms, would be a scope of work that I'd guess 
> the team would not be in a position to make a priority any time soon, even if 
> they felt strongly about this one way or another.
> 
> They have a lot on their plates, and for all the questions we see regarding 
> Mac-specific menu differences (like the auto-migration of the "About", "Help" 
> and "Preferences" items to system menus separate from the menu objects where 
> we're asked to put them), I can't recall seeing a message here before about 
> mouseLeave.
> 
> I'm not saying it isn't important. It might well be. But observably this 
> affects few; AFAIK this is the first such request in the 23 years I've been 
> using this engine and participating in its communities. Just the same, let's 
> roll up our sleeves and see what can be done:
> 
> 
> 
> Looking Forward:
> ---
> Edge case or not, let's see what we can do to get a solution for 

Re: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

It's definitely an inconsistency, but the bug's status as requiring 
"EXPERT REVIEW" prompts us to consider why these differences exist, and 
which, if any, should be considered "wrong" or "right".  It may not be 
as simple as it seems at first glance.



Background:
--
MetaCard (the engine we now call LiveCode) was born on Unix, later 
ported to Windows, Linux, and then MacOS.


On all platforms menus are implemented as selector buttons, buttons 
which provide the appearance and behavior of OS-provided menu objects.


And until the port to MacOS, all platforms behaved consistently.

So why the Mac change?

Mac is unique among popular GUI OSes in its use of a global menu bar, 
attached to the top of the display; other OSes place the menu bar 
attached to the top of the window.


Internally, LC menus are implemented as temporary 
dynamically-instantiated nameless stacks, which may seem 
counterintuitive until you realize that a menu is in essence a highly 
specialized form of window, a viewport independent of other windows with 
its own buffer, contents, and like all windows needs to use a common 
compositor for rendering them all together. (Indeed you can even use 
stacks as menus explicitly when you need a non-standard look, like a 
graphical picker, but that's another topic).


So the engine's method of using a subclass of the stack object for 
rendering menus worked well and consistently for a great many years - 
until the port to MacOS.


The Mac global menubar required a deep rethink on how menus are handled, 
not only in terms of detaching them from the window but also in terms of 
the nuances of display and interaction.


So Dr Raney special-cased menus on MacOS, so the engine uses OS routines 
to render those, fed by the menu button properties for things like the 
menu name as parameters to those OS routines. On every other platform 
you're interacting with a LiveCode object, but on Mac you're interacting 
with a system object into which the engine has inserted some hooks to 
tie it in with your scripting so you can at least know when an item has 
been selected.


This rewiring of properties and messages is no small feat, and has 
pervasive effects.  So from time to time you'll find Mac-specific things 
needed to conform to that platform like adding an "About" item to a menu 
that doesn't exist in your stack (the Mac's "Application" menu belongs 
to the OS).


It's not surprising that messages related to menu objects also have some 
inconsistencies along with everything else.


If we consider that on all other platforms the menu object we're 
interacting with is a button, and the menus that appear are a stack, the 
messaging you see with Windows and Linux is consistent with other button 
object messaging: once the mouse leaves the control the mouseLeave 
message is sent.


On Mac we have an exception to LC's normal button messaging because 
we're not interacting with an LC button at all, but with a system 
object, into which the engine devs have grafted just enough messaging to 
trigger actions from scripts.


I have no opinion on qualitative labels like "right" or "wrong" on this; 
that seems a matter of personal familiarity and taste. It may even be 
somewhat philosophical: is a menu a single thing that expands, or two 
things (menu and items) where one triggers the appearance of the other?


All I can do is help describe the under-the-hood parts to help makes 
sense of how the difference came about.




The Here-And-Now:

Whether or not we prefer it, the menu architecture is what it is, at 
least at the moment. Changing the behavior on all other platforms to be 
like Mac, or Mac to be like all other platforms, would be a scope of 
work that I'd guess the team would not be in a position to make a 
priority any time soon, even if they felt strongly about this one way or 
another.


They have a lot on their plates, and for all the questions we see 
regarding Mac-specific menu differences (like the auto-migration of the 
"About", "Help" and "Preferences" items to system menus separate from 
the menu objects where we're asked to put them), I can't recall seeing a 
message here before about mouseLeave.


I'm not saying it isn't important. It might well be. But observably this 
affects few; AFAIK this is the first such request in the 23 years I've 
been using this engine and participating in its communities. Just the 
same, let's roll up our sleeves and see what can be done:




Looking Forward:
---
Edge case or not, let's see what we can do to get a solution for you 
sooner than the engine team would be able to even thinking about 
revisions as sweeping as would be needed to satisfy the engine request.


What do you need from mouseLeave during a menu drop? What are you doing 
in response to that message?


There are some clever people on this list. I'll bet we can find a 
solution for your need once we more fully understand the goals.


--
 Richard Gaskin
 Fourth 

Error: Unable to install app - Mac OS 11.5.2 , Xcode 13.2 (13C90), LC 9.6.7 en iOS 15.2

[William de Smet via use-livecode]

Hi there,

Mac OS 11.5.2 , Xcode 13.2 (13C90), LC 9.6.7 en iOS 15.2
Yesterday I tried to put an app on my iPad 2020 with iOS 15.2 on it.
Building the app is no problem and gives no error message on my Mac
Putting the app with Xcode on my iPad however gives an error: Unable to
Install App

I checked the Provisioning Profile but the iPad is listed on it.
I did know this because there are other apps on it.
I did work before.

Am I overseeing something?

,

greetings,

William
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re Pulldownmenu button bug on Windows

[Neville Smythe via use-livecode]

The pulldownmenu bug I reported has been confirmed: bug 23693 


To remind the reader: On a Mac, when a user select a menu item from a pulldown 
menu button, the menuPick message is sent first followed by a mouseLeave 
message (generated as the mouse leaves the button rect to select the menu 
item). On Windows, the mouseLeave is sent immediately, followed by menuPick.

The Mac order is correct, the mouseLeave should be delayed until the displayed 
menu is dismissed.

Linux has the same incorrect behaviour as Windows.

The same situation applies to popupmenus and option menu buttons: the Mac has 
the correct order, Windows and Linux incorrect.

However for the combobox button, all three platforms give the wrong message 
order!

And one last twist, although the Mac implementation gives the correct order for 
3 menu buttons, it sends the mouseLeave message twice, once immediately after 
the menuPick, and then again when the mouse is released.

Neville
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Zip file problem on Mac

[Neville Smythe via use-livecode]

> On 7 May 2022, at 2:00 am, use-livecode-requ...@lists.runrev.com wrote:
> 
> This sounds like this enhancement request
> https://quality.livecode.com/show_bug.cgi?id=9642 
> 

Thanks Panos for pointing out this is a duplicate to bug 9642, an enhancement 
request since 2011. I did do a quick search but clearly not very thoroughly.

The comments in that request hint that it is an OSX specific thing to include 
the execute permission flag in the zip files, and maybe the revZip tools are 
just following the zip specs as Matthias says, but I’m not sure about either. 
The original zip description said it included a copy of the file directory, but 
that was in the context of MSDOS which didn’t have an execute flag. Whether 
permissions are included in the archive does depend on the tool used to create 
the zip file and the platform. There is a long and confuseing thread on 
Stackoverflow about producing zip files which include execute permissions.

Recall my objective was to use LC to post-process the standalone build to 
produce a compressed file of each of the Mac, Windows and Linux standalones 
created by LC, and to do this whether the development platform was a Mac, 
Windows or a Linux box. At the time zip appeared to be the obvious choice.

I haven’t checked what the OSX shell command zip produces, but the Mac version 
produced by the default archiver (in effect the shell command ditto) does 
include the x flag. As Matthias notes one can check this using zipInfo or its 
equivalent unzip -Z on any platform. But it is not just Mac specific in the 
sense that Linux will happily decompress the Mac-created Linux standalone into 
an executable – at least on Ubuntu unzip -Z reports that x is set to true. On 
Windows unzip -Z looks at the .exe extension to decide if the file is 
executable rather than looking at unix permissions, so the Windows standalone 
will decompress into a launchable app (and I guess that is the reasoning behind 
TheUnarchiver and Keka setting the permission when unzipping a file with .app 
file extension on a Mac, even if the permission is not set in the archive 
itself). 

So I can achieve my objective if the development platform is a Mac using a 
shell command from LC.

On Linux I don’t know what shell command would work. Windows not being 
unix-based clearly requires something more than just zip to set the permissions 
in the archives of the two non-Windows standalones. The clever people at LC 
know how to set unix permissions for the unix standalones themselves from the 
Windows IDE but it's beyond my skillset I’m afraid. 

I had hoped this could all be done in LC without going to platform-specific 
tools. So the requested enhancement would be nice. But I won’t hold my breath.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode