| dsc_ | good day | 15:11 |
|---|---|---|
| dsc_ | < uvos__> lots of notifcations behavior is simply hardcoded per origin | 15:11 |
| dsc_ | I do not understand this 100%, so Hildon looks at the 'incoming dbus origin' ? | 15:13 |
| dsc_ | e.g: I would change https://github.com/maemo-leste/conversations/blob/libnotify-qt/src/lib/libnotify-qt/Notification.cpp#L35 | 15:13 |
| dsc_ | to reflect: https://github.com/maemo-leste/hildon-home/blob/0d32a53e8a18b69e9472d56ea26a19cba210a649/src/notification-groups.conf#L15 | 15:13 |
| dsc_ | ? | 15:13 |
| dsc_ | even then, how would hildon know to map it to the conversations window? | 15:13 |
| dsc_ | via `Destination=Rtcom-messaging-ui` ? | 15:14 |
| dsc_ | so it would become `Destination=conversations` ? | 15:14 |
| dsc_ | and then Hildon can find a window named 'conversations' | 15:17 |
| Wizzup | dsc_: I think that might be the binary name, not sure if it matches some other name | 15:21 |
| Wizzup | I was thinking the same but wanted to research before asking you to try it :) | 15:22 |
| dsc_ | ill try it :) | 15:22 |
| uvos | no | 15:23 |
| uvos | so theres some extended vendor proparty that specifices the "group" | 15:23 |
| uvos | the dbus call in the config file is the call used to call the application on user interaction | 15:23 |
| uvos | i think the Destination is used by the implementor of RtcomNotificationUi but not sure | 15:24 |
| uvos | mainly i would say: all of this is horrible | 15:24 |
| dsc_ | even if it is horrible, I just dont understand how to implement a notification that maps to a specific window | 15:25 |
| uvos | it makes mutch more sense to properly implement this using libnotify extensions | 15:25 |
| uvos | ok so for mapping to a specific window | 15:27 |
| uvos | h-d must have the information | 15:27 |
| uvos | it dosent know what process a window comes from really | 15:27 |
| uvos | so i would expect that the notfication sets an atom and the applciation sets an atom on its window | 15:28 |
| uvos | this could be destination | 15:28 |
| Wizzup | dsc_: maybe sphone's src/modules/notify-libnotify.c can help | 15:28 |
| uvos | examing the atoms of a window pair that implements this is what you need | 15:28 |
| uvos | no sphone wont help you with this | 15:29 |
| Wizzup | don't you do this on new sms? | 15:29 |
| uvos | its a well behaved xda compliant user of libnotify | 15:29 |
| uvos | no it dosent use any of this machinery | 15:29 |
| Wizzup | dsc_: I think we can start with what sphone does | 15:29 |
| dsc_ | what does sphone do? | 15:29 |
| Wizzup | uvos ^ :) | 15:30 |
| Wizzup | getting it on top of the conversations window is just a minor detail for me atm | 15:30 |
| uvos | it uses libnotify to span a regular xdg notification | 15:30 |
| dsc_ | ok ill just do that | 15:30 |
| uvos | h-h then has a hardcoded subset of behaviors it dose when it cant find a "group" | 15:30 |
| uvos | it also dosent implement the full xdg spec | 15:31 |
| dsc_ | oh, I spoke to soon. I wont do that. | 15:31 |
| uvos | (you get no led or sound for instance) | 15:31 |
| uvos | sphoen compensates by playing a sound itself | 15:31 |
| uvos | another problem you have to be carefull about is that there is a assumption that there is a notifaction que that h-h dose not implement, it simply spawns a new window for eatch notification | 15:32 |
| Wizzup | we can fix the led/sound by fixing hildon-home, so don't worry about it for conversations | 15:33 |
| uvos | this is quite broken, you can for instance crash hildon with gpodder by downloading a podcast | 15:33 |
| uvos | since eatch download generates a notification | 15:33 |
| uvos | and h-h will spawn windows untill the device runns out of resources | 15:33 |
| uvos | this is a problem for sphone too | 15:33 |
| uvos | when manny sms are recieved when the device comes online again | 15:34 |
| uvos | so we rate limit this | 15:34 |
| dsc_ | ill just use libnotify to spawn a notification, it will have its own window | 15:36 |
| dsc_ | can fix this later by looking at hd in-depth | 15:36 |
| Wizzup | agreed, thanks | 15:36 |
| Wizzup | what you might want to do is save the notification id | 15:36 |
| dsc_ | sure | 15:37 |
| Wizzup | so you can match that to the relevant action | 15:37 |
| uvos | h-h support only one action | 15:37 |
| uvos | well 2 one is close | 15:37 |
| Wizzup | what I mean is open the right conversation | 15:37 |
| uvos | this is conformant to a old version of the xdg protocoll | 15:37 |
| uvos | right ok | 15:37 |
| uvos | i gues you could also make converstaions a ui plugin for sphone and not worry about this :P | 15:39 |
| Wizzup | not at this stage, but potentially later | 15:40 |
| freemangordon | uvos: I will start working on h-h, however, I still don;t get it how recent specs deal with what we have as vendor extension here | 17:06 |
| freemangordon | like - is dbus callback in the specs? | 17:06 |
| freemangordon | "desktop-entry" hint? | 17:07 |
| uvos | you could use that, or just have a dbus call vendor hint | 17:07 |
| freemangordon | ok, but then we are still not in the specs | 17:07 |
| uvos | having vendor hints is in spec | 17:08 |
| freemangordon | ok, but this will not work ouside of maemo | 17:08 |
| freemangordon | so what is the point? | 17:08 |
| uvos | sure | 17:08 |
| uvos | the point is that having hardcoded behavior is bad, having the bavior defined by hints is much better | 17:09 |
| uvos | also things like the sounds one could implemt in base spec | 17:09 |
| freemangordon | you mean "sound-file" etc? | 17:10 |
| uvos | yeah | 17:10 |
| uvos | that would be nice | 17:10 |
| freemangordon | yeah, but that's a detail | 17:10 |
| freemangordon | ok, lemme see | 17:10 |
| uvos | the main thing is that it is imo assinine that if you want to have a email notification | 17:10 |
| uvos | you must be the implementor of the modest dbus api | 17:10 |
| uvos | by simply passing the dbus api as a hint | 17:10 |
| uvos | this would be resolved | 17:10 |
| uvos | same thing with the special behavior | 17:11 |
| uvos | like stacking etc | 17:11 |
| freemangordon | so, you want me to remove that .conf file and used some hint instead? | 17:11 |
| uvos | why must i be a specifc application to get stackin notifications | 17:11 |
| freemangordon | *use | 17:11 |
| uvos | yeah essentally just shoeve all the stuff in that conf file into hints | 17:11 |
| uvos | you could even have both | 17:12 |
| uvos | for backward compatability | 17:12 |
| freemangordon | ok, but what about multiple apps handling the same type of event? | 17:12 |
| freemangordon | the same 'group' | 17:12 |
| uvos | what about that, if you have everything as hints it works fine | 17:12 |
| freemangordon | like, if we have 2 mail clients | 17:12 |
| uvos | it dosent work at all atm | 17:12 |
| freemangordon | and bot set categoty to email | 17:13 |
| freemangordon | *both | 17:13 |
| freemangordon | with separate dbus callbacks | 17:13 |
| uvos | if you have 2 mail clients theres no problem because eatch notification has the dbus api hint of what client to use to handle it | 17:13 |
| freemangordon | this will go to one stack, no? | 17:13 |
| freemangordon | ok, but the stack is only one | 17:13 |
| freemangordon | so, what the user clicks on the stack, which client shall we run? | 17:14 |
| freemangordon | *when the user | 17:14 |
| uvos | your designing a new interface here | 17:14 |
| uvos | the client has to send the Destination hint anyhow | 17:14 |
| uvos | use that to make 2 stacks | 17:14 |
| freemangordon | I know, but if we allow everyone to set a 'callback' hint, we shall resolve the conflicts somehow | 17:14 |
| freemangordon | ok | 17:15 |
| uvos | also maybe notifications should allways be stacking | 17:15 |
| uvos | and use the dbus caller to make stacks (regardless of hints) | 17:15 |
| uvos | since the new window for eatch notification is a problem with lots of apps | 17:16 |
| uvos | since they expect a que | 17:16 |
| freemangordon | what specs say about that? | 17:16 |
| freemangordon | (if you know) | 17:16 |
| freemangordon | hmm, we have app_name | 17:17 |
| uvos | afaik nothing, but in practice telegram for instance will send a notification for eatch message that came in while you where offline when you log in, can easly be 100s of notifications | 17:17 |
| freemangordon | I see | 17:17 |
| uvos | also gpodder will create a notification for eatch downloaded epsiode when you download a podcast | 17:17 |
| freemangordon | does it set app_name? | 17:17 |
| uvos | again 100s of potential notificaions | 17:17 |
| uvos | so in practice these appications expect a que | 17:17 |
| uvos | not sure, will check when i get the chance | 17:18 |
| freemangordon | ok | 17:18 |
| freemangordon | in the meanwhile I will think about how to properly group them | 17:18 |
| freemangordon | Wizzup: do we have -devel repo for extras? | 20:51 |
| freemangordon | figured it out, it is -testing | 21:02 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!