Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
From what I read in an article The secrets behind MacOS Mojave dark Mode Apple uses a grey background when applying a tint instead of a white background. White goes along with about any color, grey on the other hand not so much

Infact, after Mojave login screen in light mode if you notice for one second the menu bar translucency is there, then overriden by a flat grey tone.

Anyway from your pictures I don't think in Mojave beta 9 the Finder menu bar is greyed darker, maybe it's just an impression but it looks the same as previous betas.
 
  • Like
Reactions: TimothyR734
Here is an alternative to night shift for anyone that doesn't want to mess with the night shift patch until Dosdude have the issues sorted out: https://justgetflux.com
Thank you :)
[doublepost=1534792847][/doublepost]
Infact, after Mojave login screen in light mode if you notice for one second the menu bar translucency is there, then overriden by a flat grey tone.
Yes I have noticed that
[doublepost=1534793170][/doublepost]
Does it matter if you download it or not?
No it doesn't matter but a member wanted proof in a post last night
 
  • Like
Reactions: jackluke
Finder in dark and light mode
 

Attachments

  • Screen Shot 2018-08-20 at 12.32.36 PM.png
    Screen Shot 2018-08-20 at 12.32.36 PM.png
    958.2 KB · Views: 308
  • Screen Shot 2018-08-20 at 12.31.42 PM.png
    Screen Shot 2018-08-20 at 12.31.42 PM.png
    985.4 KB · Views: 275
On my iMac 10,1 (Late 2009) running DP 7, I installed DP 8 from the Software Update Preferences Pane. Then patched again (with Mojave Patcher 1.1.2). The machine is nowin an endless loop of reboot.

I tried to patch several time, with and without Force cache rebuild option, still ending in looping in boot
 
I saw that all of the screen savers have been updated to .saver files as well. So I assume they 'officially' dropped the .qtz support. I'm gonna report in anyways. But is there a consumer way to update third party .qtz files to .saver files?
Thanks for your investigation!
[doublepost=1534767602][/doublepost]

Software Update did show me the last update (DP7) but the installation broke my OS.
(SIP disabled, Patches via boot stick applied afterwards)
I'm on a MBP 8,1 so no APFS patch needed.
I'm gonna give it another try when DP8 arrives but I don't think that issue is connected to the APFS ROM Patcher.

I believe you could write a ScreenSaverView based screen saver that includes a QCView that loads the QTZ file. I'm not proficient enough with Swift/Objective-C to do it, but that might be a good starting point for those who are.
[doublepost=1534795851][/doublepost]
I've decompiled the Mojave Finder and, as you can imagine its a huge piece of code leveraging a lot of different frameworks/dylibs. As I just mentioned to @arqueox, the Dock does it well. That should be a smaller app to inspect deeply and compare its window update strategy compared to what the Finder (and most other apps) do for our unsupported non-metal cards. The New Mojave code is littered with new branches handling Dark mode. If you guys discover another Core App (like Dock) that handles transparency in Light mode well, please advise it gives me more clues. I've already found some suspect OpenGL code that I reported to Apple, but it may not be the root cause of the UI glitches. Even if we do stumble on something that is not obvious, a fix will be difficult to manage...At this point, I'm just curious. Replacing core apps with their HS equivalents is not a good approach since many of the supporting frameworks have obviously changed.
[doublepost=1534776484][/doublepost]
There is definitely something a little screwy. All EFI related partitions should be hidden. At its most basic configuration, your disk partitions (after a fresh APFS build) should look like this:

Code:
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         500.3 GB   disk0
   1:                        EFI EFI                     314.6 MB   disk0s1
   2:                 Apple_APFS Container disk1         500.0 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.0 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            383.0 GB   disk1s1
   2:                APFS Volume Preboot                 21.8 MB    disk1s2
   3:                APFS Volume Recovery                519.0 MB   disk1s3
   4:                APFS Volume VM                      1.1 GB     disk1s4

As you can see APFS is a tad more complicated than HFS+.

Sorry, I don't remember your configuration. But I would start with a diskutil list terminal command to display your disk's partitions. IF your APFS ROM patch was successful it should boot from a clean APFS formatted disk.

