qt form fullscreen sometimes goes over the ubuntu top pane and sometimes not - c++

I am writing an QT application that embeds Mplayer on Ubuntu unity. I want to project videos on a projector in a dance show. I therefore have created a second form, which I move to the second screen and make it fullscreen.
Here is how I did it:
void MainWindow::on_testdialog()
{
QScreen *secondscreen = QApplication::screens()[1];
outputform->move(secondscreen->geometry().x(),secondscreen->geometry().y());
outputform->resize(secondscreen->geometry().width(),secondscreen->geometry().height());
outputform->setWindowFlags(Qt::Window | Qt::FramelessWindowHint | Qt::WindowStaysOnTopHint);
outputform->setWindowState(Qt::WindowFullScreen);
outputform->show();
}
Then I redirect the Mplayer output to this form.
This works, however sometimes the second form is true fullscreen and sits on top of the Ubuntu unity menu pane (the one on top) and sometimes the Ubuntu unity menu pane is on top.
It seems to me that it is randomly doing this.
I would like my form to be always on top, because I don't want the menu pane to show up on stage.
Is there a way to do this?
Is there a reason for this, seamingly, random behavior? maybe a bug in Ubuntu?
Kind regards,
Bart.

This sounds like a problem of the window manager which makes it out of reach for Qt to solve. Qt is only setting the corresponding WM hints on the window and hopes for the window manager to do the right thing.
For your application I suggest you install a lightweight window manager like Openbox or Fluxbox that will more likely stay out of the way. After installation you can choose it in the login screen.

Related

Cross-platform Gtk3 app, menu bar unresponsive at first

