<dsc_>
even then, how would hildon know to map it to the conversations window?
<dsc_>
via `Destination=Rtcom-messaging-ui` ?
<dsc_>
so it would become `Destination=conversations` ?
<dsc_>
and then Hildon can find a window named 'conversations'
ahmed_sam has joined #maemo-leste
<Wizzup>
dsc_: I think that might be the binary name, not sure if it matches some other name
<Wizzup>
I was thinking the same but wanted to research before asking you to try it :)
<dsc_>
ill try it :)
<uvos>
no
ahmed_sam has quit [Read error: Connection reset by peer]
<uvos>
so theres some extended vendor proparty that specifices the "group"
<uvos>
the dbus call in the config file is the call used to call the application on user interaction
<uvos>
i think the Destination is used by the implementor of RtcomNotificationUi but not sure
<uvos>
mainly i would say: all of this is horrible
<dsc_>
even if it is horrible, I just dont understand how to implement a notification that maps to a specific window
<uvos>
it makes mutch more sense to properly implement this using libnotify extensions
<uvos>
ok so for mapping to a specific window
<uvos>
h-d must have the information
<uvos>
it dosent know what process a window comes from really
<uvos>
so i would expect that the notfication sets an atom and the applciation sets an atom on its window
<uvos>
this could be destination
<Wizzup>
dsc_: maybe sphone's src/modules/notify-libnotify.c can help
<uvos>
examing the atoms of a window pair that implements this is what you need
<uvos>
no sphone wont help you with this
<Wizzup>
don't you do this on new sms?
<uvos>
its a well behaved xda compliant user of libnotify
<uvos>
no it dosent use any of this machinery
<Wizzup>
dsc_: I think we can start with what sphone does
<dsc_>
what does sphone do?
<Wizzup>
uvos ^ :)
<Wizzup>
getting it on top of the conversations window is just a minor detail for me atm
<uvos>
it uses libnotify to span a regular xdg notification
<dsc_>
ok ill just do that
<uvos>
h-h then has a hardcoded subset of behaviors it dose when it cant find a "group"
<uvos>
it also dosent implement the full xdg spec
<dsc_>
oh, I spoke to soon. I wont do that.
<uvos>
(you get no led or sound for instance)
<uvos>
sphoen compensates by playing a sound itself
<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
<Wizzup>
we can fix the led/sound by fixing hildon-home, so don't worry about it for conversations
<uvos>
this is quite broken, you can for instance crash hildon with gpodder by downloading a podcast
<uvos>
since eatch download generates a notification
<uvos>
and h-h will spawn windows untill the device runns out of resources
<uvos>
this is a problem for sphone too
<uvos>
when manny sms are recieved when the device comes online again
<uvos>
so we rate limit this
<dsc_>
ill just use libnotify to spawn a notification, it will have its own window
<dsc_>
can fix this later by looking at hd in-depth
<Wizzup>
agreed, thanks
<Wizzup>
what you might want to do is save the notification id
<dsc_>
sure
<Wizzup>
so you can match that to the relevant action
<uvos>
h-h support only one action
<uvos>
well 2 one is close
<Wizzup>
what I mean is open the right conversation
<uvos>
this is conformant to a old version of the xdg protocoll
<uvos>
right ok
<uvos>
i gues you could also make converstaions a ui plugin for sphone and not worry about this :P
<Wizzup>
not at this stage, but potentially later
ceene has quit [Ping timeout: 252 seconds]
xmn has joined #maemo-leste
hexagonwin has joined #maemo-leste
<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
<freemangordon>
like - is dbus callback in the specs?
<freemangordon>
"desktop-entry" hint?
<uvos>
you could use that, or just have a dbus call vendor hint
<freemangordon>
ok, but then we are still not in the specs
<uvos>
having vendor hints is in spec
<freemangordon>
ok, but this will not work ouside of maemo
<freemangordon>
so what is the point?
<uvos>
sure
<uvos>
the point is that having hardcoded behavior is bad, having the bavior defined by hints is much better
<uvos>
also things like the sounds one could implemt in base spec
<freemangordon>
you mean "sound-file" etc?
<uvos>
yeah
<uvos>
that would be nice
<freemangordon>
yeah, but that's a detail
<uvos>
the main thing is that it is imo assinine that if you want to have a email notification
<freemangordon>
ok, lemme see
<uvos>
you must be the implementor of the modest dbus api
<uvos>
by simply passing the dbus api as a hint
<uvos>
this would be resolved
<uvos>
same thing with the special behavior
<uvos>
like stacking etc
<freemangordon>
so, you want me to remove that .conf file and used some hint instead?
<uvos>
why must i be a specifc application to get stackin notifications
<freemangordon>
*use
<uvos>
yeah essentally just shoeve all the stuff in that conf file into hints
<uvos>
you could even have both
<uvos>
for backward compatability
<freemangordon>
ok, but what about multiple apps handling the same type of event?
<freemangordon>
the same 'group'
<uvos>
what about that, if you have everything as hints it works fine
<freemangordon>
like, if we have 2 mail clients
<uvos>
it dosent work at all atm
<freemangordon>
and bot set categoty to email
<freemangordon>
*both
<freemangordon>
with separate dbus callbacks
<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
<freemangordon>
this will go to one stack, no?
<freemangordon>
ok, but the stack is only one
<freemangordon>
so, what the user clicks on the stack, which client shall we run?
<freemangordon>
*when the user
<uvos>
your designing a new interface here
<uvos>
the client has to send the Destination hint anyhow
<uvos>
use that to make 2 stacks
<freemangordon>
I know, but if we allow everyone to set a 'callback' hint, we shall resolve the conflicts somehow
<freemangordon>
ok
<uvos>
also maybe notifications should allways be stacking
<uvos>
and use the dbus caller to make stacks (regardless of hints)
<uvos>
since the new window for eatch notification is a problem with lots of apps
<uvos>
since they expect a que
<freemangordon>
what specs say about that?
<freemangordon>
(if you know)
<freemangordon>
hmm, we have app_name
<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
<freemangordon>
I see
<uvos>
also gpodder will create a notification for eatch downloaded epsiode when you download a podcast
<freemangordon>
does it set app_name?
<uvos>
again 100s of potential notificaions
<uvos>
so in practice these appications expect a que
<uvos>
not sure, will check when i get the chance
<freemangordon>
ok
<freemangordon>
in the meanwhile I will think about how to properly group them
akossh has joined #maemo-leste
fab_ has joined #maemo-leste
Danct12 has quit [Quit: A-lined: This user has been AViVA-lined!]
Danct12 has joined #maemo-leste
Danct12 has quit [Client Quit]
Danct12 has joined #maemo-leste
neimsaci has joined #maemo-leste
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #maemo-leste
neimsaci has quit [Quit: WeeChat 4.1.0]
<freemangordon>
Wizzup: do we have -devel repo for extras?