That's a decent list, I guess we need a few more things before 0.51-4 is ready.
Phil:
Pd doesn't explicitly support Dark Mode, so I will add the Info.plist key to disable it for now. What you are seeing is a "mixed Dark Mode" where Tk is picking up background color changes but not font color changes as they are explicit set to white/black etc. We can revisit and enable Dark mode support in another release as it will require more work.
Yes, system dialog should stay on top of other Pd windows. I wasn't aware they were somehow on a system level. For normal Cocoa applications, that's a window level key you can set, so Tk must have changed something with how it's handling window types.
fede:
I think there is a fix for the Font dialog on Github already.
The iemguis "bug" is really my fault: when I overhauled the dialogs years ago, I made them "active" for macOS, ie. make changes and see the result immediately. The downside, is that I didn't record the original values when the dialog is first opened, so cancel cannot actually reset the previous values.
Miller:
The scrollbars fix is a patch to Tk, so you'd have to rebuild Wish.app to see the changes. Let us do some test builds first, then you can pull in any new patches which are ready and rebuild Wish.app, then replace it within mac/stuff. I don't think there is much point to rebuild the mac/stuff tarball too many times and fill the git history.
On Dec 16, 2020, at 12:00 PM, pd-list-request@lists.iem.at wrote:
Message: 1 Date: Tue, 15 Dec 2020 18:26:22 -0800 From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> To: ffdd cchh <camarafede@gmail.com mailto:camarafede@gmail.com> Cc: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] Pd 0.51-4-test1 with macOS scrollbar fix Message-ID: <20201216022622.GP772643@ucsd.edu mailto:20201216022622.GP772643@ucsd.edu> Content-Type: text/plain; charset=us-ascii
Thanks for all that - it looks like I didn't manage to get Dan's fix compiled in for some reason... I'll go back and check.
That stretch thing is stupid from the get-go - I should just disable it perhaps.
M
On Tue, Dec 15, 2020 at 08:25:30PM -0500, ffdd cchh wrote:
Hi all,
I found a couple issues for the mac app. I'm testing on Mojave 10.14.5
On Miller's site, this version does not display scrollbars: Software/pd-0.51-4test2.mac.tar.gz With Dan's version, scrollbars appear correctly (and better than they used to appear, so great job with that!).
I made screen recordings of the issues below, using Dan's Pd-0.51-4-test1-scrollbars.zip. Please, let me know if you need those (I can copy a drive link or similar):
- Pd crashes when you focus on the pd console, go to Edit > Font, and
stretch x and y by a value, say 120. After clicking OK, it's a crash. 2) iemguis: when you update properties on the property dialog and hit return, -- if you hit "cancel", changes are already made (I think this might be already mentioned somewhere) -- The "OK" button font turns white, and it's hard to read. [This font color is also present on the Help > Find Externals "Show All" button.]
Other than that, pd's looking good.
Best,
fede
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Ok, here is a new 0.51-4-test2 build with some more fixes (including scrollbars): Pd-0.51-4-macupdates1.zip http://docs.danomatika.com/pdbuilds/0.52/Pd-0.51-4-macupdates1.zip
I'm being lazy and rolling these changes into the scrollbars PR on GitHub: https://github.com/pure-data/pure-data/pull/1242 https://github.com/pure-data/pure-data/pull/1242
(This time responding inline.)
## Fede:
- Pd crashes when you focus on the pd console, go to Edit > Font, and
stretch x and y by a value, say 120. After clicking OK, it's a crash.
This should be fixed with a Tk back port patch by Seb Shader on GitHub.
- iemguis: when you update properties on the property dialog and hit
return, -- if you hit "cancel", changes are already made (I think this might be already mentioned somewhere)
As mentioned before, we need to save the original state when the dialog was opened, then re-apply it on cancel. I feel this is a bit too much of a change to make for a quick bugfix release, so it will need to wait until 0.52.
-- The "OK" button font turns white, and it's hard to read. [This font color is also present on the Help > Find Externals "Show All" button.]
This is due to those buttons being the default active button, ie. "pressed" when the Enter key is pressed. Normally, the background when active is blue (or whatever tine setting you are using) and the foreground is white, so contrast is fine. For some reason, I'm not sure if this is Tk or Cocoa, if the button get's too big (ie. when Pd's font size is huge), the background color is no longer used so you have white text on a gray background. Hit the Tab button to watch the active focus leave the button and its font will turn black.
I looked at this a little but and it's not something I'm prepared to get into right now. Also, do you really use Pd with the UI font that large?
## Phil:
It looks like TK 8.6.10 is paying attention to the system “Dark” appearance setting, when set. This leads to ‘interesting’ results with patches (white borders, mostly), and it’s a real problem with dialogs such as Audio Settings, which end up being white text on a light gray background.
I looked into this again and this should not be happening often. As of a version or two ago, the GUI sets a defaults key which should disable dark mode for Pd. There is a chance you would see this if starting Pd on a new system with Dark Mode enabled as the key needs to be saved by Pd first, then loaded on the next start. What is you set up to where this is happening? Is it happening constantly, ie. whenever Pd is run?
We may need to actually set this key in Pd's Info.plist directly so it's always applied, no matter the defaults setting.
I’ve also noticed that system dialogs (Audio Settings, MIDI Settings) stay on top even when other applications are in focus. I’m not sure if this is new behavior, though.
This is fixed by not setting those dialogs to "topmost" on macOS.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan,
Comments in line…
## Phil:
It looks like TK 8.6.10 is paying attention to the system “Dark” appearance setting, when set. This leads to ‘interesting’ results with patches (white borders, mostly), and it’s a real problem with dialogs such as Audio Settings, which end up being white text on a light gray background. I looked into this again and this should not be happening often. As of a version or two ago, the GUI sets a >defaults key which should disable dark mode for Pd. There is a chance you would see this if starting Pd on a >new system with Dark Mode enabled as the key needs to be saved by Pd first, then loaded on the next start. >What is you set up to where this is happening? Is it happening constantly, ie. whenever Pd is run?
You are correct that it does not happen on re-launch. It seems to have just been the first launch that caused it.
We may need to actually set this key in Pd's Info.plist directly so it's always applied, no matter the defaults >setting.
I’ve also noticed that system dialogs (Audio Settings, MIDI >Settings) stay on top even when other applications are in >focus. I’m not sure if this is new behavior, though.
This is fixed by not setting those dialogs to "topmost" on macOS.
I can confirm that this is fixed.
Thanks, Dan.
Phil
On Dec 17, 2020, at 1:39 AM, Philip Stone pkstone@ucdavis.edu wrote:
## Phil: It looks like TK 8.6.10 is paying attention to the system “Dark” appearance setting, when set. This leads to ‘interesting’ results with patches (white borders, mostly), and it’s a real problem with dialogs such as Audio Settings, which end up being white text on a light gray background. I looked into this again and this should not be happening often. As of a version or two ago, the GUI sets a >defaults key which should disable dark mode for Pd. There is a chance you would see this if starting Pd on a >new system with Dark Mode enabled as the key needs to be saved by Pd first, then loaded on the next start. >What is you set up to where this is happening? Is it happening constantly, ie. whenever Pd is run?
You are correct that it does not happen on re-launch. It seems to have just been the first launch that caused it.
Still, this shouldn't happen. I went ahead and added the key to Info.plist should it should *always* be shown in "Light Mode".
Here is an updated build with this small change: Pd-0.51-4-macupdates2.zip http://docs.danomatika.com/pdbuilds/0.52/Pd-0.51-4-macupdates2.zip
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Howdy all,
While we are at this, can you macOS users check if the mouse offset is fixed for fullscreen windows? Also the same for tabbed windows, ie. Window -> Show Tab Bar which allows you to drag and move Pd windows to a single tabbed window. We don't explicitly support this in the Pd GUI, but it *seems* to work with my build at least, including the mouse offset.
Both fullscreen and tabbed windows seem to be working well with my builds, less so with Miller's. I think this is due to the fact that I'm building the Wish.app on a much newer system, so we may be at a turning point to where we need separate builds for macOS 10.9 or 10.10+. But I may be wrong about this, having jumped back and forth so much recently...
Here is my latest build: Pd-0.51-4-macupdates2.zip http://docs.danomatika.com/pdbuilds/0.52/Pd-0.51-4-macupdates2.zip
Further, testing on macOS 11 with my builds looks good. There are a couple tweaks to add, but it basically works.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-
Dan Wilcox -
Philip Stone