I'm writing a cross-platform Gtk3 application in C++. Lately I've been working on the integration with MacOS:
Gtkmm 3.24 obtained via Homebrew;
XCode 12.0;
MacOS Catalina 10.15.
I have derived my application class from Gtk::Application. The application object overrides the 'on_startup()' which calls the base class 'on_startup() and then uses a Gtk builder resource to construct a Gio::Menu object from an XML file, and then 'Gtk::Application::set_app_menu()' to install it:
MyApplication::on_startup()
{
Gtk::Application::on_startup();
// skipping details: ... Gtk builder reads Gio::Menu object from resource file ...
set_app_menu( pMenu );
}
When I first launch my application:
the menu bar is unresponsive. The application menu appears next to the Apple menu in the bar at the top of the screen, but neither responds to mouse clicks;
except from the frozen menu bar, the application is functioning normally and its main window is responsive.
However, then:
click on any other open application's window, that application's menu bar appears;
click on my application's window to switch back to it, its menu bar returns and now works perfectly.
This is 100% reproducible (frozen at first, toggle away to another app and back and now the menu works).
I created another project in XCode and built the Gtkmm example "app_and_win_menus" and the example application behaves the exact same way.
So I think I'm really just looking for a workaround. I've been scouring the net for any information about this problem and saw others complaining generally about frozen menu bars on MacOS but none specific to Gtk (all other applications on this Mac work normally, it's only the apps that I build with Gtk+/Gtkmm 3.24 that exhibit this issue).
I realize this sounds a bit like a bug report and this may not be the place to bring it up, but I'm unsure where to go from here. Any information much appreciated.

Which event belongs to window focus changing in qt c++?

I want to save the focused window's title, i made this part but i dont know is there any QEvent which catches all (non-application) focusChanged event? Like switching from Chrome to Qt Creator. I made an alternative solution that checks in every second if the topmost window title has changed but this is so rude. I need cross-platform solution if possible.
EDIT
I am using QT 5.9.0
Quick answer:
Qt only has focus events for it's own windows and widgets. See http://doc.qt.io/qt-5/qfocusevent.html#details for start point.
There is no event for focus in other applications.
Details:
For multi-platform solution is needed to have more general point of view. On some (X window) systems where keyboard focus is in window under mouse. But that window becomes topmost only after click. On Mobile platforms there is only one active application. And application is not allowed seeing when other applications are activated. So in my understanding there is no full multi-platform solution.
Windows only extensions are in the Qt Windows Extras. http://doc.qt.io/qt-5/qtwinextras-overview.html. But there is nothing focus change related unfortunately.

QT - Check if QT app is the app in focus

Here is what I want to do :
Check if my Qt app on windows is an app on the front or minimized.
If its minimized then draw the users attention by making it blink.
Now how can i detect if the app is minimized or on the background ?
I believe this is what you are looking for:
http://qt-project.org/doc/qt-5/qwidget.html#isActiveWindow-prop
then, you can call QWidget::activateWindow().
Looking at the notes:
if you are calling this when the application is not currently the active one then it will not make it the active window. It will change the color of the taskbar entry to indicate that the window has changed in some way.
This sounds exactly like this blink effect you are trying to achieve.
(Links are for Qt5, but this already exists in Qt4: http://qt-project.org/doc/qt-4.8/qwidget.html#activateWindow)

Qt setWindowTitle on Mac does not change icon in dock

The problem appears when I try to build a single binary on Mac. It is working fine when building my application as a bundle. Then it just takes the icon defined in the info.plist.
Another thing is that I want to avoid displaying my application icon in the dock at all? Any way to do that?
I need a solution for one of the issues, either show a custom icon in dock, or don't show any icon.
Have somebody had the same issue and maybe found a workaround or solution?

Centering a Tkinter Toplevel window in both windows and remote X11?

I know Tkinter can be an exercise in frustration at times, but I am stumped on the "correct" sequence of calls to a Tkinter/ttk Toplevel widget/window that will:
Display the window in the center of the screen WITHOUT drawing it off-center and THEN moving it.
Size the window properly.
Make the window toplevel to the parent form, but not system modal (that is, not toplevel to ALL apps/windows on the system).
Optionally create a taskbar button on Windows.
This is the current code that I have so far, with some unrelated bits removed for simplicity's sake:
def __init_ui__(self):
#// Basic setup.
self.wm_overrideredirect(False)
self.wm_resizable(False, False)
self.configure(relief=FLAT, borderwidth=4)
#// <Some extraneous widget-creation here>
#// Done!
self.update()
self.withdraw()
self.update_idletasks()
self.grid()
self.transient(self._parent)
self.grab_set()
self.form.initial_focus() #// sets initial focus before the window is displayed
center(self) #// https://stackoverflow.com/a/10018670
self.deiconify()
self._parent._parent.wait_window(self) #// Reaches back to the root Tk() obj.
# ENDIF
# END __init_ui__
This form inherits from a custom class I created that wraps a bunch of widget-creation calls, and the class inherits down from object. A second inheritance comes from ttk.Toplevel, to give it access to the various self.wm_* calls and other Tkinter goodies.
That said, I am certain some of my function calls are unneeded. But this particular call order seems to mostly work well on Windows 7. Under X11-over-ssh (using Xming for the X server in Windows), however, things get a bit weirder. In that case, if I move self.update() to be after self.withdraw(), then the window is centered correctly w/o redraw on Windows 7, but on X11, it is drawn and properly centered whilst hidden, but has ZERO geometry (only the compressed window border/decorations are shown). It's as-if grid propagation didn't fire or such.
But where self.update() is right now, it properly sizes and centers the window on both windows and X11 - but you can see the window getting created off-center THEN moved to center on both.
If I use self.wm_attributes("-toolwindow", 1) on Windows, then the windows gets centered without me seeing it, but -toolwindow only works on Windows system. It's an invalid command to both X11 and Aqua.
I'd like to avoid calls to tk::windowingsystem all the time to determine what my window manager is and having to apply different hacks for Windows and X11. And I can't test Mac/Aqua (don't own one, not going to buy), so I'll just have to hope the end look is somewhat functional on that platform.
Additionally, if I click away to another window/app under both Windows and remote X11, clicking back on the main form via the taskbar button only displays the main form -- the child Toplevel window only pops back up when you click anywhere inside the main form. Fixed: (kinda) -- I forgot that adding an argument to self._transient() kinda fixed that by specifying the parent. Earlier tonight, I didn't pass the parent argument in, thus the focusing wasn't right.
So is there some kind of tried-and-true magik recipe or invocation to the Priests of Ancient Mu to get a Tkinter/ttk Toplevel window to size, center, and properly get focus if it's not the root window? Using minimal X11, Motif-look, btw.
And no, I am not using PyGTK, PyQT, wxPython, or some other toolkit. It's standard Tkinter/ttk or bust, since that's what I've spent the last few weeks learning and writing wrapper functions for. The autocomplete combobox I worked up is a cute little contraption. Still slightly buggy, but that's a topic for another SO question...
PS, The Tkinter cookbook on Effbot is down. Looks like a server crash. Did anyone happen to mirror that site by chance?
Solved! Had to tweak the order of the calls a little bit:
#// Done!
self.withdraw()
self.grid()
self.transient(self._parent)
self.grab_set()
self.form.initial_focus()
center(self)
self.deiconify()
self._parent._parent.wait_window(self)
But the real fix was in the center() function I lifted from this answer, by changing the calls to winfo_width()/winfo_height() to winfo_reqwidth()/winfo_reqheight() and adding a call to update() as the first call in center(). Now I get my dialog windows to pop up in the center without seeing them move, focus is applied correctly, and it works on both Windows and remote X11. Maybe one day, I'll find out how well it works on Mac OS X/Aqua.