I've been using Wineskin for quite a while, and, as of late, I've been attempting to use Winemac.drv (or Mac Driver) from CodeWeavers more than X11. The main difference is that Winemac is fully programmed in Objective-C (including its Window system), while the X11 approach uses X11 dylibs and .nib files for windows.
Since Winemac's still in development, however, it lacks in some OS X functionality*. The feature in mind is bouncing on Dock. What's the problem with the bouncing? Well, it simply just doesn't bounce. More specifically at launch. The code somehow overrides the user's option for "Animating apps on launch", or does something that completely ignores the usual app launching animation.
I've still very little experience in Objective-C, so I might've missed some key documentation from Apple's Mac Documentation Library, but my question is:
Can apps usually override this option, or might this be the case just for Wine? If they can, how?
EDIT: I've stated incorrectly that the Mac Driver missed on functionality, when the reality is, as mentioned by Ken Thomases, that Wine processes start at background, so no icon is shown on the Dock at launch, and that means no animation.
I'm the developer of the Mac driver for Wine.
The issue is that all Wine processes start life as background processes with no presence on the Dock. Many Wine processes remain that way because they never present any windows.
When a Wine process does present a window for the first time, it transforms itself from a background process to a foreground process. At this time, it gains a presence on the Dock and in the Command-Tab application switcher and gets a main menu bar. It just so happens that the Dock does not bounce the icon of an app which transforms from a background process to a foreground process. Basically, the Dock is getting involved well after the process was launched and bouncing is for a process which is launching.
An application can make its Dock icon bounce by calling -[NSApplication requestUserAttention:]. However, this does nothing if the application is already active. Also, the bounce animation has a different quality. It's sharper and more urgent, rather than a relaxed bounce.
Basically, there's no way to achieve what you want for the general case. It may be possible to construct a script-based app bundle that configures the environment and then execs Wine. Since the app is bundled and describes itself in its Info.plist as a normal foreground app, it will get a Dock icon immediately and that icon should bounce. I'm not entirely sure how things will behave from there, in terms of the execed Wine taking over the Dock icon. Even if it works for the initial process, any Wine processes which are launched by the initial process will revert to behaving in the manner you're familiar with. (For example, many games have a patcher/launcher which launches a secondary process for the game itself. You might get the patcher/launcher icon to bounce, but that wouldn't help for the game process's icon.)
Related
I would like to build a helper app for gamers, and to build some extra functionality I would like to observe/time certain third party games behaviors, more specifically when the game actually launches the full screen process.
For example: my app is a system tray app, the game has a "launcher" app with lobby and menu screens. Once the game launches the extra process, usually OS X will switch resolutions (optionally) and my App would be notified somehow. Then I can start a timer. Once game match finishes, either the process is closed, or the game is not full screen anymore, my app gets a second notification and I can stop the timer.
Are there official Apple APIs that provide any way to observe/poll for the app going full screen and/or launch additional windows that I can reliably assume it's the actual game screen?
I doubt you're going to find a completely comprehensive solution. There are many ways for apps to achieve a full-screen experience and most don't provide a notification about that fact.
A full-screen app can modify the presentationOptions of NSApplication to hide the Dock and menu bar. Another app can use key-value observing to monitor its application object's currentSystemPresentationOptions property, which will reflect the current system status.
A full-screen app can capture the displays (although Apple discourages this technique). You can try to detect this by calling CGDisplayIsCaptured(), although it's been deprecated since 10.9 with no replacement. It may be possible that, if you register a callback with CGDisplayRegisterReconfigurationCallback(), you'll get called when something captures the display. However, capturing the display is sort of about preventing other processes from noticing such changes, so maybe not. In that case, you'd have to poll. You might also poll for the current display mode; changing the mode is the primary reason why a game would capture the display in the first place.
A full-screen game could also just create a borderless window the size of the screen and set its window level to be in front of the Dock and menu bar (and other apps' windows). There's not really a notification about this. You could detect it using the CGWindowList API, but you would have to poll. For example, you could call CGWindowListCopyWindowInfo(kCGWindowListOptionOnScreenOnly, kCGNullWindowID) and iterate through the dictionaries looking for one the size of the screen and at a window level above kCGStatusWindowLevel.
(You might be able to use the Accessibility API to get a notification when the frontmost window changes, so you'd only have to poll when that happens.)
You cannot observe a notification if there is none. So firstly you need to know if the app you want to observe is actually sending a notification that is observable. You cannot 'hook' into other apps without their planned consent.
I know this might seem odd, but I am working on a windows Metro app which would be displayed on touch screen monitors in our local university.
Now I am using the simulator for debugging, but in the simulator you have to start "Touch Mode" to even use the touch interface.
So when using the touch monitors, do we have to specifically specify touch mode ? Or it will automatically integrate the touch functionality ?
Thank you.
Touch is a first class-citizen in Windows Store applications, so no special accommodations are needed. I would recommend you test on a touch device though before deploying, it's a different way of interacting, and even though the simulator does a decent job of handling the mechanics, it will "feel" different to a user - especially if you're leveraging pinch-zoom, swipe and other gestures.
On another note... is this app intended for a kiosk-type application? If so, keep in mind with Windows 8/RT, you won't be able to easily prevent the users from swiping to the charms, navigating to other programs, etc. You may want/need to take a look at Windows 8 Embedded depending on the specific deployment requirements.
Well, it might be hard to describe, but what I want this:
When the application fires up, I want it to load a couple of components and I want to show a progress bar loading upto 100% Complete. But for Interface sake, I just want the progress bar on the desktop. I don't want the Window controls or background. My customized progress bar should appear on the desktop loading upto 100%, followed by showing of window and thereby, the entire app.
Just to mention, I want this in a Mac App being developed in Xcode.
I strongly suggest you think about the visual effect you're considering and the assumptions you're making. I would argue this to be "bad design":
Users can put anything as a Desktop Picture. If my background happens to be blue... and your custom progress bar is blue.. then I won't see the progress bar and will be left wondering why your application isn't responding. "Screw this app, it hangs when I launch it. Delete!"
Chances are that users have more than one application running. Your "floating progress bar" would be lost in a sea of other application windows. (Why is iTunes loading something? Oh wait!! It's this other windowless thing... "Not intuitive! Not cool")
This is not very Mac-like. Don't forget there are rules for each platform as to how to be a good citizen. Metro apps need to adhere to a specific Interface paradigm. Likewise, there's a thing to be said for "Mac-like" and I would argue this behaviour isn't (a floating progress bar).
I would strongly suggest you keep your progress bar within a properly named modal window. Applications go in-and-out of being front-most... so it's important to know what that progress bar relates too.
If you've considered all these, the following question should help you get started :
How to make an NSView transparent and show what's under the NSWindow?
You are probably talking of a borderless NSWindow (NSBorderlessWindowMask), with an opaque background view whose alpha is set to zero and an NSProgressIndicator subview to show the progress. You also probably want to use the -[NSWindow center] method to nicely center your window.
However, I doubt that you want that kind of UI. A progress bar is probably not visible on top of all desktops, and thus aesthetically worthless.
I think a rounded, half-transparant black window will be more suited in your case. Take a look at Matt Gemmell's source code.
I am writing a Mac application, in Cocoa, that needs the ability to 'lock down' the computer. Basically, I am writing a small agent that will sit in the background and when prompted, throw up a window that covers the entire screen, including the status bar, and shows a message (something like "give me back my computer, thief!").
The window has two requirements: it can't be moved and it can't be closed, minimized or otherwise disabled - just a big blob sitting on the screen, making sure the thief can't use the computer. I have all the agent stuff lined up, but I need help coding this window. Does anyone have any ideas?
Thanks,
Chris
P.S - In my dream world, this window would show up even at the login screen. The agent will be running by then, but I am not sure if OS X will allow it...
What you're asking for is basically to turn the user's computer into a not-very-functional kiosk. See also this technote on the same subject.
For display, alternatives to the full-screen view mode described in the Kiosk Mode document include:
Capture all the displays and draw directly to them using Quartz Display Services.
Set your window's frame to the frame of its screen and set its window level really high. You'll need to create one such window per screen.
I want to create a full Screen Cocoa application, however my app is slightly different from a conventional fullscreen app.
This app would be below everything else, so underneath the menu bar and the Dock, etc. It would have a large image covering up the Desktop and icons, with a custom NSView in the middle with a table view, etc. If this concept is hard to understand then here is an image:
http://img10.imageshack.us/img10/6308/mockupo.png
The only part that might be a bit confusing is the background image. This background image is NOT the wallpaper of the computer, but part of the app. So when the app is launched, it goes into full screen mode and puts itself underneath the dock and the menu bar, and underneath all other windows too. So it draws the background image to cover the screen (including Desktop and icons). Then has a custom NSView in the middle containing my controls.
What's the best way to go about doing this?
Thanks
Make a borderless window, the size of the menu-bar screen (screen 0—not [NSScreen mainScreen]), positioned at 0,0, with window level kCGDesktopWindowLevel.
Remember that you will need to observe for screen frame-change notifications (when the user changes the screen dimensions), and that you should correctly handle the case of no screen at all (headless Mac).
I think #Peter Hosey’s solution should work, but to make other windows go on top, you will probably need to change the window level to something else.
But, I implore you, do not do this. This will be the most bugly application the Macintosh has ever seen. There are a lot of really good user interface paradigms that you can use, and "replicating" the main desktop interface of Mac OS X is generally not one of them. That is, unless you are reimplementing Time Machine or something like that.