Livio has quit [Ping timeout: 256 seconds]
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 256 seconds]
macros_ has joined #maemo-leste
mardy has joined #maemo-leste
<freemangordon> Wizzup: we can't avoid
Twig has joined #maemo-leste
<freemangordon> sicelo: while I agree to some extend, how useful would be to display a link that cannot be clicked?
<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
<freemangordon> yeah, but specs say we shall remove it :(
<freemangordon> it is confusing
<sicelo> i have just read that link. if i understand it correctly, it's saying to strip the tag (not the text)
<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. "
<sicelo> what it's saying sounds exactly like in the example i gave above
<freemangordon> ok, unless someone objects I will implement it as you say
<sicelo> and yes, this means no parsing, unless i misunderstand. basically you find '<' ... skip everything until you reach '>'. done
<freemangordon> no, I must parse
<freemangordon> as I want to support <b> <i> etc
<freemangordon> but not <a> and <img>
<sicelo> ah, ok :-)
<freemangordon> it is not a biggie
<freemangordon> I am using GMarkupParser, which is said to be lightweight parser
<sicelo> back to that sentence a bit: text is 'content', so the sentence indicates that content shall not be touched
<freemangordon> ok
<freemangordon> I will display links as blue underlined text
<freemangordon> someday we may even want to support click on that as well
Pali has joined #maemo-leste
Twig has quit [Ping timeout: 256 seconds]
<Wizzup> let's hope this doesn't introduce exploits throught notification :D
Pali has quit [Ping timeout: 256 seconds]
<freemangordon> it shouldn't :)
<freemangordon> hmm, it seems libnotify assumes that timeout 0 means persistent notification
<freemangordon> but h-h looks for 'persistent' hint
<freemangordon> I wonder what 'persistent' with non-zero timeout would be
uvos has joined #maemo-leste
<uvos> "<freemangordon> I wonder what 'persistent' with non-zero timeout would be"
<uvos> most notification servers have a global que
<uvos> probubly this means to show the notification for timeout and then put it into the (usually hidden untill the user clicks) que
<uvos> but ill test that theory on kde and lxqt in a sec
<freemangordon> uvos: could be, but still, if this is persistent across reboots, I wonder how actions shall be implemented then
<freemangordon> as those are dbus callbacks
<uvos> none of the notifications are presistant across reboots
<uvos> or restarts of the server
<freemangordon> hmm
<uvos> as far as i can tell
<freemangordon> well, we support that :)
<uvos> well as you note
<uvos> it cant really work
<freemangordon> i can, as soon as there are no actions involved
<uvos> sure you can have grayed out notifications
<uvos> or something
<freemangordon> also, for example conversations or call-ui can listen to dbus and activate themselves
<uvos> clearly a uninteneded hack
<freemangordon> TBH I cannot find a single user in fremantle that sets "persistent" property
<freemangordon> ok, so it seems we do not support persistence then (in terms of specs)
<Wizzup> doesn't seem like a big deal atm?
<freemangordon> sure no
<freemangordon> I am just trying to figure out what we support and what not
<freemangordon> to properly report to clients
<uvos> probubly usefull for pressistance to exist
<uvos> for instance for a mute button
<Wizzup> I think for that we might want some notifications window or status applet
<Wizzup> but it doesn't seem quite essential now in any case ;)
<uvos> as a global que yeah eventually
<freemangordon> yeah, some status bar applet
<uvos> i dont see how my gf could survive if every notification has its own window :P
<freemangordon> no, it is not like that
<freemangordon> h-h supports threadung and category
<freemangordon> so notifications gets grouped
<freemangordon> don;t ask me how, but the code is tehre
<uvos> the dekstop notification spec if seams to create a new window for every call
<freemangordon> no
<uvos> hmm it dosent work then
<freemangordon> well, it depends on how you use that
<freemangordon> you should set the hints correctly
<uvos> what hints?
<uvos> are thes mameo specific
* freemangordon checks
<uvos> the dekstop apps that do work with the if atm
<uvos> spamm lots of windows
<uvos> like if i download 10 podcasts via gpodder
<uvos> ill get 10 windows with the compleate notification
<uvos> really annoying
<freemangordon> you should figure out how this work though
<freemangordon> maybe tehre is documentation
<uvos> this dosent help tho
<uvos> since no desktop app will ever set those
<freemangordon> seems you are nto the only one :p
<uvos> so is hd_notification_get_category set via class specific prop on the dbus call?
<freemangordon> but, at least it seems possible :)
<freemangordon> IIUC 'category' hint is another story
<uvos> ok
<uvos> well thats not really great then
<freemangordon> this is about grouping based on WM_CLASS of the application
<freemangordon> lemme check how it is on fremantle
<uvos> how dose it do that?
<uvos> query on the pid?
<uvos> to find x windows?
<freemangordon> maybe, I haven't looked at the code
<uvos> dont see how else it could work
<uvos> that sounds... farily horrible
<freemangordon> well, tasknav already does that either ways
<freemangordon> it already "adopts" X windows
<freemangordon> so not really an issue
<uvos> sure its an issue, it breaks lots of things
<uvos> xwindows of a "applicaiton" dont even have to be in the same pid
<uvos> for starters
<freemangordon> no, because that's how application thumbnail is shown in tasknav
<uvos> or set that pid
<uvos> ?
<freemangordon> does not matter, it is about the window class, not the PID
<uvos> yeah but to get to the window class
<uvos> you need a xwindow
<freemangordon> and you already have it
<uvos> to get the window from the dbus call
<freemangordon> in hildon-desktop
<freemangordon> no,no
<uvos> you need to check what pid owns what window
<freemangordon> you don;t care about dus call
<freemangordon> why do you care?
<uvos> how do you correlate the window with the notification (to get WM_CLASS)
<uvos> ?
<freemangordon> anyway, lemme see what this file contains in fremantle
<uvos> you have to correlate the dbus call with a xwindow somehow
<freemangordon> dunno
<freemangordon> look at the code
<uvos> right the only way to do so is via pid
<uvos> and thats horrible
<freemangordon> no, it seems it uses "category" from dbus call
<freemangordon> and maps that category via the config file to know which WM_CLASS to use
<uvos> ok then thats fine
<freemangordon> that's what I saw from a quick glance
<uvos> still i dont think mutch sets this
<freemangordon> well...
<uvos> ill try some more stuff
<freemangordon> see notification_get_group()
<freemangordon> ugh...
<freemangordon> uvos: https://pastebin.com/4NLthG6h
<freemangordon> :)
<freemangordon> what is missing here is .d, but I guess we can easily add that
<uvos> ugh thats farily horrific no
<freemangordon> no, why horrific?
<freemangordon> it is fairly configurable and if we miss something... well
<freemangordon> we can add it
<uvos> ? a config file with destinations
<uvos> hows that not horrific
<freemangordon> we can replace with mime type
<uvos> it breaks pretty mutch everything
<freemangordon> and xdg_open
<uvos> thats still broken
<uvos> what about actions?
<freemangordon> there is only "default" action. fullstop :)
<uvos> xdg_open ing soemthing is not the same as triggering an action
<uvos> default action and xdg_open are not the same
<freemangordon> agree
<freemangordon> but, I don;t think "destination" is mandatory
<freemangordon> so actions will still execute
<freemangordon> well, "default" action
<uvos> its still terrible, your essentaly "hardcodeing" special behavior for some blessed apps
<freemangordon> anyway, lemme push what I have done so far
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
<uvos> looks ok
<uvos> ill test later today
<freemangordon> hmm, lemme force-push fix for one possible memleak
<freemangordon> uvos: done
<Wizzup> freemangordon: ok with putting osso-addressbook in stable / meta pkg?
<freemangordon> sure
<freemangordon> it lacks some stuff, and has at least one issue (segfault I can no longer repro now gtalk does not work), but otherwise...
<Wizzup> there's the thing with telepathy-haze and slack where everyone is (no name)
<Wizzup> but I think that is for later :)
Livio has quit [Ping timeout: 256 seconds]
pere has quit [Ping timeout: 256 seconds]
<freemangordon> yeah
noidea__ has quit [Quit: Leaving]
<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
noidea_ has joined #maemo-leste
<freemangordon> mighty17[m]: I guess no
<freemangordon> but, you'd better just use mesa from repos
pere has joined #maemo-leste
<mighty17[m]> yup there's no need for it
<mighty17[m]> tested with phosh :D
pere has quit [Ping timeout: 248 seconds]
<mighty17[m]> freemangordon: we dont have EXT_read_format_bgra working right?
<freemangordon> why is that?
<freemangordon> well, check with eglinfo
<freemangordon> or es2_info
<mighty17[m]> in a sec
pere has joined #maemo-leste
<mighty17[m]> freemangordon: nope, we do not
<freemangordon> EXT_read_format_bgra is same as GL_IMG_read_format?
<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`
<mighty17[m]> `GL_EXT_read_format_bgra, GL_NV_pack_subimage, GL_EXT_frag_depth,`
<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`
<freemangordon> hmm, seems like a bug
<freemangordon> which mesa is that?
<mighty17[m]> from maemo-leste-upstream-forks
<freemangordon> ok
* freemangordon boots d4
<freemangordon> mighty17[m]: hmm, this is DRM or WL or X11?
<freemangordon> I guess X11
<freemangordon> but you want DRM
<mighty17[m]> WL
<mighty17[m]> as in the error is from wl....
<freemangordon> yes, but renderer is drm, afaik
<mighty17[m]> right
<freemangordon> sec (phone call)
<freemangordon> hmm, is it?
<freemangordon> DISPLAY=:0 does not look like DRM
<mighty17[m]> thats just me doing it from ssh
<freemangordon> still, you ask for x11 platform capabilities
<freemangordon> not for GBM platform
<mighty17[m]> hm? im a bit lost
<freemangordon> there are 3 platforms that have different extensions: GBM (or drm), X11 and WL
<freemangordon> which renderer does wlroots use?
<freemangordon> DRM or X11?
<mighty17[m]> wayland
<freemangordon> no, there is no such renderer, unless I am missing something
<freemangordon> or was it backend?
* freemangordon checks
<mighty17[m]> hm im confused
<freemangordon> wait a sec
<mighty17[m]> i suppose its drm
<freemangordon> see https://pastebin.com/KYTYZkeh
<freemangordon> no GL_EXT_read_format_bgra
<freemangordon> this is for DRM backend
<mighty17[m]> hmm, then adding it should be as simple as reusing IMG_read_format ?
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
<mighty17[m]> <mighty17[m]> "https://github.com/tmlind/..."; <- this commit did work magically
<freemangordon> better ask tmlind about it
<freemangordon> #define GL_BGRA_EXT 0x80E1
<freemangordon> #define GL_BGRA_IMG 0x80E1
<freemangordon> I think it should be a little more clever
<mighty17[m]> maybe it isnt who knows
<mighty17[m]> but fair point
<freemangordon> hmm, no, seems those are interchangeable
<freemangordon> besides that GL_EXT_read_format_bgra can return UNSIGNED_SHORT_1_5_5_5_REV_EXT in theory
<freemangordon> so it is a superset of GL_IMG_read_format
pere has quit [Ping timeout: 252 seconds]
<freemangordon> mighty17[m]: you may want to fix that in pvr driver and make a PR
<mighty17[m]> freemangordon: Pvr driver? Wdym mesa or blobs?
<freemangordon> mesa
<mighty17[m]> <freemangordon> "besides that GL_EXT_read_format_..." <- Ah then it should work by just interchanging :D
<mighty17[m]> freemangordon: Me has no clue how🥲
<freemangordon> intercept eglQueryString and append GL_EXT_read_format_bgra to the list
<freemangordon> ok, I may do that someday
pere has joined #maemo-leste
xmn has joined #maemo-leste
<mighty17[m]> I'll look into it later this week then
<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
<uvos> i would have expected that to not matter if the entire display is changed
<Wizzup> well that depends on if it's also reloading the bg no?
<uvos> the bg also moves
<uvos> was it redrawing the window pixmaps too?
<uvos> ie updateing the textures
<uvos> btw maybe we could fix the tasknav animation in portrait
<uvos> its a bit of a pet peeve of mine (i can also try some time)
dev has joined #maemo-leste
<freemangordon> uvos: the big difference is that it does not re-upload the whole buffer every frame
<freemangordon> that's what enunes' hack was doing
<freemangordon> umm, what is wrong with tasknav animation?
<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
<freemangordon> is that visible in the ^^^ video?
<uvos> yeah
<uvos> 2:45
<uvos> it looks like the center point of the animation dosent change for protrait
<uvos> while the center of the display obv dose
<uvos> just a minor visual glitch
<freemangordon> hmm, I guess I can change transitions.ini to make that animation last few seconds
* freemangordon boots PP
<uvos> its visible on all devices btw
<uvos> not pp specific
<freemangordon> ok
<freemangordon> tasknav is my pet for the last couple of years :)
<freemangordon> so I will fix that when I find some spare time
<uvos> then you probubly know where to look
<freemangordon> shoudl be an easy fix
<freemangordon> yeah
<freemangordon> though I see nothing @ 2:45
<freemangordon> oh, right
<freemangordon> now I see
noidea_ has quit [Remote host closed the connection]
noidea_ has joined #maemo-leste
Twig has joined #maemo-leste
vagag has joined #maemo-leste
<sicelo> lovely 'woosh' sounds. have we had them all along, or they're new to Leste?
<freemangordon> sicelo: audio was not working :)
<freemangordon> or, if you mean "do we have it in fremantle?", yes, we have them
Pali has joined #maemo-leste
parazyd has quit [Ping timeout: 252 seconds]
<sicelo> i meant in Leste. i recall a day or two ago Wizzup said something about importing certain sounds. or those were ringtones only
parazyd has joined #maemo-leste
<Wizzup> it wasn't added to any meta pkg yet
<uvos> the woosh sounds have been there all alonge
<uvos> thats maemo-input-sounds
<uvos> thats worked for quite some time
<sicelo> i guess it's because my d4 acts up so much, so i hardly use Leste
<uvos> it also depends on your profile
<uvos> you may have them disabled
<uvos> the woosh is tied to the click, wich i find really annoying
<sicelo> actually it isn't tied to the click (i've always had clicks disabled)
mardy has quit [Quit: WeeChat 2.8]
<uvos> it is if you just swich profiles
<uvos> (as opposed to creating a custom one)
<sicelo> it's in "System Sounds". just rechecked with my Fremantle N900. unless something's changed in Leste
<uvos> yes thats correct
<uvos> but theres just 2 default profiles 1 has both enabeled 1 both disabled
<uvos> not that it really matters
<sicelo> click is elsewhere ... Key Sounds and/or Touch Screen Sounds
<uvos> as you can create your own
<uvos> sicelo: right but we dont have that exact ui in leste
<uvos> we just have profilesx
<uvos> its in there
<uvos> but you have to create a new profile
<sicelo> alright. yeah i'm not familiar with profilesx
xmn has quit [Quit: xmn]
Twig has quit [Ping timeout: 248 seconds]
vagag has left #maemo-leste [Error from remote client]
xmn has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
uvos has quit [Ping timeout: 268 seconds]
Livio has quit [Ping timeout: 248 seconds]
Pali has quit [Ping timeout: 268 seconds]