Trouble with back-button an android
-
ok folks seems like we've tried everything....
- tried the in QML onClosing() event - never gets fired.
onCLosing: { close.accepted=true; }
- tried platform specific Java implementation in activity with sendToBack
@Override public void onBackPressed() { moveTaskToBack(true); }
-
tried implementing an Event Filter... registering it with tha main window... no luck.. no event caught for back button.... then plugged the event into the Application itself... no luck... lots of events caught by the filter.. not a single one for the back_button.
-
so we got pissed off and overrided notify() within QApplicaiton itself.. just to see.. that not events for back button are being dispatched at all?
class FilteredApplication final : public QApplication { public: FilteredApplication(int &argc, char **argv) : QApplication(argc, argv) {} virtual bool notify(QObject *receiver, QEvent *event) override { if (event->type() == QEvent::KeyPress) { QKeyEvent *keyEvent = static_cast<QKeyEvent *>(event); int key = keyEvent->key(); if(key == Qt::Key_Back) { qDebug("Ate a back-button press.", keyEvent->key()); CUIActions * ui = CUIActions::getInstance(); if(ui) { if(ui->areAnyDialogsOpen()) { ui->closeAllDialogsRequest(); } else { exit(0); } } return true; } } return QApplication::notify(receiver,event); } };
-
@Vega4 said in Trouble with back-button an android:
onCLosing: {
close.accepted=true;
}That method works for me, to be fair.
ApplicationWindow { id: root onClosing:{ //Manages Android Back-button if(Qt.platform.os == "android"){ close.accepted = false } } .... ... }
The onClose has to be on the very root element of your gui tree, the one you load in main.cpp
I don't have to typo and I set the accepted to false instead of true... maybe thats the issue ?
For some reason, the key events get to the QML side before you see them in QApplication and the Eventfilter, I noticed that too 🤷♂️
-
.. an interesting thing to note... the notify() override gets executed... ONLY and when a custom QDialog gets opened()... which is good as handling of back_arrow key on android when it comes to QDialogs is uterly broken and we at least have a chance of doing some cleaning up by hand. By default QDialog.. is hidden.. not destroyed not anything which used to cause A LOT of trouble.
Still no events no notifications when the main (full-screen) window is open. Nothing.
-
@Vega4 said in Trouble with back-button an android:
onCLosing: {
close.accepted=true;
}That method works for me, to be fair.
ApplicationWindow { id: root onClosing:{ //Manages Android Back-button if(Qt.platform.os == "android"){ close.accepted = false } } .... ... }
The onClose has to be on the very root element of your gui tree, the one you load in main.cpp
I don't have to typo and I set the accepted to false instead of true... maybe thats the issue ?
For some reason, the key events get to the QML side before you see them in QApplication and the Eventfilter, I noticed that too 🤷♂️
@J-Hilk
ApplicationWindow { id: window flags: Qt.WindowTitleHint |Qt.WA_TranslucentBackground|(Qt.platform.os === "ios" ? Qt.MaximizeUsingFullscreenGeometryHint : 0) &(~Qt.WA_ContentsMarginsRespectsSafeArea) visibility: Window.FullScreen color: "#00000000" onClosing: { close.accepted = true; }
that's how it is on our end.. yeah.. we realy wish THIS would have worked indeed:D It doesn't.
-
@J-Hilk
ApplicationWindow { id: window flags: Qt.WindowTitleHint |Qt.WA_TranslucentBackground|(Qt.platform.os === "ios" ? Qt.MaximizeUsingFullscreenGeometryHint : 0) &(~Qt.WA_ContentsMarginsRespectsSafeArea) visibility: Window.FullScreen color: "#00000000" onClosing: { close.accepted = true; }
that's how it is on our end.. yeah.. we realy wish THIS would have worked indeed:D It doesn't.
-
(..) on top of everything isn't it strange that both the Application-level and window-level event-filters do not trigger... that the QApplicaiton's notify() overrides do not get triggered ? Aren't these the very things that dispatch events to anything else lower in the hierarchy?
-
-
@J-Hilk
What do you mean? we want the window to actually CLOSE .. or be sent to the back to be precise. The thing is nothing happens.
That's why we set it to true (i.e. accept)@Vega4 ok you need to actually tell me what is it you actually want to archive here.
You originally forked from here:
https://forum.qt.io/topic/28801/android-backbuttonI'm making simple examples with Qt 5.1 for android, but i have noted that with the backbutton the app exit instead of come back at previous stack page. Will be it also in future version? I think that is very important to have native behaviour (without trick).
which is about preventing the android back button from closing the whole application...
-
@Vega4 ok you need to actually tell me what is it you actually want to archive here.
You originally forked from here:
https://forum.qt.io/topic/28801/android-backbuttonI'm making simple examples with Qt 5.1 for android, but i have noted that with the backbutton the app exit instead of come back at previous stack page. Will be it also in future version? I think that is very important to have native behaviour (without trick).
which is about preventing the android back button from closing the whole application...
@J-Hilk
Seems like we want the application to actually close. Like we want the opposite. Minimize or anything or to have control over the process but like described above. for anything we do we are unable to intercept the key_back event.That's what we want - to intercept the key-back event since we need to do some cleaning up before sending the app to the back.
There must be some reason for which the app is completely unaware of the back-keyt presses which is why.. it is not minimized in the first place (which should be by default right?) maybe because it's full-screen? maybe because of some of the flags? we've got no idea but the problem is here.
-
That's our implementation of a "key-eater" event filter. No matter where we plug it (Application, main-Window) no luck...
CKeyEater::CKeyEater(QObject *parent) : QObject(parent) { } bool CKeyEater::eventFilter(QObject *obj, QEvent *event) { if (event->type() == QEvent::KeyPress) { QKeyEvent *keyEvent = static_cast<QKeyEvent *>(event); if(keyEvent->key() == Qt::Key_Back) { qDebug("Ate a back-button press.", keyEvent->key()); CUIActions * ui = CUIActions::getInstance(); if(ui) { if(ui->areAnyDialogsOpen()) { ui->closeAllDialogsRequest(); } else { exit(0); } } } return true; } else { // standard event processing return QObject::eventFilter(obj, event); } }
-
That's our implementation of a "key-eater" event filter. No matter where we plug it (Application, main-Window) no luck...
CKeyEater::CKeyEater(QObject *parent) : QObject(parent) { } bool CKeyEater::eventFilter(QObject *obj, QEvent *event) { if (event->type() == QEvent::KeyPress) { QKeyEvent *keyEvent = static_cast<QKeyEvent *>(event); if(keyEvent->key() == Qt::Key_Back) { qDebug("Ate a back-button press.", keyEvent->key()); CUIActions * ui = CUIActions::getInstance(); if(ui) { if(ui->areAnyDialogsOpen()) { ui->closeAllDialogsRequest(); } else { exit(0); } } } return true; } else { // standard event processing return QObject::eventFilter(obj, event); } }
-
@Vega4
more.. the event filter does not get fired for any of the two other android bottom-menu keys.@Vega4
(..) but notice... the event filter works... when a QDialog gets opened. Events are thus THEN being processed by QApplicaiton.. otherwise no luck. no idea how it's related. Smells like something due to the app being full-screen or the flags which we've set... but there's nothing that would indicate that it shouldn't work. -
@J-Hilk
Seems like we want the application to actually close. Like we want the opposite. Minimize or anything or to have control over the process but like described above. for anything we do we are unable to intercept the key_back event.That's what we want - to intercept the key-back event since we need to do some cleaning up before sending the app to the back.
There must be some reason for which the app is completely unaware of the back-keyt presses which is why.. it is not minimized in the first place (which should be by default right?) maybe because it's full-screen? maybe because of some of the flags? we've got no idea but the problem is here.
@Vega4 said in Trouble with back-button an android:
@J-Hilk
Seems like we want the application to actually close. Like we want the opposite. Minimize or anything or to have control over the process but like described above. for anything we do we are unable to intercept the key_back event.That's what we want - to intercept the key-back event since we need to do some cleaning up before sending the app to the back.
There must be some reason for which the app is completely unaware of the back-keyt presses which is why.. it is not minimized in the first place (which should be by default right?) maybe because it's full-screen? maybe because of some of the flags? we've got no idea but the problem is here.
now I get it :D
maybe because it's full-screen? maybe because of some of the flags
very possible, yes! You could reduce the flags/remove them and add one after the other to see if the event comes through?
Have you checked Shortcuts ? From my experience, they are triggered reliably
Shortcut { sequence: StandardKey.Back onActivated: console.log("back Key") } Shortcut { sequence: StandardKey.Quitt onActivated: console.log("Quit Key") } Shortcut { sequence: StandardKey.Close onActivated: console.log("Close Key") }
-
@Vega4 said in Trouble with back-button an android:
@J-Hilk
Seems like we want the application to actually close. Like we want the opposite. Minimize or anything or to have control over the process but like described above. for anything we do we are unable to intercept the key_back event.That's what we want - to intercept the key-back event since we need to do some cleaning up before sending the app to the back.
There must be some reason for which the app is completely unaware of the back-keyt presses which is why.. it is not minimized in the first place (which should be by default right?) maybe because it's full-screen? maybe because of some of the flags? we've got no idea but the problem is here.
now I get it :D
maybe because it's full-screen? maybe because of some of the flags
very possible, yes! You could reduce the flags/remove them and add one after the other to see if the event comes through?
Have you checked Shortcuts ? From my experience, they are triggered reliably
Shortcut { sequence: StandardKey.Back onActivated: console.log("back Key") } Shortcut { sequence: StandardKey.Quitt onActivated: console.log("Quit Key") } Shortcut { sequence: StandardKey.Close onActivated: console.log("Close Key") }
@J-Hilk said in Trouble with back-button an android:
very possible, yes! You could reduce the flags/remove them and add one after the other to see if the event comes through?
actually I'm right at it this very moment;d it's cooking...
-
@Vega4 said in Trouble with back-button an android:
@J-Hilk
Seems like we want the application to actually close. Like we want the opposite. Minimize or anything or to have control over the process but like described above. for anything we do we are unable to intercept the key_back event.That's what we want - to intercept the key-back event since we need to do some cleaning up before sending the app to the back.
There must be some reason for which the app is completely unaware of the back-keyt presses which is why.. it is not minimized in the first place (which should be by default right?) maybe because it's full-screen? maybe because of some of the flags? we've got no idea but the problem is here.
now I get it :D
maybe because it's full-screen? maybe because of some of the flags
very possible, yes! You could reduce the flags/remove them and add one after the other to see if the event comes through?
Have you checked Shortcuts ? From my experience, they are triggered reliably
Shortcut { sequence: StandardKey.Back onActivated: console.log("back Key") } Shortcut { sequence: StandardKey.Quitt onActivated: console.log("Quit Key") } Shortcut { sequence: StandardKey.Close onActivated: console.log("Close Key") }
@J-Hilk said in Trouble with back-button an android:
very possible, yes! You could reduce the flags/remove them and add one after the other to see if the event comes through?
It's confirmed.. the flags. Now how about it, we like need them :-)
-
@J-Hilk said in Trouble with back-button an android:
very possible, yes! You could reduce the flags/remove them and add one after the other to see if the event comes through?
It's confirmed.. the flags. Now how about it, we like need them :-)
-
@Vega4 I'm out of my depth here, especially as that is probably also all dependent on the window manager you/your OS uses :(
@J-Hilk
We've pretty much closed-in onto the problem. No key-events regarding the bottom navigation bar are dispatched and processed at all once any of the following flags are set (in conjunction or individually):
- Qt.WA_TranslucentBackground
- Qt.WindowTitleHint
- (~Qt.WA_ContentsMarginsRespectsSafeArea)
We need these flags, and it happens when ANY of the above are set.
Setting visibility: Window.FullScreen doesn't seem to affect anything BUT the app looks simply ugly without the above flags. (huge empty black bars on top and bottom.. also yeah due to missing support for smart-borders on android with devices with rounded screens we had to do that by hand).
Time to file a bug-report?
-
@J-Hilk
We've pretty much closed-in onto the problem. No key-events regarding the bottom navigation bar are dispatched and processed at all once any of the following flags are set (in conjunction or individually):
- Qt.WA_TranslucentBackground
- Qt.WindowTitleHint
- (~Qt.WA_ContentsMarginsRespectsSafeArea)
We need these flags, and it happens when ANY of the above are set.
Setting visibility: Window.FullScreen doesn't seem to affect anything BUT the app looks simply ugly without the above flags. (huge empty black bars on top and bottom.. also yeah due to missing support for smart-borders on android with devices with rounded screens we had to do that by hand).
Time to file a bug-report?
@Vega4 said in Trouble with back-button an android:
Time to file a bug-report?
possibly,
you should get at least a "good" answer ;)Don't forget to post a link here, so others can follow the report as well