I made a gtk app with Ubuntu quickly tool.But I have encountered a few problems with the window close button(the one in the top left of the window).So here's the thing: I want my app to close in the system tray ,so I write the code in a method ,create a button on my window and connect the "clicked" signal to my method.Everything is working as it should.Now I want my window close button to do the same thing.When i look up on the code written by quickly i found this method:
def on_destroy(self, widget, data=None):
# Clean up code for saving application state should be added here.
Gtk.main_quit()
So instead of Gtk.main_quit() I called my handler for the button I deployed on my window.The thing now is that my app is hiding on the system tray but when i want to unhide it there is no window,although I can see the process of my app is alive.
I want to say that when I use the button i created I can see my app when I unhide it ,so it's quite obvious that when I press the system close button there's more than one signal.
So my question is what other signals are called when I close my window from system button?And where is the place quickly implements the handler for the other signals?
Thank for your time!
Your window is "destroy". Connecting to that signal allows you to run some code, but, your window is still destroyed. If you're aren't breaking out of the main loop with Gtk.main_quit() then your app is still running. To re-display the window you would need to recreate it.
Another option is to instead connect a callback function to the "delete-event" of the window. In this signal handler if you return True then the window will not be destroyed. In other words, you could hide the window and return True and then re-show the window later. If you return False from this signal handler then the window will continue to be destroyed.
Related
I need to execute some native code to interact with the macOS menu bar, ideally immediately after it got initialised. IMHO, a good time would be right after the JavaFX application window becomes visible.
From the documentation, I thought that Window.onShown should do exactly that:
Called just after the Window is shown.
But that does not seem to be the case. When putting a breakpoint into the event handler for Window.onShown, the window is not yet visible. Unfortunately at this point, the macOS menu bar is not yet fully initialised, so all my changes to the menu bar would be overwritten later by JavaFX's default menu bar.
For now, I'm just using a delay of 1sec after the WindowEvent.WINDOW_SHOWN is sent, but that does not seem to be a good solution. So does anyone have a better idea on how to reliably determine when the window is actually visible or all initialisations have finished?
If you put a breakpoint in the onShown method the problem might just be that the window was created but you are blocking the visualization because of the debugger.
If this is not the case you could try to create a new Thread that only checks for the visibility of the window using the isShowing method of the class Window.
This should be faster than just waiting for one second after the onShown method was called.
I am developing cocoa application having multiple windows. There is a red close button on left corner of window. And I want to handle click event of close button so that I can show message to ask user whether he wants to close window or not. If user accept to close window then application will be terminated otherwise same window shown to user.
Any idea how can I handle click event of close button???
Please look at NSWindowDelegate protocol reference, the method which you are looking for is-
- (BOOL)windowShouldClose:(id)sender
NSWindowController has a method
- (BOOL)shouldCloseDocument
I am working on a utility application that controls other running applications. On certain input event my application displays a window, user can pick some operation from the window, the window disappears and control returns to the previous app. My problem is that clicking in my app’s window activates my application, thus removing focus from the previous application’s window. I can re-activate the previous application when my window closes, but I’d rather keep the original application activated all the time. Is that possible?
It's quite easy to to, just make your window an instance of NSPanel (a subclass of NSWindow), and set it as non-activating in Xcode/IB (or create it programatically, with NSNonactivatingPanelMask in the style mask).
One idea would be: while your app is running, try to keept track of the active window in the system.
After you activate your app and click the command button, restore the previous active window.
This is only an idea, I don't know how to do it on mac.
In one of my first Cocoa applications I have just a single window with 2 NSTextField instances - for user text input and of output of text processing.
If my user clicks on the red x on the top left, the window closes but the application is still running and icon stays in the dock - the normal Mac behavior.
When the user double-clicks on the icon in dock or on the desktop, this does not reopen the window - apparently also normal Mac behavior, but confusing to the user.
To get the app back into a running state, the user has to force Quit from the main menu or the context menu, and restart the app by clicking on one of the icons.
I searched Apple doc and forums, and it seemed that the following should prevent the closing of the window (my first preference : hide the widow so it can be reopened later) :
add a delegate to NSApp
delegate implements -applicationShouldHandleReopen which calls [mainWindow makeKeyAndOrderFront:self]; and returns TRUE
delegate implements -windowShouldClose which returns FALSE
However, although -windowShouldClose is called, the window closes.
What am I missing here?
As an alternative (my second preference), I added to the delegate
-applicationShouldTerminateAfterLastWindowClosed which returns YES
This works, i.e. the application closes when the used clicks on the red x,
and the user can restart the app later without further ado.
Clarifications and pointers to specific doc and working code examples would be appreciated.
Rudi
"When the user double-clicks on the icon in dock or on the desktop, this does not reopen the window - apparently also normal Mac behavior, but confusing to the user."
If you want the window to re-open in that case, implement applicationShouldHandleReopen:hasVisibleWindows:. There's nothing un-Mac-like about opening a window when the user clicks the dock icon after closing all the windows; lots of apps do it and the delegate exists specifically to support that behavior.
First of all, your "alternative" behavior of terminating the app on window close is probably the preferred approach for your situation. Users may be confused when they can't close the window.
If you really want to prevent the window from being closed, why not just disable the close control on the window in IB?
I have a small OSX Cocoa app that just bring up an IKPicutreTaker and saves the picture to a file if one is set. I use applicationShouldTerminateAfterLastWindowClosed: to close the application when the pictureTaker is closed. This all works fine when I either set(this is done when you have picked the picture you want) or when you hit cancel, but when I click on the red arrow in the top left of the windows, the application does not quit when the window is closed this way. Is this intended functionality or am I doing something wrong (not setting some flag?). Also, is there some way to disable this button?
Clicking the red button does not close an application, partly because that verb does not go with that noun. The red button closes the window it's on; it does not quit your application. (An application can and will often have multiple windows on Mac OS X.)
That's where applicationShouldTerminateAfterLastWindowClosed: comes in. Whenever the user closes the last window on the screen (whether by clicking the red button, by choosing Close from the File menu, or by some other means), the NSApplication object will send an applicationShouldTerminateAfterLastWindowClosed: message to its delegate, to ask it whether the application should terminate. If the delegate responds to the message by returning YES, then the application will terminate itself.
You don't say exactly how you're “using” applicationShouldTerminateAfterLastWindowClosed:. If you're just sending it to some object, that's not going to work, because you're asking a question (“should the application terminate after the last window is closed?”) and then ignoring the answer. If you implement the method in an object, but that object isn't the application's delegate, that won't work either—the application object only sends that message to its delegate.
You need to implement the method in your delegate, and return YES when it is appropriate for the application to terminate when the user closes its last window.