As a point of reference, before I flashed my rom I wiped all traces of old APFS related volumes/partitions from my disk (using diskutil or various other tools). I was playing around with old APFS boot loader hacks back then. Then reformatted clean to HFS+ and tested. Then I flashed my rom - converted my primary partition to APFS using diskutil from a usb stick (any dosdude patcher stick I had handy) - then installed the patched OS - then post-install - voila. This may not apply directly to your situation, but may help...

Regarding apps being affected by the transparency glitch, did you see my ~30 line Swift program that produced the exact same effect as the Finder sidebar, both in light and dark mode? I posted this a while back. It's probably useful for tracing stuff in AppKit but I never made a whole ton of progress. The key seems to be in NSVisualEffectView.
[doublepost=1534796080][/doublepost]
Infact, after Mojave login screen in light mode if you notice for one second the menu bar translucency is there, then overriden by a flat grey tone.

Anyway from your pictures I don't think in Mojave beta 9 the Finder menu bar is greyed darker, maybe it's just an impression but it looks the same as previous betas.

Menu bar transparency does work briefly in the login screen? I can't say I've tested this but I would think that's a major piece of information that we can use. Because that means the correct functions/shaders/whatever are there to draw it. Something else is just causing it to be screwed up.
[doublepost=1534796507][/doublepost]I just came across something kind of interesting.

Here on InsanelyMac forums, somebody posted an instruction for installing Mojave that was based on my manual patch tutorial a while back. But they changed (improved?) some things, namely binary patching the Telemetry plugin rather than replacing it altogether. Weird... need to open up a decompiler and see what the changes they're making are.
 
I see now that this is just an issue I’ve been having, which is strange. Can anyone give me an answer about the mystery “EFI Boot” option on startup? I know that when booting into an APFS on a patched EFI chip some code is supposed to run before booting starts, but that does not happen when I try to boot onto an APFS volume. Maybe that’s why installs don’t work on APFS volumes?

Mine used to do that after I first used the version 1 of the APFS patcher because it still had the APFS Script from dosdude1's HS APFS boot script from the post install patch tool (the one that has the text scrolling a bit like single user startup.) in the ssd's EFI.

dosdude's advice was to remove it manually (later versions I have read removed it automatically).

It looks like you still have that script in your EFI. If you select EFI Boot using the option Key at startup it should run the script which will enable it to boot into your APFS drive. I used this way of booting into a macbook 5,2 that I could not get to insert the firmware with the APFS ROM Patcher.

If none of this is working for you and you want to remove the script:

Find the identifier number for your EFI partition by running: diskutil list in Terminal
my EFI identifier is disk0s1, take note of your identifier
make a mount point to access the partition - in Terminal

sudo mkdir /Volumes/EFI

then

sudo mount -t msdos /dev/disk0s1 /Volumes/EFI (Replace disk0s1 with whatever identifier you have)

Your EFI partition will now be mounted and you can use finder to see the files to delete.

APFS EFI files to remove.png

i.e. delete - apfs.efi
delete the folder - BOOT
 
I believe you could write a ScreenSaverView based screen saver that includes a QCView that loads the QTZ file. I'm not proficient enough with Swift/Objective-C to do it, but that might be a good starting point for those who are.
[doublepost=1534795851][/doublepost]

Regarding apps being affected by the transparency glitch, did you see my ~30 line Swift program that produced the exact same effect as the Finder sidebar, both in light and dark mode? I posted this a while back. It's probably useful for tracing stuff in AppKit but I never made a whole ton of progress. The key seems to be in NSVisualEffectView.
[doublepost=1534796080][/doublepost]

Menu bar transparency does work briefly in the login screen? I can't say I've tested this but I would think that's a major piece of information that we can use. Because that means the correct functions/shaders/whatever are there to draw it. Something else is just causing it to be screwed up.
[doublepost=1534796507][/doublepost]I just came across something kind of interesting.

Here on InsanelyMac forums, somebody posted an instruction for installing Mojave that was based on my manual patch tutorial a while back. But they changed (improved?) some things, namely binary patching the Telemetry plugin rather than replacing it altogether. Weird... need to open up a decompiler and see what the changes they're making are.

