NSPrincipalClass trick not working for retina application?! (EXPOSED) (GONE WRONG) Topic is solved

Do you have a typical platform dependent issue you're battling with ? Ask it here. Make sure you mention your platform, compiler, and wxWidgets version.
Post Reply
User avatar
LoganDark
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Nov 07, 2018 12:40 pm

NSPrincipalClass trick not working for retina application?! (EXPOSED) (GONE WRONG)

Post by LoganDark » Fri Jul 17, 2020 1:03 pm

So I have this C++ application, here is my CMakeLists.txt:

Code: Select all

cmake_minimum_required(VERSION 3.12)
project(wxwidgets_test)

set(CMAKE_CXX_STANDARD 11)

find_package(wxWidgets 3.1.3 COMPONENTS all REQUIRED)
include(${wxWidgets_USE_FILE})

add_executable(wxwidgets_test MACOSX_BUNDLE main.cpp)
target_link_libraries(wxwidgets_test ${wxWidgets_LIBRARIES})

add_custom_target(NSPrincipalClass ALL plutil -replace NSPrincipalClass -string NSApplication ${CMAKE_BINARY_DIR}/wxwidgets_test.app/Contents/Info.plist DEPENDS wxwidgets_test)
add_custom_target(NSHighResolutionCapable ALL plutil -replace NSHighResolutionCapable -bool true ${CMAKE_BINARY_DIR}/wxwidgets_test.app/Contents/Info.plist DEPENDS wxwidgets_test)
I manually built wxWidgets 3.1.3 from source for my specific machine and then installed it via `make install`. Ever since I did that, all dark theme support is working correctly, but I have one problem.

Image

It's not Retina.

Even though I double-checked the `Info.plist` and saw that the correct things were there, it's still not HiDPI, even though the demo applications are:

Image

What am I doing wrong? I can't find any significant differences, yet the demo applications are working great and mine is blurry...

I think in the past I was able to get HiDPI working when I built wxWidgets 3.1.1 as part of the CMake project, but that's like... way too hard to maintain. It was literally a nightmare. I had to switch the standard library and everything. Obviously now I don't do any of that stuff because it's ridiculous and I don't want to maintain a mess like that.

I'm on macOS Mojave, 10.14.6 using wxWidgets 3.1.3 (downloaded from the official website)
Last edited by LoganDark on Sat Jul 18, 2020 5:14 am, edited 1 time in total.

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 4245
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: NSPrincipalClass trick not working for retina application?! (EXPOSED) (GONE WRONG)

Post by ONEEYEMAN » Fri Jul 17, 2020 2:26 pm

Hi,
So minimal sample from the wxWidgets distribution supports black theme and has HiDPI?

In this case - what is different inside the info.plist for both?

Thank you.

User avatar
LoganDark
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Nov 07, 2018 12:40 pm

Re: NSPrincipalClass trick not working for retina application?! (EXPOSED) (GONE WRONG)

Post by LoganDark » Fri Jul 17, 2020 7:09 pm

ONEEYEMAN wrote:
Fri Jul 17, 2020 2:26 pm
Hi,
So minimal sample from the wxWidgets distribution supports black theme and has HiDPI?

In this case - what is different inside the info.plist for both?

Thank you.
Yep, minimal app works fine.

Image

I even manually reordered all the keys in my plist (and added a couple) to exactly match the minimal app's Info.plist:

Code: Select all

1 LoganDark ~/Downloads/wxWidgets-3.1.3/mybuildthing/samples
diff /Users/LoganDark/CLionProjects/wxwidgets-test/cmake-build-debug/wxwidgets_test.app/Contents/Info.plist /Users/LoganDark/Downloads/wxWidgets-3.1.3/mybuildthing/samples/minimal/minimal.app/Contents/Info.plist
2,3c2,3
< <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
< <plist version="1.0">
---
> <!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
> <plist version="0.9">
10c10
< 	<string>net.logandark.wxwidgets_test</string>
---
> 	<string>org.wxwindows.samples.minimal</string>
12a13,19
> 	<key>CFBundleLocalizations</key>
> 	<array>
> 		<string>de</string>
> 		<string>en</string>
> 		<string>fr</string>
> 		<string>it</string>
> 	</array>
14c21
< 	<string>wxwidgets_test</string>
---
> 	<string>minimal</string>
16c23
< 	<string></string>
---
> 	<string>wxmac.icns</string>
18c25
< 	<string>wxwidgets_test</string>
---
> 	<string>minimal</string>
28c35
< 	<string>wxwidgets_test</string>
---
> 	<string>minimal version 3.1.3, (c) 2002-2018 wxWidgets</string>
30c37
< 	<string>3.1.3</string>
---
> 	<string>3.1.3, (c) 2002-2018 wxWidgets</string>
32c39
< 	<string></string>
---
> 	<string>Copyright 2002-2018 wxWidgets</string>
39,40d45
< 	<key>NSHighResolutionCapable</key>
< 	<true/>
Basically, the differences are:
  • My bundle ID is different
  • I have no CFBundleLocalizations
  • My executable name is different along with copyright/version info
  • I have no icon file
  • I have the NSHighResolutionCapable key
I have a feeling it has something to do with how I'm loading the library or something, but I'm not sure. Do you have any ideas?

User avatar
LoganDark
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Nov 07, 2018 12:40 pm

Re: NSPrincipalClass trick not working for retina application?! (EXPOSED) (GONE WRONG)

Post by LoganDark » Fri Jul 17, 2020 11:02 pm

It does seem to have something to do with the executable itself, considering running one of the examples still produces a non-blurry result even though it's not even in a bundle.

Image

User avatar
LoganDark
In need of some credit
In need of some credit
Posts: 7
Joined: Wed Nov 07, 2018 12:40 pm

Re: NSPrincipalClass trick not working for retina application?! (EXPOSED) (GONE WRONG)

Post by LoganDark » Sat Jul 18, 2020 4:50 am

So I was reading up online about NSHighResolutionCapable and I came across this StackOverflow post. The post describes ways to force an app to run in low-resolution mode when it refused to do so, which was the complete inverse of my situation, but still possibly a good read.

Lo and behold, the post mentions a magic checkbox stored separately from the executable itself that says whether or not the OS has determined some app should run in low resolution. It's called the "Open in Low Resolution" checkbox, and can be accessed easily by using Get Info on any app bundle.

Now, I thought I had just found the solution already. However, this checkbox was checked and grayed out for my executable.

Do you want to know what fixed it? I misclicked and accidentally moved the bundle to the trash. Then I undid the move, and for some reason, macOS decided it was not going to force-check the checkbox anymore. So I started the application back up, and saw this:

Image

The only reason the bundle was running in low resolution was because the operating system had stored that setting somewhere! So all I had to do was make it double-check. As it turned out, my bundle was perfectly eligible, it's just the checkbox was out of date.

I hope this post can be a good resource to any future reader who comes across the same problem!

Post Reply