In WindowsForms there is a property called TopMost that when True makes the window always in front of anything else in the desktop (like dialog messages). I'd to know if there is a opposite property in GTK+, in that when activated would make the window stay in the back of every thing on the desktop.
There's a line between the window manager's capabilities and what a UI toolkit can do. The toolkit takes care of the window's content, the window manager determines the placement and layering of windows. Such property is likely to be non-existent. It is potentially not feasible to implement the desired property across platforms (WMs) in a meaningful way.
Furthermore Gtk.WindowType only suggests only POPUP and TOPLEVEL.
Are you looking for a Gtk.StatusIcon for selectively showing and hiding your application window?
Related
If I call my app using a separate activity (not the normal initial route but, for instance, by overriding getInitialRoute() in a secondary FlutterActivity), or maybe even if I have no UI at all but a plugin I call into provides a platform UI of any kind, upon returning to my code, when I want to dismiss the functionality, the root route of my Flutter app is visible for a short moment. As an example, let's consider a printing scenario:
my app receives a share intent
I catch the intent with my Android code, send it to the Dart side
I act upon the intent, which involves displaying the Android printing UI
the user finishes printing or dismisses the UI
control returns to my code
before my Flutter app goes away, its initial route displays temporarily
Item 6 happens even if I call SystemNavigator.pop() in my item 5. The app exits all right, the funcionality is OK, but the momentarily visible root page is a visual nuisance.
So, what I would practically need is a way to clear the back stack when I reach item 5 to make sure I don't return to the root, not even for a moment.
I found something in the meantime that, at least for now, seems to work. It involves several steps:
make sure you use an extra route for this activity -- this ensures that it won't be the root page but this one the navigation returns to temporarily,
make sure the route shows an invisible page, practically an empty Container() -- this ensures the page will not show anything,
start this activity with a transparent background mode (including a transparent launch theme and referencing it in the manifest) -- this ensures the page will not even re-color the background temporarily,
use SystemNavigator.pop([animated: false]) when your code returns from the foreign UI -- this ensures that the extra page will disappear in the end. Animated actually does nothing, as the doc describes (which is unfortunate, actually, it would be nice to be able to suppress it).
These all combined make sure that, although the extra page is technically present for a short period of time, it isn't actually visible and distracting to the user.
I'm still very much open to suggestions that provide a real solution rather than a hacky workaround, if possible. :-)
There is a small window application (50x50px) with only one image inside of it. When you click the image, a popover(GtkPopover) appears, but it cannot overpass the window borders and only part of it is shown.
How could I solve this issue without resizing the window?
Popovers in GTK under X11 cannot extend outside of the top-level window they belong to, because they do not use a separate windowing system surface; if they did, like menus, they would not be able to remain open even when clicking outside of them.
This cannot be fixed in GTK3, see:
https://bugzilla.gnome.org/show_bug.cgi?id=747509
https://gitlab.gnome.org/GNOME/gtk/issues/543
You must use Wayland, or you must ensure that your window is big enough to display your popover.
You also probably want to use gtk_popover_set_position(), gtk_popover_set_pointing_to(), or gtk_popover_set_constrain_to() to ensure that your popover always opens within the window surface, instead of outside.
I have an Eclipse RCP application that defines multiple perspectives. The default perspective allows opening views (through the showView method) that are not defined in the IPerspectiveLayout class.
When switching to another perspective, these views disappear as they belong to the default one.
Is there a way of making these views persistable through perspective changes?
AFAIK there is no way to do that in RCP other than to declare a view as "sticky". But the sticky views have their limitations, use it with great care.
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_ui_views.html
A sticky view is a view that will appear by default across all
perspectives in a window once it is opened. Its initial placement is
governemed by the location attribute, but nothing prevents it from
being moved or closed by the user. Use of this element will only cause
a placeholder for the view to be created, it will not show the view.
Please note that usage of this element should be done with great care
and should only be applied to views that truely have a need to live
across perspectives.
The view won't appear in the perspective, unless you define, that the view belongs to this perspective, while creating perspective layout or unless user opens it in the, using some action. So, you have to consider adding view placeholders to the perspective layout, see org.eclipse.ui.IFolderLayout.addPlaceholder(String viewId) method.
I’m working on an interface in VB6 to interact with a sound editor to automate certain tasks mainly using the editor’s object handles and activating them through SendMessage/PostMessage. In general it works OK, except that the editor has some dialog boxes that open in modal mode and freeze everything on the interface, including the timers.
Is there a practical way to get these dialog boxes to open modeless or to interact with them from the interface after they pop up? I tried an MDI form, but it also freezes along with everything else. The only way to override the modal mode of these boxes is to launch an independent applet beforehand to address the dialog boxes with a timer, but the process is somewhat cumbersome.
All I need to do with the dialog boxes is click the OK button or hit the return key.
The Form.Show method excepts an optional style parameter that determines if the form is modal or modeless. You can pass it the intrinsic constant vbModeless.
Form1.Show vbModeless
It's a difficult question to answer without understanding the context of the dialog boxes. However, if you don't want the dialog to stall the execution of your program, I think the only way is to run your app from a different thread (start and Active X exe or something) and then make calls across to the other thread.
I'm having a sort out of my (Delphi) applications and I been visiting the floating form size and location persistence which seems to be increasingly important with larger screen real-estate and multi-monitors. Clearly it is often desireable to have a user's form reopen in the same place as they closed it, but maybe not always, for example a modal dialog might justify opening bang in front of the users vision, i.e on the primary monitor center screen. There seems to be little out there on the 'net about this and commercial applications seem inconsistent especially regarding multiple monitors. So, a few (probably contravertial!) rules to get us started...
Non-modal forms should always reopen at the size and location of closure.
Modal forms (i.e with OK/cancel, Yes/No buttons) should reopen at the
previous size (if sizeable), but inthe center of the monitor on which the application resides.
An information message box should open in the center of the monitor on which the application resides.
A warning or error dialog should open in the center of the primary monitor.
Thanks in advance,
Brian
"Non-modal forms should always reopen at the size and location of closure."
They must have a default position and size when they first open. Do you have
any rules about this?
I would add the qualifier: If the screen resolution/monitor count is
different from the last time this form was opened, then it reverts to default
position. So no inaccessible forms restored 400 pixels to the right and below
the screen area.
"A warning or error dialog should open in the centre of the primary monitor."
I don't understand why you move the messagebox from 'monitor where the app
resides' (henceforth MWTAR) to the primary monitor. You know the punter is
looking at the MWTAR; after all he has just done something 'bad'. Why are you
changing monitors now you have something important to say?
(After all, if it is an error dialog containing useful diagnostics, he won't
read it anyway. I don't see the need to hide it from him.)
A further thought. One problem with error modal dialogs is that, wherever they pop up, the user may hit 'Enter' accidentally while typing something else and dismiss it. I know I do this quite often.
One trick I have seen to overcome this is to disable the Ok button when the dialog is first displayed. There is a 3 second timer in the dialog which counts down, displaying the time remaining in a small label attached to the button. So the punter knows he will be able to dismiss the thing soon.
Obviously this must be used very, very sparingly, and only on the rarest and most important of dialogs. But it struck me as quite clever. Perhaps all that needs doing is to make Ok the default button after three seconds.
A dialog should never open in the center of the monitor. Consider one of the 30" monitors with 2560 x 1600 pixels resolution - using an application maximized on one of these monitors makes sense only in very specific cases. If an application form resides in one of the corners of that huge screen area then the user would need to move the mouse cursor from its current location to the center of the screen, and back after dismissing the dialog. Also, with a normal viewing distance it's probably impossible to have all of that screen in view at the same time, so center of the active window will be more "in front of the users vision" than the screen center. Any dialog that doesn't remember its position should open centered on its parent window. Exceptions should be made for dialogs that are bigger than their parent window (where it makes sense to leave a bit of the parent visible, which makes it more obvious for the user what's going on), and property pages that should appear near the objects they apply to.
I would also think about saving screen positions in percent of the screen area, not in pixels. This way using a laptop with and without a large external screen will always make optimum use of the screen area - using absolute coordinates will either have portions of the screen unused, or windows moved outside of the visible area.
Depending on the platform, when the application does not have focus when throwing up an alert it should avoid taking focus. Too easy for a user typing to dismiss the alert without any chance to read it.
E.g. on Windows make use of the ability to flash a task bar button.