I am trying to use Sparkle to update an app (not the current app). I start with something simple which is creating the updater object:
var updater = SUUpdater(forBundle: appBundle)
The problem I'm having is that that line of code can open UI dialogs if something go wrong. For example:
I can solve that problem, but my concern is that this code is running on a screensaver and popping a dialog like that blocks it to the point where a hard reboot is the only way to move forward.
Is there a way to prevent Sparkle from ever opening any kind of UI?
Related
I am essentially trying to create something like a launcher for an Unreal application. The expected behavior that I was looking for is that when I launch an application the launcher would minimize or hide in the background and then whenever you close the application the launcher would then be restored.
I can successfully get the launcher to launch the other app and minimize itself but, for some reason my method for re-maximizing it doesn't seem to work. However, I was able to get it to work if I keep the app on screen(& not in focus) but, at a small size. It just seems that minimizing or hiding the app causes this method not to work
Essentially, I am using FPlatformProcess::CreateProc and grabbing the processID and then listening to see if the application is running. If it quits running then I (try to) restore the window.
My guess is there is something happening that is most likely pausing the app for some reason. I should also note that I overrode the UGameViewportClient class so that it doesn't pause the game even if it loses focus and that doesn't seem to work either.
I could possibly modify some code on the other application but, I want to keep that at a minimum. Any help would be greatly appreciated.
I was able to get a hold of one of the Engine developers with my question. Essentially, there are two options for doing something like this. First, you can use the MessageBus class and establish a connection between the two game instances. The drawback to this method however, is that it isn't really possible to detect crashes and things of that nature.
The second method (the approach I took) is to create a watchdog program in something like Visual Basic that you can use to set up a listener to a process exiting. This also allows you to set up other things like listening for application crashes or sending logs to developers.
I Create one application via Applescript, and desktop to run this application,
I will automatically open the project file for a particular logic. After moving to the first track, but is the syntax to play.
I've created so far. Problem, but next to it.
When i make another application program via the Applescript,
It is got to try to fade out the Master Volume of the currently running logic,
but I tries to fade out,I do not know way.
How logic master volume control by Applescript?
Thanks!
I may be wrong, but I don't believe Logic has support for AppleScript. Its a shame too, there are many cool things that a scripting engine would open up.
I want to respond to a certain type of new window being opened by an external application. I have some experience finding applications and windows currently open (system wide) using some of the carbon functionality, so could theoretically just check every few seconds. This would require getting a list of all open windows and checking it against some list I would have to maintain, and feels very clunky.
How can I get a simple, clean notification when a new window is launched? Should I use the accessibility API? If so, what specifically am I looking for?
First, create an AXObserver. Then, watch for launches of any applications that you think you'd be interested in. When such a launch occurs, create an application AXUIElement for that process, and add your observer to it for the kAXWindowCreatedNotification notification.
I question whether this is the best way to do whatever you're trying to do. You might step back a bit from this solution (that is, watching for new windows) and ask another question about your goal.
I'm writing a Cocoa application that installs itself as an menulet in the menu bar (i.e. like the volume or battery icons). When the program crashes, it isn't possible to use the Force-Quit dialog, because it doesn't show up in the list. Of course, I can still kill it using the command-line, but my users don't know how to do that. Is there any way to fix this, say by making the program show up in the Force-Quit dialog?
(Note: the app is Leopard only).
To be honest, the proper solution is to make sure your app never hangs or crashes for users. This should be your #1 priority, rather than figuring out how to let users deal with crashes and hangs. Obviously it isn't always possible to make sure your app never breaks in these ways, but it should definitely be the exception rather than the rule.
On another note, MenuExtras is a private API which I hope you aren't using to create your "menulet". Rather, the public class NSStatusItem (part of Cocoa) is the Apple-approved, recommended way to install icons into your menu bar.
Not really an answer, but hopefully helpful still ...
I think that most people who know how to force quit also know they can kill a process in the activity monitor. Just make sure it's not named '93AZkZ' or something.
You could provide a PreferencePane for your application that can send the proper signal to it, if you want to allow users an easy way to shut it down or restart it. This is the pattern that MySQL uses on OS X.
Using the Apple OS X Cocoa framework, how can I post a sheet (slide-down modal dialog) on the window of another process?
Edit: Clarified a bit:
My application is a Finder extension to do Subversion version control (http://scplugin.tigris.org/). Part of my application is a plug-in (a Contextual Menu Item for Finder); the bulk of my application, however, is in a separate daemon proces. For several reasons, we've chosen to put virtually all the code into the daemon; the plug-in only defines the menu itself, and Apple-Events over to the Daemon.
Sometimes, the daemon needs to prompt the user for further information. It can toss a window on-screen for this, but that's disruptive (randomly positioned), and it seems to me the work flow here is legitimately modal, for example "select a file, pick 'commit' from the menu, provide commit comments, do the operation."
Interprocess cooperation (such as passing a reference of some kind) is acceptable: both processes are mine, but I want to avoid binding the sheet's code into the primary process.
Really, it sounds like you're trying to have your inter-process communication happen at the view level, which isn't really how Cocoa generally works. Things will be much easier if you separate your layers a bit more than that.
Why don't you want to put the sheet code into the other process? It's view code, and view code is inherently process-specific. The right thing to do here is probably to add somewhat generic modal-sheet support to your plugin code, and an IPC call that your daemon can make to summon that code. Trying to ship view objects over to the remote process is going to be nightmarish if you can make it work at all.
You're fighting the frameworks with this approach.
You can't add a sheet to a window in another process, because you have at most only the most restricted access to the windows in the other process.
Please don't do this. Make the interaction nonmodal if at all possible. Especially in something like a commit, it's much nicer to be able to browse around your files while you're writing commit comments.
OS X does have window groups, but I don't think they can (easily) span applications.
Another thing to consider is that in OS X it's possible to have many Finder windows open on the same folder (unlike in OS 9). Even if you did have sufficient privileges/APIs to add a sheet to a Finder window, it's not like the modality of that window would prevent the user from being able to continue working with the files.
(My personal opinion as a long-time Mac user is that this kind of interaction would drive me right up the wall.)