| uvos | freemangordon: i agree that the spec saies to remove the entire block shal be removed | 00:14 |
|---|---|---|
| uvos | but i also agree with sicelo that removeing just the tags is probubly more usefull in practice | 00:14 |
| uvos | *freemangordon: i agree that the spec saies to remove the entire block | 00:15 |
| Wizzup | I'm not sure if we want to do any parsing if we can avoid it | 00:31 |
| freemangordon | Wizzup: we can't avoid | 07:01 |
| freemangordon | sicelo: while I agree to some extend, how useful would be to display a link that cannot be clicked? | 07:16 |
| sicelo | yes, i didn't finish writing another sentence to the effect that an unclickable link is somewhat confusing too. However, user intuition can help in that case, while it's totally absent when tag+text are gone | 08:23 |
| freemangordon | yeah, but specs say we shall remove it :( | 08:29 |
| freemangordon | it is confusing | 08:29 |
| freemangordon | see https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html#markup | 08:29 |
| sicelo | i have just read that link. if i understand it correctly, it's saying to strip the tag (not the text) | 08:35 |
| sicelo | "The tags specified above mark up the content in a way that allows them to be stripped out on some implementations without impacting the actual content. " | 08:36 |
| sicelo | what it's saying sounds exactly like in the example i gave above | 08:37 |
| freemangordon | ok, unless someone objects I will implement it as you say | 08:38 |
| sicelo | and yes, this means no parsing, unless i misunderstand. basically you find '<' ... skip everything until you reach '>'. done | 08:39 |
| freemangordon | no, I must parse | 08:39 |
| freemangordon | as I want to support <b> <i> etc | 08:39 |
| freemangordon | but not <a> and <img> | 08:39 |
| sicelo | ah, ok :-) | 08:39 |
| freemangordon | it is not a biggie | 08:39 |
| freemangordon | I am using GMarkupParser, which is said to be lightweight parser | 08:40 |
| sicelo | back to that sentence a bit: text is 'content', so the sentence indicates that content shall not be touched | 08:40 |
| freemangordon | ok | 08:40 |
| freemangordon | I will display links as blue underlined text | 08:40 |
| freemangordon | someday we may even want to support click on that as well | 08:41 |
| Wizzup | let's hope this doesn't introduce exploits throught notification :D | 10:25 |
| freemangordon | it shouldn't :) | 10:47 |
| freemangordon | hmm, it seems libnotify assumes that timeout 0 means persistent notification | 10:48 |
| freemangordon | but h-h looks for 'persistent' hint | 10:49 |
| freemangordon | I wonder what 'persistent' with non-zero timeout would be | 10:50 |
| uvos | "<freemangordon> I wonder what 'persistent' with non-zero timeout would be" | 11:17 |
| uvos | most notification servers have a global que | 11:18 |
| uvos | probubly this means to show the notification for timeout and then put it into the (usually hidden untill the user clicks) que | 11:18 |
| uvos | but ill test that theory on kde and lxqt in a sec | 11:18 |
| freemangordon | uvos: could be, but still, if this is persistent across reboots, I wonder how actions shall be implemented then | 11:20 |
| freemangordon | as those are dbus callbacks | 11:20 |
| uvos | none of the notifications are presistant across reboots | 11:20 |
| uvos | or restarts of the server | 11:20 |
| freemangordon | hmm | 11:20 |
| uvos | as far as i can tell | 11:21 |
| freemangordon | well, we support that :) | 11:21 |
| uvos | well as you note | 11:21 |
| uvos | it cant really work | 11:21 |
| freemangordon | i can, as soon as there are no actions involved | 11:21 |
| uvos | sure you can have grayed out notifications | 11:21 |
| uvos | or something | 11:22 |
| freemangordon | also, for example conversations or call-ui can listen to dbus and activate themselves | 11:22 |
| uvos | clearly a uninteneded hack | 11:23 |
| freemangordon | TBH I cannot find a single user in fremantle that sets "persistent" property | 11:23 |
| freemangordon | ok, so it seems we do not support persistence then (in terms of specs) | 11:24 |
| Wizzup | doesn't seem like a big deal atm? | 11:24 |
| freemangordon | sure no | 11:24 |
| freemangordon | I am just trying to figure out what we support and what not | 11:24 |
| freemangordon | to properly report to clients | 11:25 |
| uvos | probubly usefull for pressistance to exist | 11:25 |
| uvos | for instance for a mute button | 11:26 |
| Wizzup | I think for that we might want some notifications window or status applet | 11:26 |
| Wizzup | but it doesn't seem quite essential now in any case ;) | 11:26 |
| uvos | as a global que yeah eventually | 11:26 |
| freemangordon | yeah, some status bar applet | 11:26 |
| uvos | i dont see how my gf could survive if every notification has its own window :P | 11:26 |
| freemangordon | no, it is not like that | 11:26 |
| freemangordon | h-h supports threadung and category | 11:27 |
| freemangordon | so notifications gets grouped | 11:27 |
| freemangordon | don;t ask me how, but the code is tehre | 11:27 |
| uvos | the dekstop notification spec if seams to create a new window for every call | 11:27 |
| freemangordon | no | 11:27 |
| uvos | hmm it dosent work then | 11:27 |
| freemangordon | well, it depends on how you use that | 11:27 |
| freemangordon | you should set the hints correctly | 11:28 |
| uvos | what hints? | 11:28 |
| uvos | are thes mameo specific | 11:28 |
| * freemangordon checks | 11:28 | |
| uvos | the dekstop apps that do work with the if atm | 11:28 |
| uvos | spamm lots of windows | 11:28 |
| uvos | like if i download 10 podcasts via gpodder | 11:28 |
| uvos | ill get 10 windows with the compleate notification | 11:28 |
| uvos | really annoying | 11:28 |
| freemangordon | see https://github.com/maemo-leste/hildon-home/blob/master/src/hd-incoming-events.c#L74 | 11:29 |
| freemangordon | you should figure out how this work though | 11:30 |
| freemangordon | maybe tehre is documentation | 11:30 |
| uvos | this dosent help tho | 11:30 |
| uvos | since no desktop app will ever set those | 11:30 |
| freemangordon | seems you are nto the only one :p | 11:31 |
| freemangordon | http://thpmaemo.blogspot.com/2010/08/desktop-notification-support-in-gpodder.html | 11:31 |
| uvos | so is hd_notification_get_category set via class specific prop on the dbus call? | 11:32 |
| freemangordon | but, at least it seems possible :) | 11:32 |
| freemangordon | IIUC 'category' hint is another story | 11:32 |
| uvos | ok | 11:32 |
| uvos | well thats not really great then | 11:32 |
| freemangordon | this is about grouping based on WM_CLASS of the application | 11:33 |
| freemangordon | lemme check how it is on fremantle | 11:33 |
| uvos | how dose it do that? | 11:33 |
| uvos | query on the pid? | 11:33 |
| uvos | to find x windows? | 11:33 |
| freemangordon | maybe, I haven't looked at the code | 11:33 |
| uvos | dont see how else it could work | 11:34 |
| uvos | that sounds... farily horrible | 11:34 |
| freemangordon | well, tasknav already does that either ways | 11:34 |
| freemangordon | it already "adopts" X windows | 11:34 |
| freemangordon | so not really an issue | 11:34 |
| uvos | sure its an issue, it breaks lots of things | 11:35 |
| uvos | xwindows of a "applicaiton" dont even have to be in the same pid | 11:35 |
| uvos | for starters | 11:35 |
| freemangordon | no, because that's how application thumbnail is shown in tasknav | 11:35 |
| uvos | or set that pid | 11:35 |
| uvos | ? | 11:35 |
| freemangordon | does not matter, it is about the window class, not the PID | 11:36 |
| uvos | yeah but to get to the window class | 11:36 |
| uvos | you need a xwindow | 11:36 |
| freemangordon | and you already have it | 11:36 |
| uvos | to get the window from the dbus call | 11:36 |
| freemangordon | in hildon-desktop | 11:36 |
| freemangordon | no,no | 11:36 |
| uvos | you need to check what pid owns what window | 11:36 |
| freemangordon | you don;t care about dus call | 11:36 |
| freemangordon | why do you care? | 11:36 |
| uvos | how do you correlate the window with the notification (to get WM_CLASS) | 11:37 |
| uvos | ? | 11:37 |
| freemangordon | anyway, lemme see what this file contains in fremantle | 11:37 |
| uvos | you have to correlate the dbus call with a xwindow somehow | 11:37 |
| freemangordon | dunno | 11:37 |
| freemangordon | look at the code | 11:37 |
| uvos | right the only way to do so is via pid | 11:37 |
| uvos | and thats horrible | 11:37 |
| freemangordon | no, it seems it uses "category" from dbus call | 11:37 |
| freemangordon | and maps that category via the config file to know which WM_CLASS to use | 11:38 |
| uvos | ok then thats fine | 11:38 |
| freemangordon | that's what I saw from a quick glance | 11:38 |
| uvos | still i dont think mutch sets this | 11:38 |
| freemangordon | well... | 11:38 |
| uvos | ill try some more stuff | 11:38 |
| freemangordon | see notification_get_group() | 11:39 |
| freemangordon | ugh... | 11:40 |
| freemangordon | uvos: https://pastebin.com/4NLthG6h | 11:40 |
| freemangordon | :) | 11:40 |
| freemangordon | what is missing here is .d, but I guess we can easily add that | 11:42 |
| uvos | ugh thats farily horrific no | 11:42 |
| freemangordon | no, why horrific? | 11:43 |
| freemangordon | it is fairly configurable and if we miss something... well | 11:43 |
| freemangordon | we can add it | 11:43 |
| uvos | ? a config file with destinations | 11:43 |
| uvos | hows that not horrific | 11:43 |
| freemangordon | we can replace with mime type | 11:44 |
| uvos | it breaks pretty mutch everything | 11:44 |
| freemangordon | and xdg_open | 11:44 |
| uvos | thats still broken | 11:44 |
| uvos | what about actions? | 11:44 |
| freemangordon | there is only "default" action. fullstop :) | 11:44 |
| uvos | xdg_open ing soemthing is not the same as triggering an action | 11:44 |
| uvos | default action and xdg_open are not the same | 11:45 |
| freemangordon | agree | 11:45 |
| freemangordon | but, I don;t think "destination" is mandatory | 11:45 |
| freemangordon | so actions will still execute | 11:45 |
| freemangordon | well, "default" action | 11:45 |
| uvos | its still terrible, your essentaly "hardcodeing" special behavior for some blessed apps | 11:46 |
| freemangordon | anyway, lemme push what I have done so far | 11:46 |
| freemangordon | uvos: https://github.com/maemo-leste/hildon-home/pull/2 | 11:50 |
| uvos | looks ok | 11:59 |
| uvos | ill test later today | 11:59 |
| freemangordon | hmm, lemme force-push fix for one possible memleak | 12:00 |
| freemangordon | uvos: done | 12:04 |
| freemangordon | this https://github.com/maemo-leste/hildon-home/compare/76d57aeb1d88abfb3ffa180889e63be46196a9de..bf4916ebb52cfa8ed991ffb20c186bfdfad56a04 | 12:05 |
| Wizzup | freemangordon: ok with putting osso-addressbook in stable / meta pkg? | 12:46 |
| freemangordon | sure | 12:47 |
| freemangordon | it lacks some stuff, and has at least one issue (segfault I can no longer repro now gtalk does not work), but otherwise... | 12:47 |
| Wizzup | there's the thing with telepathy-haze and slack where everyone is (no name) | 12:48 |
| Wizzup | but I think that is for later :) | 12:48 |
| freemangordon | yeah | 13:00 |
| mighty17[m] | freemangordon: is `egl-dri2-Workaround-for-EGL_EXT_image_dma_buf_import.patch` still needed after https://github.com/maemo-leste-upstream-forks/mesa/commit/87c70d8e169d8034998f1859d11b2541ffceee3e | 14:08 |
| freemangordon | mighty17[m]: I guess no | 14:37 |
| freemangordon | but, you'd better just use mesa from repos | 14:38 |
| mighty17[m] | yup there's no need for it | 14:59 |
| mighty17[m] | tested with phosh :D | 14:59 |
| mighty17[m] | freemangordon: we dont have EXT_read_format_bgra working right? | 15:51 |
| freemangordon | why is that? | 15:52 |
| freemangordon | well, check with eglinfo | 15:52 |
| mighty17[m] | https://github.com/tmlind/wlroots/commit/04491889240bbadb693aa37036dc55835118b2cc | 15:52 |
| freemangordon | or es2_info | 15:52 |
| mighty17[m] | in a sec | 15:53 |
| mighty17[m] | freemangordon: nope, we do not | 15:56 |
| freemangordon | EXT_read_format_bgra is same as GL_IMG_read_format? | 15:57 |
| mighty17[m] | https://github.com/tmlind/wlroots/commit/04491889240bbadb693aa37036dc55835118b2cc acc to this, yes | 15:58 |
| mighty17[m] | <freemangordon> "well, check with eglinfo" <- `samsung-espresso3g:~$ DISPLAY=:0 XDG_RUNTIME_DIR=/run/user/10000 es2_info | grep -i GL_EXT_read_format_bgra` | 15:59 |
| mighty17[m] | `GL_EXT_read_format_bgra, GL_NV_pack_subimage, GL_EXT_frag_depth,` | 15:59 |
| mighty17[m] | it seems like its present, but the logs say `(phoc:18590): phoc-wlroots-CRITICAL **: 19:28:39.915: [render/gles2/renderer.c:445] Cannot read pixels: missing GL_EXT_read_format_bgra extension` | 15:59 |
| freemangordon | hmm, seems like a bug | 16:00 |
| freemangordon | which mesa is that? | 16:00 |
| mighty17[m] | from maemo-leste-upstream-forks | 16:01 |
| freemangordon | ok | 16:01 |
| * freemangordon boots d4 | 16:01 | |
| freemangordon | mighty17[m]: hmm, this is DRM or WL or X11? | 16:02 |
| freemangordon | I guess X11 | 16:02 |
| freemangordon | but you want DRM | 16:03 |
| mighty17[m] | WL | 16:03 |
| mighty17[m] | as in the error is from wl.... | 16:03 |
| freemangordon | yes, but renderer is drm, afaik | 16:03 |
| mighty17[m] | right | 16:04 |
| freemangordon | sec (phone call) | 16:06 |
| freemangordon | hmm, is it? | 16:11 |
| freemangordon | DISPLAY=:0 does not look like DRM | 16:11 |
| mighty17[m] | thats just me doing it from ssh | 16:12 |
| freemangordon | still, you ask for x11 platform capabilities | 16:12 |
| freemangordon | not for GBM platform | 16:12 |
| mighty17[m] | hm? im a bit lost | 16:12 |
| freemangordon | there are 3 platforms that have different extensions: GBM (or drm), X11 and WL | 16:13 |
| freemangordon | which renderer does wlroots use? | 16:14 |
| freemangordon | DRM or X11? | 16:14 |
| mighty17[m] | wayland | 16:14 |
| freemangordon | no, there is no such renderer, unless I am missing something | 16:14 |
| freemangordon | or was it backend? | 16:15 |
| * freemangordon checks | 16:15 | |
| mighty17[m] | hm im confused | 16:15 |
| freemangordon | wait a sec | 16:15 |
| mighty17[m] | i suppose its drm | 16:15 |
| freemangordon | see https://pastebin.com/KYTYZkeh | 16:17 |
| freemangordon | no GL_EXT_read_format_bgra | 16:18 |
| freemangordon | this is for DRM backend | 16:18 |
| mighty17[m] | hmm, then adding it should be as simple as reusing IMG_read_format ? | 16:20 |
| freemangordon | not sure https://registry.khronos.org/OpenGL/extensions/IMG/IMG_read_format.txt | 16:21 |
| mighty17[m] | <mighty17[m]> "https://github.com/tmlind/..." <- this commit did work magically | 16:23 |
| freemangordon | better ask tmlind about it | 16:23 |
| freemangordon | #define GL_BGRA_EXT 0x80E1 | 16:23 |
| freemangordon | #define GL_BGRA_IMG 0x80E1 | 16:23 |
| freemangordon | I think it should be a little more clever | 16:25 |
| mighty17[m] | maybe it isnt who knows | 16:25 |
| mighty17[m] | but fair point | 16:25 |
| freemangordon | hmm, no, seems those are interchangeable | 16:26 |
| freemangordon | besides that GL_EXT_read_format_bgra can return UNSIGNED_SHORT_1_5_5_5_REV_EXT in theory | 16:29 |
| freemangordon | so it is a superset of GL_IMG_read_format | 16:29 |
| freemangordon | mighty17[m]: you may want to fix that in pvr driver and make a PR | 16:30 |
| mighty17[m] | freemangordon: Pvr driver? Wdym mesa or blobs? | 16:34 |
| freemangordon | mesa | 16:35 |
| mighty17[m] | <freemangordon> "besides that GL_EXT_read_format_..." <- Ah then it should work by just interchanging :D | 16:35 |
| mighty17[m] | freemangordon: Me has no clue how🥲 | 16:35 |
| freemangordon | intercept eglQueryString and append GL_EXT_read_format_bgra to the list | 16:36 |
| freemangordon | ok, I may do that someday | 17:04 |
| Wizzup | freemangordon: https://www.youtube.com/watch?v=hBStZAGXvM0 | 17:53 |
| mighty17[m] | I'll look into it later this week then | 17:59 |
| uvos | is it not a bit wierd that it makes sutch a difference in fullscreen animations, did you improve something besides using buffer age? @freemangordon | 18:16 |
| uvos | i would have expected that to not matter if the entire display is changed | 18:17 |
| Wizzup | well that depends on if it's also reloading the bg no? | 18:17 |
| uvos | the bg also moves | 18:18 |
| uvos | was it redrawing the window pixmaps too? | 18:18 |
| uvos | ie updateing the textures | 18:18 |
| uvos | btw maybe we could fix the tasknav animation in portrait | 18:20 |
| uvos | its a bit of a pet peeve of mine (i can also try some time) | 18:20 |
| freemangordon | uvos: the big difference is that it does not re-upload the whole buffer every frame | 18:27 |
| freemangordon | that's what enunes' hack was doing | 18:27 |
| freemangordon | umm, what is wrong with tasknav animation? | 18:28 |
| uvos | freemangordon: in landscape it zooms out to the center of the display, in portrait it skews to one side, im pretty sure its just a missing coordinate swap | 18:28 |
| freemangordon | is that visible in the ^^^ video? | 18:29 |
| uvos | yeah | 18:29 |
| uvos | 2:45 | 18:29 |
| uvos | it looks like the center point of the animation dosent change for protrait | 18:30 |
| uvos | while the center of the display obv dose | 18:30 |
| uvos | just a minor visual glitch | 18:30 |
| freemangordon | hmm, I guess I can change transitions.ini to make that animation last few seconds | 18:31 |
| * freemangordon boots PP | 18:31 | |
| uvos | its visible on all devices btw | 18:31 |
| uvos | not pp specific | 18:31 |
| freemangordon | ok | 18:31 |
| freemangordon | tasknav is my pet for the last couple of years :) | 18:32 |
| freemangordon | so I will fix that when I find some spare time | 18:32 |
| uvos | then you probubly know where to look | 18:32 |
| freemangordon | shoudl be an easy fix | 18:32 |
| freemangordon | yeah | 18:32 |
| freemangordon | though I see nothing @ 2:45 | 18:33 |
| freemangordon | oh, right | 18:34 |
| freemangordon | now I see | 18:34 |
| sicelo | lovely 'woosh' sounds. have we had them all along, or they're new to Leste? | 19:40 |
| freemangordon | sicelo: audio was not working :) | 19:40 |
| freemangordon | or, if you mean "do we have it in fremantle?", yes, we have them | 19:41 |
| sicelo | i meant in Leste. i recall a day or two ago Wizzup said something about importing certain sounds. or those were ringtones only | 19:42 |
| Wizzup | it wasn't added to any meta pkg yet | 19:50 |
| uvos | the woosh sounds have been there all alonge | 20:23 |
| uvos | thats maemo-input-sounds | 20:23 |
| uvos | thats worked for quite some time | 20:23 |
| sicelo | i guess it's because my d4 acts up so much, so i hardly use Leste | 20:24 |
| uvos | it also depends on your profile | 20:25 |
| uvos | you may have them disabled | 20:25 |
| uvos | the woosh is tied to the click, wich i find really annoying | 20:25 |
| sicelo | actually it isn't tied to the click (i've always had clicks disabled) | 20:30 |
| uvos | it is if you just swich profiles | 20:31 |
| uvos | (as opposed to creating a custom one) | 20:31 |
| sicelo | it's in "System Sounds". just rechecked with my Fremantle N900. unless something's changed in Leste | 20:32 |
| uvos | yes thats correct | 20:32 |
| uvos | but theres just 2 default profiles 1 has both enabeled 1 both disabled | 20:32 |
| uvos | not that it really matters | 20:32 |
| sicelo | click is elsewhere ... Key Sounds and/or Touch Screen Sounds | 20:32 |
| uvos | as you can create your own | 20:32 |
| uvos | sicelo: right but we dont have that exact ui in leste | 20:33 |
| uvos | we just have profilesx | 20:33 |
| uvos | its in there | 20:33 |
| uvos | but you have to create a new profile | 20:33 |
| sicelo | alright. yeah i'm not familiar with profilesx | 20:33 |
| freemangordon | uvos: https://github.com/maemo-leste/hildon-desktop/commit/d248bbfc952f097587983c686c4a424feadd8923 | 22:40 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!