Nikos Chantziaras wrote: > In other words, don't use QML for desktop applications if you can avoid > it :-/
I wouldn't... > It looks like the standard Windows menu to me in Assistant (Qt 5.8)? We > get the standard menu in our application too, which is exactly what we want. I suppose that's not an open source application? In the Assistant that menu is created explicitly and populated with the Minimise and Zoom actions. The menu itself is held by a local variable and thus isn't referenced anywhere else. AFAICT that means it will only ever contain those 2 items, which seems to be confirmed in practice. There is a design difference that's relevant here: Qt applications tend to use tabs or subwindows in a single (or handful) of main windows; native Mac applications tend to use more individual windows, and that's what the automatic Window menu we're used to works with (see also NSApplication(NSWindowsMenu) ). I don't see any evidence (in Qt 5.9 and earlier) of an explicit deactivation of the window menu (there's a call to exclude specific NSWindows from it), but I also don't see any evidence that a Window menu is created and declared (via NSApplication:setWindowsMenu). I added a debug probe at an appropriate location in the Cocoa QPA and indeed, `[NSApp windowsMenu]` returns NULL in random applications. R. _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