Menu bar transparency not always appears after login...
 
  • Like
Reactions: TimothyR734
On my iMac 10,1 (Late 2009) running DP 7, I installed DP 8 from the Software Update Preferences Pane. Then patched again (with Mojave Patcher 1.1.2). The machine is nowin an endless loop of reboot.

I tried to patch several time, with and without Force cache rebuild option, still ending in looping in boot

Try simply this, targeting your Mojave partition hold CMD+S keeping until you see a verbose mode then type:

mount -uw /
rm -R /System/Library/UserEventPlugins/com.apple.telemetry.plugin
reboot

edit:
don't worry, except the com.apple.remoted.plugin you can delete all the others UserEventPlugins, they are almost totally unnecessary, without them Mojave will still boot and work fine, I did already deeply tested, anyway after another beta upgrade they will be all there again.
 
Last edited:
Infact, after Mojave login screen in light mode if you notice for one second the menu bar translucency is there, then overriden by a flat grey tone.

Anyway from your pictures I don't think in Mojave beta 9 the Finder menu bar is greyed darker, maybe it's just an impression but it looks the same as previous betas.

Not always, but yes. I noticed too.
I was thinking if that grey bar that appear after login and all lack of transparency it isn't a bug, but an apple controlling method to people not using their stuff before 2012.......if they want to use Mojave and the new and shinny Dark mode.
 
Not always, but yes. I noticed too.
I was thinking if that grey bar that appear after login and all lack of transparency it isn't a bug, but an apple controlling method to people not using their stuff before 2012.......if they want to use Mojave and the new and shinny Dark mode.

Maybe I'm being naive, but I don't think Apple would ever resort to petty crap like this. They'll just remove the kexts for that machine and update the compatibility checks. Besides, they have the code and they're competent programmers. If they wanted to make it not work on your hardware, they would do a better job than this. They'd put much more thorough checks in the Finder, DSMOS, the kernel, whatever. Not stuff that can be overridden by a boot flag and a couple kext replacements.
 
Maybe I'm being naive, but I don't think Apple would ever resort to petty crap like this. They'll just remove the kexts for that machine and update the compatibility checks. Besides, they have the code and they're competent programmers. If they wanted to make it not work on your hardware, they would do a better job than this. They'd put much more thorough checks in the Finder, DSMOS, the kernel, whatever. Not stuff that can be overridden by a boot flag and a couple kext replacements.

Ok. Agree, but do you know which kexts to replace? Cause this looks like some kind of a filter...hey, but I agree if apple wanted to do it, they did it properly. But all questions should be made at this point, don't you think? :D
 
  • Like
Reactions: TimothyR734
Ok. Agree, but do you know which kexts to replace?
Fair point. I don't.

But just because it's hard to fix, doesn't mean it's a master plan by Apple. The Penryn kernel panic took a month to track down. All the previous issues were a mystery at some point, and at some point, someone suggested that Apple intentionally broke them on our machines.

No, they didn't. They just didn't intentionally not break them.
 
Fair point. I don't.

But just because it's hard to fix, doesn't mean it's a master plan by Apple. The Penryn kernel panic took a month to track down. All the previous issues were a mystery at some point, and at some point, someone suggested that Apple intentionally broke them on our machines.

No, they didn't. They just didn't intentionally not break them.

I agree. I am not that kind of a guy full of conspiracy theories. None of that at all, but there is something odd around all of this... It looks like something and then it is not... It looks dark mode works very well for a beta and then light mode works on some apps (messenger, Facetime, calculator), at least the top bar. But what we think is the easy part, we can't reach to it. After login menu bar shows some kind of transparency and then something block it. Like a filter... Baah. Need to sleep. Hehehe
 
If you update only, yes, should do the patches again with you USB stick. If you can't update. You will have to make a brand new installation as you did before and apply post installation patches.
[doublepost=1534766988][/doublepost]

