Replacement for NSTexturedBackgroundWindowMask

I use NSTexturedBackgroundWindowMask and isMovableByWindowBackground to provide a “unified” window interface so the user can drag a window by it’s background (e.g. a large toolbar-like area at the top). Thats broken in 2019R1. I filed a feedback and was informed this was by design because Apple deprecated it in macOS 10.12 (it still works in 2018 R4 in my hands).

<https://xojo.com/issue/55419>

My question is, what is the modern API way to to allow this behavior? Unfortunately, the Apple docs don’t give a clue and by google searches aren’t helping.

[quote=432262:@Jonathan Ashwell]I use NSTexturedBackgroundWindowMask and isMovableByWindowBackground to provide a “unified” window interface so the user can drag a window by it’s background (e.g. a large toolbar-like area at the top). Thats broken in 2019R1. I filed a feedback and was informed this was by design because Apple deprecated it in macOS 10.12 (it still works in 2018 R4 in my hands).

<https://xojo.com/issue/55419>

My question is, what is the modern API way to to allow this behavior? Unfortunately, the Apple docs don’t give a clue and by google searches aren’t helping.[/quote]

/* Calling -setMovable with a flag of NO will disable server-side dragging of the window via titlebar or background. -setMovableByWindowBackground:YES is ignored on a window that returns NO from -isMovable. When a window returns NO for -isMovable, it can be assigned to a different space with its relative screen position preserved. Note that a resizable window may still be resized, and the window frame may be changed programmatically. Applications may choose to enable application-controlled window dragging after disabling server-side dragging (perhaps to achieve snapping or pinnning) by handling the mouseDown/mouseDragged/mouseUp sequence in -sendEvent: in an NSWindow subclass. Note that a non movable window will also not be moved (or resized) by the system in response to a display reconfiguration. */
@property (getter=isMovable) BOOL movable NS_AVAILABLE_MAC(10_6);

@property (getter=isMovableByWindowBackground) BOOL movableByWindowBackground;

It’s not about the version of macOS you are running, but the SDK version that your app is built against. This is what was changed.

Yes, I understand that. My current distribution is built with Xojo 2018R4 and it allows background dragging. Xojo2019R1 does not. I realize this version of Xojo was built against a later SDK. I missed the macOS requirements for apps deployed with Xojo 2019R1 – it was 10.10 for 2018R4. What is it now?

The minimum requirement is still 10.10.5.

http://documentation.xojo.com/resources/system_requirements_for_current_version.html

This has more to do with the macOS SDK version the Xojo framework is linked against - as Greg already stated
Different versions of the macOS SDK’s will behave differently

I guess what OP is trying to know is what changed between Xojo 2018r4 and 2019r1 that could make this not work anymore? From what I read both use SDK 10.14, so it should be other thing or a newer SDK 10.14.x perhaps?

The replies are not convincing at all; for example:

    static const NSWindowStyleMask NSTexturedBackgroundWindowMask NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSWindowStyleMaskTexturedBackground", 10_0, 10_12) = NSWindowStyleMaskTexturedBackground;

This tells you that the mask is not deprecated, just replaced with a new name, in addition, my previous reply should have given a hint as well.

The OP experiences a difference with two versions of Xojo, while the macOS SDK does not suggest things really changed. If the OP can post a sample project showing this …

The version of the macOS SDK that apps made with each version links against

[quote=432416:@Alfred Van Hoek]The replies are not convincing at all; for example:

    static const NSWindowStyleMask NSTexturedBackgroundWindowMask NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSWindowStyleMaskTexturedBackground", 10_0, 10_12) = NSWindowStyleMaskTexturedBackground;

This tells you that the mask is not deprecated, just replaced with a new name, in addition, my previous reply should have given a hint as well.

The OP experiences a difference with two versions of Xojo, while the macOS SDK does not suggest things really changed. If the OP can post a sample project showing this …[/quote]

Doesnt that mean the function still exists from 10.0 but is deprecated in 10.12 SDK’s and has a replacement

deprecated does not mean it is gone. Am on 10.14, Xcode 10, create plugins with 10.14 for 64-bit and can use the “deprecated” mask. Since 2018r4 (was build with 10.13 and Xcode 9) and 2019r1 presumably as well, I would doubt what OP claims. The OP probably uses declares, which might introduce a different behavior

NSWindowStyleMaskTexturedBackground should be used instead.

Thank you Norman.

I just don’t understand how Jonathan say that it works with the app build with 2018r4, when Greg said that Apple removed support with 10.12 SDK and Xojo moved from 10.9 to 10.14 in 2018r4. If I understand correctly it shouldn’t work with 2018r4 or 2019r1.

@Alberto De Poo That confused me, too. I uploaded a trivial project in the Feedback case in my original post. It’s open to all if anyone else once to see the behavior in Xojo 2018R4 (works) and Xojo 2019R1 (fails).

BTW, by “broken” what I meant (and said in the Feedback, but not the OP) is that the the window background drag should only work when clicking on the window itself or a canvas – clicking and dragging in a control like a listbox should not move the window. It behaves that way in Xojo 2018R4 but not in Xojo 2019R1, where a drag in a listbox does drag the entire window. I apologize for not making that clear up front.

Do you want something like the screenshots on this page? https://ohanaware.com/retinakit/

Yes. And I have that, and have had that for many years. In Xojo 2019R1 isMovableByWindowBackground no longer respects controls like the listbox. I can work around that by setting isMovableByWindowBackground = false when the mouse enters the listbox (and back to true with it leaves). I reported this change in behavior to Xojo, but they argue that it’s normal (and we shouldn’t be using isMovableByWindowBackground any more). If there is another API call I should be using I’d love to hear it. I can’t believe I’m the only one.

What comes to mind is this fundamental change for TargetMacOS in 2019r1: <https://xojo.com/issue/54430>

Maybe… this is related? Since the Controls now are “Transparent” (and they maybe have not been transparent in your Window before), they are treated kind of: “Transparent → belongs to the Background → you’re dragging not the Control, but the underlying Window”?
While this sounds like a possible explanation, I don’t have any idea if that is correct, and if that change is related and has an impact on what you’re seeing as a difference in 2018r4<->2019r1…

Interesting thought. But it doesn’t apply to all controls. Dragging on these controls drags the window:

Listbox
Placard
Label

Dragging on these does not:

Pushbutton
Popup menu
TextArea
HTMLViewer
Disclosure triangle

I don’t know how to interpret this, though.

But definitely somehow related… I’ve just tried your example project in 2018r4.

  • Listbox, Transparent=false → drag stays in Listbox, does not drag the whole window
  • Listbox, Transparent=true → drags the whole window
    Since in 2019r1 the Listbox will always be ‘Transparent=true’ (no matter what you’ve set in the IDE), it gets that behavior change (compared to 2018r4 with Transparent=false).

Thanks, I’ll ask Xojo to reopen the Feedback and see what they say.