noidea_ has quit [Remote host closed the connection]
noidea_ has joined #maemo-leste
noidea__ has joined #maemo-leste
noidea_ has quit [Ping timeout: 255 seconds]
Daanct12 has joined #maemo-leste
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
macros_2ndPC has quit [Ping timeout: 248 seconds]
macros_2ndPC has joined #maemo-leste
Twig has joined #maemo-leste
ceene has joined #maemo-leste
Hatman has joined #maemo-leste
Hatman has quit [Remote host closed the connection]
Supositware has quit [Ping timeout: 252 seconds]
pere has quit [Ping timeout: 240 seconds]
pere has joined #maemo-leste
xmn has quit [Ping timeout: 260 seconds]
uvos__ has joined #maemo-leste
<uvos__>
norayr: besides wirteing your own notification deamon you cant
<uvos__>
norayr: the maemo notification deamon (par of h-h) is hardcoded to only blink the led/play sounds/vibrate etc for a specific set of stock freemantle apps
<uvos__>
yes this is a massive defficancy, fremantles notifcation system is bad in general
<Wizzup>
uvos__: we could change this
<Wizzup>
to vibrate on general ones too
<uvos__>
the problem is more the hardcodeing
<uvos__>
you dont want to vibrate on every notfication either
<uvos__>
the way sphone currently works is also a huge hack
<uvos__>
because it cant do the right thing because its not called rtcomm on dbus
<Wizzup>
doesn't sound like it would be hard to add another item to h-d
<freemangordon>
uvos__: yes, we can change, just have to extend the functionality to do run-parts on config files
<Wizzup>
btw: I will be a bit less available until Sunday, having family visit me
<freemangordon>
uvos__: also, your opinion on what is good or bad is not necessarily true, maybe add "IMO" when making such statements
<freemangordon>
notifications protocol has a major deficiency that it does not have the idea of "persistent across reboot" notifications, but that does not make it "good" or "bad"
<freemangordon>
it is just that it lacks functionality
<freemangordon>
and BTW, this is why Nokia did what they did
<uvos__>
no
<uvos__>
i doubt
<uvos__>
persistant notifications are a thing in the spec, and cross reboot is no problem if they shove thair dbus endpoint into a x-maemo property
<uvos__>
the hardcodeing is just bad design
<uvos__>
i dont think there is anything subjective about it
<uvos__>
but no matter
<freemangordon>
no, persistent notifications are not saved across rebotos
<freemangordon>
*reboots
<freemangordon>
they are persistent in the sense that user has to dismiss them
<freemangordon>
but if reboot happens thay are lost
<freemangordon>
*they
<uvos__>
thats not true
<uvos__>
nothing in the spec prevents the notifcation server from saveing persistant notifcations across reboot
<uvos__>
it is simply silent on the topic
<uvos__>
imo in spec the difference between a presistant notification and one that has no timeout is not clear
Twig has quit [Ping timeout: 260 seconds]
Twig has joined #maemo-leste
<freemangordon>
but on the other hand no daemon saves notifications across reboots, so I doubt they meant it
<freemangordon>
hmm, my PC keyboard seems to develop HW issues :(
<freemangordon>
anyway, I can implement something, if we agree on what exactly :)
<freemangordon>
uvos__: Wizzup: ^^^
<freemangordon>
uvos__: "Notifications will be retained until they are acknowledged or removed by the user or recalled by the sender."
<freemangordon>
but, sfter a reboot sender is no longer valid
<freemangordon>
because, IIRC, sender is the process (dbus one) that made the notification in the first place
<freemangordon>
this is not persistent across reboot, so there is no way a sender to remove notification after a reboot, even if it keeps the id
<freemangordon>
agree?
<Wizzup>
I think that is true
<uvos__>
freemangordon: i think a first non-contraversioal thing to implement
<uvos__>
would be the xdg specs used when a notification dosent belong to a hardcoded sender
<uvos__>
like honoring the sound hint and so on
<uvos__>
this would initally improve the situation, since more stuff would just work with regular non maemo users of the xdg notification bus
<freemangordon>
right
<freemangordon>
"sound-name" I guess, or "sound-file" too?
<uvos__>
maybe both is not so hard idk, best check what gets used in practice maybe
<freemangordon>
also, I am not sure how to deal with versions, as sound hint is supported by specs >= 1.2
<uvos__>
i dont thing you have to worry about versions atm
<freemangordon>
ok
<uvos__>
kdes notification server just reports the latest version
<freemangordon>
ok, will start with that
<freemangordon>
most-probably because it implements it :)
<uvos__>
sure maybe i missunderstood
<uvos__>
i mean that reporting a never version has no downside (if you implement it)
<freemangordon>
in the meanwhile will think about adding a way for an application to runtime-register itself like a fremantle apps do
<uvos__>
as they are backwards compatable with old clients
<freemangordon>
no, it is not
<freemangordon>
see hints
<freemangordon>
there are version conflicts
* Wizzup
back later
<freemangordon>
uvos__: a side question - besides xorg dying too early, do you think we have a proper login session now?
<uvos__>
sure, could be better however
<uvos__>
currently we cant restart it if it fails
<uvos__>
also usind xdg-session spec would have benefits
<uvos__>
but this is small fry
<freemangordon>
what do you mean "session fails"?
<freemangordon>
xorg dies?
<uvos__>
or autologind
<uvos__>
*autologin
<uvos__>
ie if the session ends
<uvos__>
we cant restart it
<uvos__>
why dosent matter
<freemangordon>
I don;t think we want to anyways
<freemangordon>
better restart the device
<uvos__>
not really
<uvos__>
if x dies restarting just it would be better no?
<freemangordon>
actually, there is no reason to not be able to restart the session
<freemangordon>
it is a matter of telling dsme to do so
<uvos__>
also on mapphones is would be beneftical to be able to do so