Several windows in OS X have drag-and-droppable window icons (e.g. Terminal, Keynote, Finder). Can Qt4 window icons be set up for drag and drop? I can't figure out whether clicking on the window icon triggers any event.
As this feature is specific to only one platform it may not directly available in Qt. Probably you will have to use Cocoa API to handle such events. You can get native window handle:
WId QWidget::winId () const Returns the window system identifier of
the widget.
Portable in principle, but if you use it you are probably about to do
something non-portable. Be careful.
If a widget is non-native (alien) and winId() is invoked on it, that
widget will be provided a native handle.
On Mac OS X, the type returned depends on which framework Qt was
linked against. If Qt is using Carbon, the {WId} is actually an
HIViewRef. If Qt is using Cocoa, {WId} is a pointer to an NSView.
With such handle you probably will be able to handle "window icon drag" with native (not portable!) Mac OS X code
Related
I have a Windows tool, it allows we move cursor, click on any third-party window on the desktop to get their related window handle, then we can use those handles to change the attribute of the third-party window such as alpha, WS_VISIBLE, cloak etc of the selected window, is it possible to implement those features in macOS?
The Windows APIs used: WindowFromPoint, SetCapture, GetCapture, SetWindowLong, DwmSetWindowAttribute, ModifyWindow, FindWindow etc,
Is there any mapped macOS APIs for those purposes?
I planned to use Swift and Objective-C, but not sure if it is possible or not
No code yet, just for investigation
not yet
Not possible to port all those features, the closest example will be SonOfGrab
On Mac it is usual that there is a "hidden" main window.
The usual example is "Text Edit". When you open a file you with you don't see a "main frame". Instead every single file will be opened in its own "Text Edit" instance. This is OSX way of emulating the so-called MDI interface.
However, there is an exception. If you open Xcode and open the project there, you can click on the file and it will be open inside the main Xcode window. And if you double click the file it will be opened in its own independent editor window, keeping the main Xcode window visible.
My question would be: do I need to do anything special in order to make my program behave like an Xcode? Should I use different class for the main frame or maybe react differently on the opening document event?
Any hints/pointers where to look or even to the official Apple documentation would be helpful.
The TextEdit behavior you're describing is much more like “SDI” than “MDI”, and the terms “SDI” and “MDI” weren't even needed until Microsoft invented MDI long after Xerox invented the SDI-type interface of which macOS is a derivative.
Anyway, I think you are misunderstanding Xcode's behavior. You seem to think “its own independent editor window” is a different kind of window than “the main Xcode window”. But in fact the new window is of the same kind as the old window, with some optional parts hidden. You can show those hidden parts and make the new window look exactly like the old window. Demo:
The ability to open multiple windows showing the same document (or, in Xcode's case, project) is a matter of software architecture. If you carefully design your app so that multiple windows can share a single model object graph, and can be notified and redraw themselves when the object graph changes, then you have an app that supports multiple windows showing the same document. If you want multiple kinds of windows showing the same document, nothing about Cocoa stands in your way. As a matter of fact, Xcode does have at least one other kind of window in which it shows some properties of a project:
That project settings sheet is really another window; macOS keeps it attached to the main window, but it is in fact an instance of NSWindow (or a subclass of NSWindow), no doubt with its own custom window controller that references the same project objects as the main window.
If you use the Cocoa NSDocument architecture, then a small amount of multi-window support is built-in: an NSDocument knows about its associated windows (via their window controllers). If you want to use the NSDocument architecture, you should read Document-Based App Programming Guide for Mac.
It is unclear what you are after. The traditional Mac UI has been one window per document - i.e. SDI with a single instance of the app running multiple windows - but there has always been the ability for any app to organise the content of that window as it sees fit, including showing multiple "documents" within one window - i.e MDI type UI.
Apps approach such "MDI" in different ways, e.g. some use panes (views) and others tabs. From macOS Sierra the standard NSWindow supports tabs, this system is (semi)automatic for standard document apps. Read Apple's NSWindow Automatic Window Tabbing section in the Sierra release notes for more details.
If you wish to use multiple panes - e.g. like Xcode - you just use views (NSView) and arrange them how you wish.
HTH
Working on porting a Windows game to Mac using SDL2, and I noticed on the Mac that the menu bar for the game includes a View menu with an item Toggle Full Screen. I'm assuming SDL put it there automatically, as I didn't request it anywhere in my code. However, since the game can run in a window or full screen (and the window is resizable), I figure I should make this menu item actually work somehow.
I know practically nothing about Mac OSX coding (I just followed a tutorial to get my SDL app to build on the Mac side in XCode), and I can't find anything in the SDL documentation about how to respond to, activate, or remove this menu item (or other ones that are greyed out, like the Minimize option in the Window menu). Best I could find online is a reference to it being added in a commit to the SDL code base, but nothing in the commit message about how one is supposed to hook it up to their application code.
So, how do I activate and respond to this menu item (and any other menu items that only show up in OSX builds for that matter, like Minimize and About)? And is it something I can hook up in a cross-platform way via SDL itself, or did SDL add something that I have to deal with using platform-specific OSX code?
I'm working on a cross-platform command-line application (in C++ on
Win/Linux and ObjC++ on OSX) which sometimes creates an OpenGL
context. The OpenGL context and window creation code is obviously
different for the different platforms, but on OSX it's done through
NSOpenGLView and NSWindow. There's no nib, and it's not built with
Xcode (it uses a cross-platform build script).
On OSX, the window is created and works fine, but the OpenGL window
doesn't show up in the Application Switcher (Cmd-Tab). This means
that it's tricky to find the window if you 'lose it' behind other
windows, and can often only be found by going to Mission
Control/Expose.
My question is: is there a programmatic way (i.e. a message to send to
the NSWindow object or NSApplication) to ensure that a (unix-style)
command line application will show up in the Cmd-Tab list once the
window is created?
You need to transform the process from an accessory to a regular app. Call [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular].
Once you do that, though, the app will also have a menu bar when it's active. This is good because it's what users expect. However, you probably need to add appropriate items to the menus in that menu bar to get a decent user experience.
Your app will appear in the Dock as well as the Command-Tab application switcher. By default, an unbundled executable will get an icon that looks like a CRT display showing the word "exec". You can use [NSApp setApplicationIconImage:someImage] to set a better icon, although the Dock will revert to showing the generic executable icon briefly as the process exits.
I currently have a program written in Cocoa and I would like it to have an onscreen keyboard as I am thinking of using a touch-screen monitor and would like to not have a keyboard for this particular piece of software.
I know there is an onscreen keyboard in Cocoa-touch, but as far as I am aware, that can only be used on the iPhone, iTouch and iPad.
Is there anyway I can use it in a regular Cocoa application?
Thanks
UIKit isn't part of Mac OS X, unfortunately, so you can't use anything from it. There is an onscreen keyboard that you can enable in the system's Language & Text preference pane, but I don't know how you'd do it programmatically. If this is a major requirement for your system, though, it would probably be better to roll your own. OS X is not really designed for touchscreens and has just recently gotten the most rudimentary support for touch-y interaction (thanks to the Magic Mouse and the MacBooks' trackpad).
Unfortunately, the on-screen keyboard is part of UIKit, which is only available on iOS. The only (hacky) option that I'm aware of would be to run your app in the iPad simulator. Not ideal, for sure and I'm not sure how the simulator handles a multi-touch capable display.