Have you already tryed to replace Mojave Finder for the HS? Maybe you already did.. just curious.
Thanks arqueox, I will update using the usb stick, don't want to risk doing a straight update.
The only thing I haven't been able to do on my system is the Transparency, I have tried every option but without luck, but maybe is because my iMac has a AMD Radeon HD 6790M, and as I'm aware doesn't support acceleration.
[doublepost=1534799080][/doublepost]
@oscarodas
Have you got any problem on mojave? I use only for internet browsing and office , no play games ...any disadvantages? Imac 2011 !!
Hi kral84, I'm running Mojave beta 7 and apart from not being able to see any transparency, the iMac runs very smooth, the only program I haven't been able to run is vlc player. Tonight I will try the build 8.
 
~ DP8 and the equivalent PB7 ~

Aloha Folks!

Is Apple releasing both at the same time now? I have 2 scenarios that I need update testing on:
  1. Developer Preview on an APFS.
  2. Public Beta on an HFS+ partition.
~ Mahalo ~

Follow-up on the above.

Item 1 ~ updated via System Preferences | Software Update. ~ DP8

Screen Shot 2018-08-20 at 12.44.52 PM.png
Screen Shot 2018-08-20 at 1.37.25 PM.png


Item 2 ~ no updates showing yet. ~PB7

FYI.
 
I believe you could write a ScreenSaverView based screen saver that includes a QCView that loads the QTZ file. I'm not proficient enough with Swift/Objective-C to do it, but that might be a good starting point for those who are.
[doublepost=1534795851][/doublepost]

Regarding apps being affected by the transparency glitch, did you see my ~30 line Swift program that produced the exact same effect as the Finder sidebar, both in light and dark mode? I posted this a while back. It's probably useful for tracing stuff in AppKit but I never made a whole ton of progress. The key seems to be in NSVisualEffectView.
[doublepost=1534796080][/doublepost]

Menu bar transparency does work briefly in the login screen? I can't say I've tested this but I would think that's a major piece of information that we can use. Because that means the correct functions/shaders/whatever are there to draw it. Something else is just causing it to be screwed up.
[doublepost=1534796507][/doublepost]I just came across something kind of interesting.

Here on InsanelyMac forums, somebody posted an instruction for installing Mojave that was based on my manual patch tutorial a while back. But they changed (improved?) some things, namely binary patching the Telemetry plugin rather than replacing it altogether. Weird... need to open up a decompiler and see what the changes they're making are.
Yes! We happened on the same class NSVisualEffectView in AppKit... I was looking at this last night when peeling through the code. Good coincidence. It seems like many supper classes style a visual effect view for transparency. I was planning on debugging the Finder window hierarchy in Xcode or some other tools to isolate that view in offending apps. I think it's a good hunch that it's where things start to go awry.
Good tidbits on InsanelyMac (a great forum) . Good stuff!
[doublepost=1534799621][/doublepost]
Follow-up on the above.

Item 1 ~ updated via System Preferences | Software Update. ~ DP8

View attachment 776959 View attachment 776961

Item 2 ~ no updates showing yet. ~PB7

FYI.
Yup, I think the overwhelming conclusion is that APFS helps with system updates. I'm waiting to dp7->dp8 and dp6->dp8 (directly) to see how it performa locally. The second scenario (skipping a beta) is one I left a machine on an older beta for.
 
Yes! We happened on the same class NSVisualEffectView in AppKit... I was looking at this last night when peeling through the code. Good coincidence. It seems like many supper classes style a visual effect view for transparency. I was planning on debugging the Finder window hierarchy in Xcode or some other tools to isolate that view in offending apps. I think it's a good hunch that it's where things start to go awry.
Good tidbits on InsanelyMac (a great forum) . Good stuff!
[doublepost=1534799621][/doublepost]
Yup, I think the overwhelming conclusion is that APFS helps with system updates. I'm waiting to dp7->dp8 and dp6->dp8 (directly) to see how it performa locally. The second scenario (skipping a beta) is one I left a machine on an older beta for.

Cool. Let us know how it goes for both please. Mahalo.
 
  • Like
Reactions: TimothyR734
I agree. I am not that kind of a guy full of conspiracy theories. None of that at all, but there is something odd around all of this... It looks like something and then it is not... It looks dark mode works very well for a beta and then light mode works on some apps (messenger, Facetime, calculator), at least the top bar. But what we think is the easy part, we can't reach to it. After login menu bar shows some kind of transparency and then something block it. Like a filter... Baah. Need to sleep. Hehehe
Yes. Intentionally breaking stuff requires a lot of evil planning...:) . Guys and gals, our platforms and devices are just suffering from regression testing neglect. Simple as that. We're effectively testing unfortunately. We'll have to support ourselves with possibly fancier fixes from now on. This is beyond just replacing and swapping kext files. But fun...

