| norayr | how can i make d4 to vibrate when dino sends notification? | 00:44 |
|---|---|---|
| uvos__ | norayr: besides wirteing your own notification deamon you cant | 10:46 |
| 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 | 10:47 |
| uvos__ | yes this is a massive defficancy, fremantles notifcation system is bad in general | 10:48 |
| Wizzup | uvos__: we could change this | 10:59 |
| Wizzup | to vibrate on general ones too | 11:00 |
| uvos__ | the problem is more the hardcodeing | 11:09 |
| uvos__ | you dont want to vibrate on every notfication either | 11:09 |
| uvos__ | the way sphone currently works is also a huge hack | 11:09 |
| uvos__ | because it cant do the right thing because its not called rtcomm on dbus | 11:10 |
| Wizzup | doesn't sound like it would be hard to add another item to h-d | 11:20 |
| freemangordon | uvos__: yes, we can change, just have to extend the functionality to do run-parts on config files | 11:20 |
| Wizzup | btw: I will be a bit less available until Sunday, having family visit me | 11:21 |
| freemangordon | uvos__: also, your opinion on what is good or bad is not necessarily true, maybe add "IMO" when making such statements | 11:21 |
| 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" | 11:23 |
| freemangordon | it is just that it lacks functionality | 11:24 |
| freemangordon | and BTW, this is why Nokia did what they did | 11:24 |
| uvos__ | no | 11:29 |
| uvos__ | i doubt | 11:29 |
| 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 | 11:30 |
| uvos__ | the hardcodeing is just bad design | 11:30 |
| uvos__ | i dont think there is anything subjective about it | 11:30 |
| uvos__ | but no matter | 11:30 |
| freemangordon | no, persistent notifications are not saved across rebotos | 11:39 |
| freemangordon | *reboots | 11:39 |
| freemangordon | they are persistent in the sense that user has to dismiss them | 11:39 |
| freemangordon | but if reboot happens thay are lost | 11:39 |
| freemangordon | *they | 11:39 |
| uvos__ | thats not true | 11:41 |
| uvos__ | nothing in the spec prevents the notifcation server from saveing persistant notifcations across reboot | 11:42 |
| uvos__ | it is simply silent on the topic | 11:42 |
| uvos__ | imo in spec the difference between a presistant notification and one that has no timeout is not clear | 11:43 |
| freemangordon | but on the other hand no daemon saves notifications across reboots, so I doubt they meant it | 12:01 |
| freemangordon | hmm, my PC keyboard seems to develop HW issues :( | 12:01 |
| freemangordon | anyway, I can implement something, if we agree on what exactly :) | 12:04 |
| freemangordon | uvos__: Wizzup: ^^^ | 12:04 |
| freemangordon | uvos__: "Notifications will be retained until they are acknowledged or removed by the user or recalled by the sender." | 12:05 |
| freemangordon | but, sfter a reboot sender is no longer valid | 12:05 |
| freemangordon | because, IIRC, sender is the process (dbus one) that made the notification in the first place | 12:06 |
| 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 | 12:07 |
| freemangordon | agree? | 12:07 |
| Wizzup | I think that is true | 12:11 |
| uvos__ | freemangordon: i think a first non-contraversioal thing to implement | 12:12 |
| uvos__ | would be the xdg specs used when a notification dosent belong to a hardcoded sender | 12:12 |
| uvos__ | like honoring the sound hint and so on | 12:12 |
| uvos__ | this would initally improve the situation, since more stuff would just work with regular non maemo users of the xdg notification bus | 12:13 |
| freemangordon | right | 12:13 |
| freemangordon | "sound-name" I guess, or "sound-file" too? | 12:14 |
| uvos__ | maybe both is not so hard idk, best check what gets used in practice maybe | 12:15 |
| freemangordon | also, I am not sure how to deal with versions, as sound hint is supported by specs >= 1.2 | 12:15 |
| uvos__ | i dont thing you have to worry about versions atm | 12:15 |
| freemangordon | ok | 12:15 |
| uvos__ | kdes notification server just reports the latest version | 12:16 |
| freemangordon | ok, will start with that | 12:16 |
| freemangordon | most-probably because it implements it :) | 12:16 |
| uvos__ | sure maybe i missunderstood | 12:16 |
| uvos__ | i mean that reporting a never version has no downside (if you implement it) | 12:16 |
| freemangordon | in the meanwhile will think about adding a way for an application to runtime-register itself like a fremantle apps do | 12:17 |
| uvos__ | as they are backwards compatable with old clients | 12:17 |
| freemangordon | no, it is not | 12:17 |
| freemangordon | see hints | 12:17 |
| freemangordon | there are version conflicts | 12:17 |
| * Wizzup back later | 12:17 | |
| freemangordon | uvos__: a side question - besides xorg dying too early, do you think we have a proper login session now? | 12:18 |
| uvos__ | sure, could be better however | 12:19 |
| uvos__ | currently we cant restart it if it fails | 12:19 |
| uvos__ | also usind xdg-session spec would have benefits | 12:19 |
| uvos__ | but this is small fry | 12:19 |
| freemangordon | what do you mean "session fails"? | 12:19 |
| freemangordon | xorg dies? | 12:20 |
| uvos__ | or autologind | 12:20 |
| uvos__ | *autologin | 12:20 |
| uvos__ | ie if the session ends | 12:20 |
| uvos__ | we cant restart it | 12:20 |
| uvos__ | why dosent matter | 12:20 |
| freemangordon | I don;t think we want to anyways | 12:20 |
| freemangordon | better restart the device | 12:20 |
| uvos__ | not really | 12:20 |
| uvos__ | if x dies restarting just it would be better no? | 12:20 |
| freemangordon | actually, there is no reason to not be able to restart the session | 12:20 |
| freemangordon | it is a matter of telling dsme to do so | 12:21 |
| uvos__ | also on mapphones is would be beneftical to be able to do so | 12:21 |
| uvos__ | to swich ui | 12:21 |
| uvos__ | when transforming to laptop mode | 12:21 |
| freemangordon | here https://github.com/maemo-leste/maemo-system-services/blob/master/debian/maemo-system-services.xorg.init#L15 | 12:21 |
| freemangordon | we can tell dsme to not reboot, but to restart the session | 12:22 |
| freemangordon | but those are details I guess | 12:22 |
| freemangordon | my question was more general, like "did I miss something obvious" | 12:23 |
| uvos__ | no | 12:23 |
| uvos__ | btw | 12:23 |
| freemangordon | also, what about https://github.com/maemo-leste/dsme/commit/929cde639a74cecde58d1fdf86316daa51ea1e27 | 12:23 |
| uvos__ | i dont think the ts inhibit is working | 12:23 |
| uvos__ | pm wise | 12:23 |
| freemangordon | it is, at least here | 12:23 |
| uvos__ | i mean its inhibiting it | 12:23 |
| freemangordon | ah | 12:23 |
| uvos__ | but this seams to not reduce power | 12:23 |
| freemangordon | it does here | 12:24 |
| uvos__ | hm | 12:24 |
| freemangordon | about 30mW lee | 12:24 |
| freemangordon | *less | 12:24 |
| uvos__ | maybe its something else | 12:24 |
| uvos__ | currently my device dosent idle right | 12:24 |
| freemangordon | what is the power usage? | 12:24 |
| uvos__ | 200mW | 12:24 |
| uvos__ | ill investigate later | 12:24 |
| freemangordon | here it hits less that 150 at times, connected to wifi | 12:25 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!