| 10 Mar 2021 |
 tilde | Fedora 33 | 10:20:00 |
 Nico|dev | Right, I'll try it out there | 10:20:14 |
| tilde | The "quit after doing something in the background" functionality is a bit complex to describe | 10:28:38 |
| tilde | My current idea is to set a flag at startup if it's started up in "push message" mode, and when that flag is set, it sets a 1 minute (maybe?) timeout and quits when that timeout runs out if the flag is set, and also quits the app at the end of ChatPage::sendNotifications if the flag is set
Then, if the window is brought up by the user (MainWindow::show), then the flag gets unset so the app doesn't quit automatically anymore
| 10:34:18 |
| Nico|dev | Sounds reasonable | 10:34:44 |
| tilde | that timeout to quit is because there are lots of situations where a push message arrives but there are no notifications to process | 10:34:50 |
| tilde | (for example network error, or there simply aren't any messages to notify about) | 10:36:10 |
| Nico|dev | Or if the push was delayed and processed with a previous push :3 | 10:36:44 |
| tilde | Also, push messages are also used to tell the app when there are no longer any messages to notify about, so nheko could technically delete desktop notifications that it has already sent, although that would require starting to keep track of notifications in the app database across processes, and that would be complicated | 10:37:22 |
| tilde | so I'm not going to try implementing that | 10:37:28 |
| Nico|dev | Yeah, we should do that at some point, but you don't have to implement, since it is generalized across all notifications | 10:38:15 |
| tilde | Also I noticed the app doesn't get brought up for me when clicking a notification, so I'm going to try seeing why that is | 10:38:59 |
| tilde | that is, the window isn't made visible | 10:39:25 |
| Nico|dev | Hm, weird, I never run hidden window mode, so maybe that never worked >.< | 10:39:47 |
| tilde | Also the notification has a blank button attached to it, so maybe the dbus notification api is just being called incorrectly | 10:40:15 |
| tilde | I'll look at that | 10:40:18 |
| Nico|dev | I feel like the blank button is the notifications reinterpreting the reply action wrongly maybe? | 10:41:01 |
| tilde | // The list of actions has always the action name and then a localized version of that
// action. Currently we just use an empty string for that.
// TODO(Nico): Look into what to actually put there
| 10:42:08 |
| tilde | I feel like this is why there's a blank button | 10:42:13 |
| Nico|dev | Oh, maybe | 10:42:28 |
| Nico|dev | But I'm pretty sure that an empty string should be allowed ._. | 10:42:43 |
| tilde | It sure seems to be allowed | 10:42:59 |
| tilde | but it's literally a blank string, so that's what gets put on the button | 10:43:12 |
| Nico|dev | Well, you can try putting something else there, if that changes things, we have to translate it | 10:43:31 |
| Nico|dev | I guess all my systems don't show a button for the actions or provide their own translations :D | 10:48:06 |
| tilde | It's also not an inline reply field, even though I think Gnome supports inline reply in notifications | 10:48:18 |
| Nico|dev | In reply to @vurpo:hacklab.fi
It's also not an inline reply field, even though I think Gnome supports inline reply in notifications I'm pretty sure it doesn't | 10:48:32 |
| Nico|dev | The vetoed the proposal, iirc | 10:48:43 |
| tilde | I've never had an app with notifications with inline reply, but all the references I see online suggest that it does | 10:48:49 |
| tilde | activateWindow(); did not make the window appear after it was hidden, but window()->show(); did (in the notificationClicked handler in ChatPage) | 15:13:17 |