I don't have dp8 yet, can someone check if App Store transparency is working on non-metal cards yet?
 
Mine used to do that after I first used the version 1 of the APFS patcher because it still had the APFS Script from dosdude1's HS APFS boot script from the post install patch tool (the one that has the text scrolling a bit like single user startup.) in the ssd's EFI.

dosdude's advice was to remove it manually (later versions I have read removed it automatically).

It looks like you still have that script in your EFI. If you select EFI Boot using the option Key at startup it should run the script which will enable it to boot into your APFS drive. I used this way of booting into a macbook 5,2 that I could not get to insert the firmware with the APFS ROM Patcher.

If none of this is working for you and you want to remove the script:

Find the identifier number for your EFI partition by running: diskutil list in Terminal
my EFI identifier is disk0s1, take note of your identifier
make a mount point to access the partition - in Terminal

sudo mkdir /Volumes/EFI

then

sudo mount -t msdos /dev/disk0s1 /Volumes/EFI (Replace disk0s1 with whatever identifier you have)

Your EFI partition will now be mounted and you can use finder to see the files to delete.

View attachment 776950
i.e. delete - apfs.efi
delete the folder - BOOT

Thanks for the advice. However, in the EFI disk, it only shows this:
Screen Shot 2018-08-20 at 2.34.53 PM.png
 
  • Like
Reactions: TimothyR734
Version 1.1.2 of the Mojave patcher downloads 18A371a Mojave DP8 installed over DP7 and a screenshot of the App Store
 

Attachments

  • Screen Shot 2018-08-20 at 2.37.27 PM.png
    Screen Shot 2018-08-20 at 2.37.27 PM.png
    919.9 KB · Views: 186
  • Screen Shot 2018-08-20 at 2.38.40 PM.png
    Screen Shot 2018-08-20 at 2.38.40 PM.png
    520 KB · Views: 194
Yes, SIP is still disabled - "csrutil status" - and it confirms it. Thanks.
[doublepost=1534727552][/doublepost]

Thanks for the suggestion. I will see if i could have a spare eternal drive. I'm actually running the ROM patcher from a internal SSD partition that is using @dosdude1's HS patcher.
I will also try and physically check the eeprom. The ROM patcher actually picked my exact model (MBP5,5) and didn't even get a chance to select manually.

Thanks.

Update on my APFS ROM Patch process.

@sapphade, per your suggestion, I installed High Sierra on a spare external drive using @dosdude1's HS patcher and did all necessary patch steps.
Then, I tried APFS ROM patch again and still got the same kext errors.

Oh well, I will defer the APFS ROM patcher, and stay with HFS+ boot. I'm still un-clear on what the advantages are and also did not want to risk "bricking" my MBP5,5. Thank you for the replies on this subject matter.
 
Yes. Intentionally breaking stuff requires a lot of evil planning...:) . Guys and gals, our platforms and devices are just suffering from regression testing neglect. Simple as that. We're effectively testing unfortunately. We'll have to support ourselves with possibly fancier fixes from now on. This is beyond just replacing and swapping kext files. But fun...

I don't have dp8 yet, can someone check if App Store transparency is working on non-metal cards yet?

Dark:

Screenshot 2018-08-20 at 23.56.29.png

Light:

Screenshot 2018-08-20 at 23.57.10.png
 
  • Like
Reactions: ASentientBot
@jackluke I downloaded the CoreBrightness from your link its missing the .framework at the end but it didn't add nightshift and I think dosdude1 one is still working on night shift as it was removed from the Patch Updater. I even replaced the CoreBrightness framework from my iMac 9,1 which Night does appear in the displaypref.pane with the one on my MacBook 5,2 no luck. So maybe Night shift will only work on APFS formatted drives RESOLVED disregard
 
Last edited:
  • Like
Reactions: jackluke
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.