It's pretty frustrating to have no idea if the copy to an iOS device has either started or is in progress. The only way I could set up my own progress hint was to copy files across a dedicated LAN mounted file store (on the Mac) and run "netstat 1" from a terminal to see if data transfer was in progress. Netstat gives you an idea of the throughput so I had to run a progress bar in my head. If any other transfer is in progress across that LAN mount, it messes up the monitoring.
Another possibility was to use "iostat 5" and monitor transfers from a mounted disk.
It's pretty crazy to have to guess like this (not been fixed for over a year, across two MacOS major versions). Where's the file going? Did I drag the file into the right folder (no indication until all is complete). How close to capacity am I while copying? Who's the manager in charge of this utility? Enquiring minds want to know!
softeky
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Adding to the original post. No positive progress, just more detail and things I've tried that don't work.
<body>
<!-- Does not work, datadetectors still on, overlaying/hiding the .png map links
<div datadetectors="off" x-apple-data-detectors="false" class="NoDDs">
<a datadetectors="off" x-apple-data-detectors="false" style="display: inline">
<img src="./GroundContact_W7_Bubbles.png" datadetectors="off" x-apple-data-detectors="false" class="inline" alt="./GroundContact_W7_Bubbles.png: not found" usemap="#html">
</a>
</div>
-->
<!-- Does not work, datadetectors still on, overlaying/hiding the .png map links
<img src="./GroundContact_W7_Bubbles.png" datadetectors="off" x-apple-data-detectors="false" class="inline" alt="./GroundContact_W7_Bubbles.png: not found" usemap="#html">
-->
<!-- Does not work, datadetectors still on, overlaying/hiding the .png map links
<h1 datadetectors="off">
<img src="./GroundContact_W7_Bubbles.png" datadetectors="off" x-apple-data-detectors="false" class="inline" alt="./GroundContact_W7_Bubbles.png: not found" usemap="#html">
</h1>
-->
<!-- Does not work, datadetectors still on, overlaying/hiding the .png map links
<a href="#" datadetectors="off" x-apple-data-detectors="false">
<img src="./GroundContact_W7_Bubbles.png" class="inline" alt="./GroundContact_W7_Bubbles.png: not found" usemap="#html">
</a>
-->
<!-- Does not work, datadetectors still on, overlaying/hiding the .png map links
<img src="./GroundContact_W7_Bubbles.png" datadetectors="off" x-apple-data-detectors="false" class="inline" alt="./GroundContact_W7_Bubbles.png: not found" usemap="#html">
-->
<!-- Does not work, datadetectors are on, overlaying/hiding the .png map links.
Definition order - map first, makes no difference. usemap before src also makes no difference.
.gif vs .png makes no difference.
-->
<img src="./GroundContact_W7_Bubbles.png" alt="./GroundContact_W7_Bubbles.png: not found" usemap="#html">
<map name="html">
<area shape="circle" coords="73,250,30" href="./PassiveStrideRecovery_W12_Notes.html" alt="PassiveStrideRecovery_W12" target="_self">
<area shape="circle" coords="174,250,30" href="./QuietFeet_W6_Notes.html" alt="QuietFeet_W6" target="_self">
<area shape="circle" coords="63,350,30" href="./ArmSwing_W4_Notes.html" alt="ArmSwing_W4" target="_self">
<area shape="circle" coords="133,350,30" href="./Breathing_W11_Notes.html" alt="Breathing_W11" target="_self">
<area shape="circle" coords="205,350,30" href="./ForwardTilt_W8_Notes.html" alt="ForwardTilt_W8" target="_self">
<area shape="circle" coords="286,350,30" href="./HeadPosture_W10_Notes.html" alt="HeadPosture_W10" target="_self">
... (more map areas here. One for each circle in the image)
...
</map>
</body>
Here's one of the 27 areas in my .png that "Data Detectors" creates, that block some of my own mapped areas. I create a linked map for each circle in the .png, each limited to the associated circle's size:
I don't know what Data Detectors is identifying or why. Whenever I refresh the URL the "x-apple-data-detectors-result" grows, though no additional blocks are identified.
I'm still trying to stop Data Detectors obscuring my created (mapped) links.
Any help appreciated.
PROBLEM SOLVED
Apple came up with a workaround. HOOOORRRAAAAY!
Thanks to Apple Developer Series (David K and Jon D). They suggested that since turning off Data Detectors (within the <img src=...>) was not working and neither was their initial attempt to use "-webkit-user-select: none", the workaround was to hide the .png away behind a transparent window. The mapped links could be attached to the transparent window and the Apple Data Detectors would not be able to see through this window to create its own overlayed links (useless as those links were).
Brilliant!
The workaround result was achieved by replacing the original "<img src=...>" with these two lines:
<img src="./transparent.png" class="inline" id="transparent" usemap="#html">
<img src="./GroundContact_W7_Bubbles.png" class="inline" id="bubbles" alt="GroundContact_W7: not found">
Plus the following CSS (in the same html file):
<style type="text/css">
#bubbles {
pointer-events: none;
}
#transparent {
position: absolute;
background-color: #ffffff;
opacity: 0.01;
width: 2502px;
height: 745px;
}
</style>
Notes:
"transparent.png" had to be a real picture file. I used a screenshot of a small square section of white screen and uploaded it to my server.
opacity of 0.0 did not work as Data Detectors could see through that. 0.01 works as needed.
width/height numbers were supplied by my "bubble creator" when the linked html was generated. I bet it's possible to fetch those numbers from the loaded .png using javascript, if needed.
For comparison, the working (new) version is at:
https://softekpartners.com/WFR/GroundContact_W7_Bubbles.html
while the original, not working, version is at:
https://softekpartners.com/WFR/orig_GroundContact_W7_Bubbles.html
Thanks again to Apple. Very nicely done.
--Instead of Defensive Programming... it's now Defenestrative Programming!
Corrections (sorry, I cannot format this Comments section...gah!):
In point 10:
#include "SDL2/SDL.h" is meant to be a code block on its own line.
In Step 13: '"Trick" detailed above' should read '"Trick" detailed below'.
The line before "Aside..." section is missing a semicolon. Code line should read:
cd /usr/local/include; ln -s /Library/Frameworks/SDL2_ttf.framework/Headers; mv Headers SDL2_ttf
The issue appears to be associated with using Frameworks in a Command Line Tool. Though designating an app instead of a Command Line Tool has a different set of issues related to sandboxing. There will be another bug report (later) where chdir(path) returns success but errno is set to 1 (not allowed) and getcwd() subsequently returns NULL.
Two more corrections (clarifications): Step (6) refers to the upper "FrameWorkTest" item in the Navigation Pane. Step (8) refers to an already installed SDL2 Framework downloaded from "https://github.com/libsdl-org/SDL/releases/tag/release-2.30.2". I usually download the .dmg found at that link and, once that .dmg is mounted in the Finder, I drag the contained SDL2.framework to /Library/Frameworks to complete its MacOS installation.
Another clarification: To start the investigation, select "Do Not Embed" for the framework inclusion in Step (8). This will introduce the "Abort" issue (on Run). "Product->Clean Build Folder..." usually gets the "File not Found" to go away at this stage, though selecting the "SDL2/SDL.h" text and selecting "Jump to Definition" with a right-click, does not show the found file location. Xcode is starting to get confused at this stage (and so am I).