Yes you were first to let people know it was out but I was first to provide proof with the screenshots as I was downloading the update at the same time uploading the screenshots
Does it matter if you download it or not?
Yes you were first to let people know it was out but I was first to provide proof with the screenshots as I was downloading the update at the same time uploading the screenshots
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
Thank youHere 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
Yes I have noticed thatInfact, 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.
No it doesn't matter but a member wanted proof in a post last nightDoes it matter if you download it or not?
Oh, well I have it now btw.Thank you
[doublepost=1534792847][/doublepost]
Yes I have noticed that
[doublepost=1534793170][/doublepost]
No it doesn't matter but a member wanted proof in a post last night
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'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...
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.
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?
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.
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
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.
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.
Fair point. I don't.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.
Thanks arqueox, I will update using the usb stick, don't want to risk doing a straight update.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.
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.@oscarodas
Have you got any problem on mojave? I use only for internet browsing and office , no play games ...any disadvantages? Imac 2011 !!
~ 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:
~ Mahalo ~
- Developer Preview on an APFS.
- Public Beta on an HFS+ partition.
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.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.
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.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.
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.
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 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
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
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.
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?