When running a WebKitGTK+ application on macOS, every instance of the WebKitWebProcess makes a new dock icon. Is there a way to disable/fix this behavior?
Suggestions to use lsuielement (https://developer.apple.com/documentation/bundleresources/information_property_list/lsuielement) have not worked. It seems that WebKit itself and/or GTK is forcing each WebView widget to have a new application icon in the dock.
The Nyxt Browser folks worked this out with some help from WebKitGtk. You need to patch WebKitWebView so that it gets it NSApp and calls [NSApp setActivationPolicy: NSApplicationActivationPolicyProhibited].
Nyxt spread that over several patches and a naked file write in their MacPorts Portfile, I've consolidated it into a single patch for Gtk-OSX.
Related
Is there a way of doing this?
I want to hide the Dock when my JFrame starts and then show it when the JFrame is disposed.
According to this stackoverflow answer
There's is no API to control the Dock... at best, you can only suggest a tile to represent your app when present on the Dock.
To my recollection, you can hide the Dock from an App (and/or the MenuBar) but this is achieved from the Info.plist file (and Terminal applications do not have one) or you can do this with NSApplication, but once again Terminal apps do not have such object.
However, you may want to transform your CLI application into a faceless GUI application, so you can benefit from a GUI application without ever displaying anything.
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 have continued work on an app made by another. It looks in relevant parts identical to the standard NSDocument window-based app that you get when starting a new project (where the Window menu works like normal, ie. the NSDocument appears in the Window menu with the title Untitled).
But in this app, something seems to have happened to the Window menu or the app, that has somehow disconnected this automated behavior from the NSDocument.
Quite substantial work is needed to get this finished, submitted, and later rejected (by reviewers) app into a fresh project.
I'm looking to the experienced Mac app devs for:
What requirements/dependencies need to be fulfilled for the NSDocument to appear in the Window menu as normal?
I have checked MyDocument.h/.m (they are the standard stubs, virtually unchanged), and properties and outlets/delegates in MyDocument.xib, MainMenu.xib (none seem to be missing), and -Info.plist (which is identical to that of a New Project app). I'm experienced with XCode and Cocoa Touch, but not yet with Cocoa.
I'm willing to check things and write test code and give quick feedback, if you would help me over this last hurdle :)
I just had the same problem, and solved it by creating a reference to the window, and showing the window when the nib gets loaded:
- (void)windowControllerDidLoadNib:(NSWindowController *)aController
{
[super windowControllerDidLoadNib:aController];
[window makeKeyAndOrderFront: self];
}
The cause of the problem is still unknown to me. If after trying that it doesn't work, try debugging it. You may discover the real cause, for example the window may have been already deallocated because there isn't any strong reference (not even in NSApp) to it.
My app at launch time prompts the user with a template chooser, this works fine on Snow Leopard but on Lion the window never appears maybe due to restoration behaviour.
My app is NSDocument based and I use NSDocumentController to open the window on newDocument:(id)sender
Now on Lion no application delegate related to "untitiled" is called so I don't understard how to make it working
I think XCode 4 is NSDocument based and it shows the Startup Panel, how it does?
Another smart XCode Startup Panel's behaviour consists to show the panel only when no other windows are restored, again how this is implemented in Lion?
You're right to suspect the new restorable state behavior. The app may never be asked to create a new, empty document when relaunched/resumed. This is stated in the release notes:
As part of the restorable windows feature, the application delegate
may not be asked to create an Untitled window at launch in some
circumstances. This was found to cause crashes in certain apps, so
these apps will maintain 10.6 behavior of more often opening Untitled
windows. When these apps are recompiled on 10.7, they will acquire the
10.7 behavior. For maximum compatibility, do not depend on being asked
to create an Untitled window at launch.
They don't mention an alternative, and the document-based app documentation does not appear to have been updated yet with restorable state information.
As to your approach, you could change so that the template chooser is shown as a sheet on a new, empty doc window (like Pages or Instruments, for example). The document's contents are set when the template sheet is completed. This way, each new document shows its template sheet but this only happens if the user requests a new document, rather than relying on a fresh app launch (which you're no longer meant to do).
I'm working to an application for OSX and I would to add a new menu item on the menu shown when you click on a dock icon.
The menu isn't for my application but it must appear for all running apps.
I've found only this doc http://cocoadevcentral.com/articles/000036.php but it adds to its own app.
My app will run on OSX 10.6 or superior
You can't do that with the public API. You need to inject code into the Dock. In 10.6, the standard way to inject the code is to use the OSAX loading trick, described in this blog post for that. Then you need to do Objective-C runtime hackery to replace the method, using method_exchangeImplementations.
Anyway it's a tricky process. But if you have the will, you can. SIMBL might (or might not) help you.