The QLPreviewPanel window has a button that will allow the user to open the quick look document they are currently previewing by launching its original application.
Is it possible to (a) disable this button for some documents and (b) learn if the user has clicked that button.
My problem is that some of the QLPreviewItem objects I'm passing to QLPreviewPanel are actually placeholders that aren't intended to be opened, while others are temporary documents that get created spontaneously.
In the later case, I normally delete these when the preview is done, but obviously I don't want to do this if the user has opened them in an application.
I've looked at the API for QLPreviewItem, QLPreviewPanel, and QLPreviewPanelDelegate and don't see any notifications or messages that occur when the user opens an item.
If there's no API, I might just try to hack the UI by searching the QLPreviewPanel for an NSButton and hooking its action, but I don't like hacks and I'm sure this would be a fragile one.
Related
I am creating an app with Laravel that is supposed to use GoogleMaps API to show certain data in the map.
What I want to achieve is, that when you browse the root of the app, so when the user hits the main website, a new window is opened that will show a map to work with. So I want to have the ability to work with a second screen that only shows the map and all the information that should be displayed on the map.
How can I open a new window with certain content automatically when I browse to the main page.
Best
Sebastian
All modern browsers prevent this from happening, as it's commonly abused to serve popup advertisements. You'll need to make the new window happen via a user action, like a click on a button.
I am testing a chat client at a web service. I thought the best way to do this was to open the website in one internet explorer window, log in, open the chat. Then open a new IE window(in private mode so that the log in details will be forgotten) go the the page and then log in with another user and open the chat, and then start chatting with the other user in the other browser window.
The problem is when I have done everything in the first window and I open a new window, all actions are triggered in the first window even though the second window is selected. Is there any way to select which browser window to use? Or are there better ways to test this functionality without opening two internet explorer windows?
Solved: I solved this by opening a new window in private mode. When I wanted to do actions in that window I defined the browser window as:
BrowserWindow privateWindow = new BrowserWindow();
privateWindow.SearchProperties.Contains("[InPrivate]");
You need to find some characteristic of the two IE windows that is different and ensure that it is included in the search criteria used to find the two windows. However modern browsers are complex, the distinction between windows and tabs it not always clear; window titles can change depending on which tab is selected.
Specific windows are selected by setting the properties of the UITestControl objects (and of derived objects). In the UI Map editor the properties panel has fields for the "Windows Title" and the "Search Criteria". For some controls there is also a "Filter Properties" field. The same fields are available if hand coding rather than recording tests.
I've removed the menu from my cocoa app, all of the interaction should happen from within a status item, that links to a menu, that links to different NSPanels. But this seems to have removed the ability to ⌘C or ⌘V within a NSTextField. Is there a way to add this back without having to have a standard menu included with my app?
Even if your app is a faceless background app, so it never shows a menu bar, you should still have a full main menu because that's what provides all of the default actions (and enables the user to redefine the key commands if they so choose). If you remove the main menu, you have to reimplement everything in it, including anything Apple adds in the future, in code.
And I'd especially warn you against trying to handle keyboard shortcuts yourself. That's damned tricky. A lot of applications get it wrong, causing us Dvorak users (among others) to curse their developers.
I assume you can just implement the actions originally connected to the menu items in a keyDown event. Check out this page for details: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html
Just have it respond to cmd-v with paste:, and cmd-C with copy:
Edit: Though I have to agree with Peter, you really should have a main menu...
I have a desktop application written in Ruby that is using GTK2. It's just a small test application to play with GTK2, but I'm having problems achieving what I want to do. Is there any way using GTK2 to get at the titlebar (apart from setting the title), specifically to either add a button to it (beside the min/max/etc, B in the below diagram) or to add an option to the menu that pops up when you click the icon on the titlebar (A in the below diagram)?
I'm thinking there might not be because GTK is meant to work with many many different window managers, but I just wondered if there was. As a side question, what event does clicking the 'cross' button fire? At the moment if the user clicks that the window disappears but the program doesn't end - I need to capture that event and quit the program.
Thanks for any help, including hitting me over the head and telling me how silly I am.
Note that this is possible in GTK 3.10 and up, by using gtk_window_set_titlebar(). It replaces the window manager's title bar with a custom one. GtkHeaderBar is a good custom title bar class to use.
You can't, however, make it look just like the window manager would, because you won't know which window manager the user is running.
No, the title bar is owned by the window manager and you will typically not have direct access to it.
When the user tries to close the window by clicking the window manager's button, the window will receive the delete event.
After creating a translucent window (based on example code by Matt Gemmell) I want to get keyboard events in this window. It seems that there are only keyboard events when my application is the active application while I want keyboard events even when my application isn't active but the window is visible.
Basically I want behavior like that provided by the Quicksilver application (by blacktree).
Does anybody have any hints on how to do this?
There are two options:
Use GetEventMonitorTarget() with a tacked-on Carbon run loop to grab keyboard events. Sample code is available on this page at CocoaDev.
Register an event trap with CGEventTapCreate. Sample code can be found in this thread from the Apple developer mailing list.
Edit: Note that these methods only work if you check off “Enable access for assistive devices” in the Universal Access preference pane.
A simpler route that may work better for you is to make your app background-only. The discussion on CocoaDev of the LSUIElement plist key explains how to set it up. Basically, your application will not appear in the dock or the app switcher, and will not replace the current application's menu bar when activated. From a user perspective it's never the 'active' application, but any windows you open can get activated and respond to events normally. The only caveat is that you'll never get to show your menu bar, so you'll probably have to set up an NSStatusItem (one of those icon menus that show up on the right side of the menu bar) to control (i.e. quit, bring up prefs, etc.) your application.
Edit: I completely forgot about the Non-Activating Panel checkbox in Interface Builder. You need to use an NSPanel instead of an NSWindow to get this choice. This setting lets your panel accept clicks and keyboard input without activating your application. I'm betting that some mix of this setting and the Carbon Hot Keys API is what QuickSilver is using for their UI.
Update:
Apple actually seems to have changed everything again starting with 10.5 BTW (I recently upgraded and my sample code did not work as before).
Now you can indeed only capture keydown events setting up an event tap if you are either root or assistive devices are enabled, regardless on which level you plan to capture and regardless if you selected to capture (which allows you to modify and even discard events) or to be listen only. You can still get information when flags have changed (actually even change these) and other events, but keydown under no other circumstances.
However, using the carbon event handler and the method RegisterEventHotKey() allows you to register a hotkey and you'll get notified when it is pressed, you neither need to be root for that nor do you need anything like assistive devices enabled. I think Quicksilver is probably doing it that way.