NSViewPeerComponent::setIcon() is STILL TODO


#1

Hi, this is still listed as “TODO” in juce 5.x, even though it was still listed as TODO in JUCE 4. I posted a possible direction for a solution here, but it got no attention. So I’m making a separate thread.

Here’s the post with ALL of the Apple documentation explaining how to do it already linked and quoted: Window title and task bar icon
Here’s the possible direction for implementation:

void setIcon(const Image& customImage) {
    auto rgbColourSpace = CGColorSpaceCreateDeviceRGB();
    auto greyColourSpace = CGColorSpaceCreateDeviceGray();
    auto cgImageRef = juce_createCoreGraphicsImage(customImage,
                                                  customImage.getFormat() == Image::PixelFormat::SingleChannel ? greyColourSpace : rgbColourSpace,
                                                  false);
    auto nsImage = [[NSImage alloc] initWithCGImage:cgImageRef size:NSMakeSize(customImage.getWidth(), customImage.getHeight())];
    [[window standardWindowButton:NSWindowDocumentIconButton] setImage:nsImage];
}

Obviously, if that implementation worked, I would be requesting it be added, but I don’t know how to use ObjectiveC, so… Anyway, it seems like an easy thing to get working if you know ObjC! @jules @ed95 @fabian @IvanC


#2

Thanks for the documentation links. I’ve looked into this and it seems like the convention on macOS is only to show an icon in the window’s title bar if the window represents a file, as the icon behaves as if it were the file when dragged - if you look at various mac apps they don’t have icons in the window’s title bars for precisely this reason. So the idea of setting a title bar icon that doesn’t represent a file feels sort of wrong.


#3

ok, but regular documentWindows representing a file don’t show the icon…
unless I’m mistaken.

Either way, the OS provides the functionality regardless of if it’s a file or not, so it would be nice if JUCE supported it on OS X like they do on Windows:

@ed95


#4

FFS, You guys even implemented it for Linux:

so, come on. You guys implemented setIcon() for Windows and Linux who knows how many years ago. I gave you the apple docs and possible direction for doing it on OS X. Don’t put up a fight. Just spend 20 minutes, implement it, and that’ll be that! Seriously, how long has this been “TODO” in the framework? JUCE 3? JUCE 1.5? If I seem upset, it’s because I paid you guys $999 for a license with JUCE 4 and when requesting a feature, the answer that comes back is “yeah, uh, that goes against convention on macOS even though we put in the time to make it work on 2 other operating systems”. We developers are not looking for excuses about not being able to do something on a specific platform. We developers bought JUCE licenses so we can do the SAME thing on ALL supported platforms without having to be platform specific! Isn’t that the WHOLE point of JUCE? :rage: :face_with_symbols_over_mouth:


#5

Dude, chill. Just because you don’t get a reply on the forum instantly it doesn’t mean we aren’t working - we read every post on here and will respond accordingly.

I took another look at this and you were right that we should allow the icon to be set for windows representing files, so I’ve implemented that - you need to call ComponentPeer::setRepresentedFile() and then ComponentPeer::setIcon() to set a custom icon in the titlebar. This icon can be dragged and dropped to create a symlink to the file that it represents and cmd-clicked to display the default drop-down menu. I’ve also made it so that if you call ComponentPeer::setIcon() on a window not representing a file the icon will be displayed in the titlebar but won’t be draggable and won’t have the cmd-click menu. These changes will be on develop shortly.

EDIT: https://github.com/WeAreROLI/JUCE/commit/9027d1e5a192911ad0d9e8b68f0df7bd6175c62a