=== safetypeaches is now known as Guest82846 === marcusto_ is now known as marcustomlinson === dandrader is now known as dandrader|afk [13:11] mzanetti: I assume you saw my note about session-lightdm -- just rip it out for now, not quite ready to land as is === Guest82846 is now known as peaches [13:47] mzanetti: where are we with the current silo? (like how close to being done?) [13:48] I have a fix I'd like to add (for bug 1629009) -- the only problem is I'm not done finding the right fix [13:48] bug 1629009 in webbrowser-app (Ubuntu) "Does not work inside a snap due to hardcoded paths" [High,In progress] https://launchpad.net/bugs/1629009 [13:48] minor issue :) === dandrader_ is now known as dandrader [14:07] mzanetti: we might want a rush order silo for the media-suggests change... [14:22] pstolowski: do you do model updates from threads? [14:22] from https://errors.ubuntu.com/problem/0168de360a9e17b6337e0304609320555b011747 it seems you do [14:22] that's kind of dangerous last time i read aboutit [14:25] tsdgeos, unlikely. we do receive results from scope listener in a thread, yes, but then they are pushed to the main loop via custom qevent and applied to the model there [14:26] pstolowski: see taht backtrace [14:27] you're creating a QtConcurrent::run that calls beginResetModel [14:30] tsdgeos, ah, but this is for settings model, not search results model (my bad, you didn't say which one and I assumed wrong) [14:30] tsdgeos, indeed. that sounds like it's a problem. [14:30] well the crash seems to disagree with you :D [14:31] but maybe something else [14:31] i agree [14:32] tsdgeos, we do use QtConcurrent to handle child scopes update & reset settings model in response [15:04] Hi! Is there a way to get unity8 pointer co-ordinates ? [15:04] I need that for autopilot where there is a need to do relative moves from the current position of the pointer. === om26er is now known as om26er1 === om26er1 is now known as om26er [15:38] om26er: nope, that ability is not possible currently. We'd need to add another dbus api for that [15:38] I'd question why relative moves are needed at all [15:38] AP moved the cursor, AP should know where it is, no? [15:40] greyback, Its complex than that, AP uses evdev, and evdev supports two modes relative and absolute(good for touch where you don't need to see the pointer). [15:41] in relative mode we need to give new co-ordinate relative to current position. So to reply to your initial question, autopilot does not initially know where the mouse is, it however does keep a track of last known position. [15:42] so when the test is run for the first time, it won't know the position because there is no way. [15:42] om26er: can it not do an absolute move, and relative from then on? [15:43] sounds hackish, could work but the mouse won't start moving from where it is, rather would move from a hard-coded position, always. [15:45] lets say I move it to ABS position 0,0 first and then move to where I want it to be. [15:45] why hardcoded? You can calculate the position that the move is going to start. Absolute move the cursor to that spot. Then relative move from then on [15:45] I'll try to use that approach as a stop-gap and see how it behaves [15:46] greyback, for abs move, the pointer does not show, as I said its for Touch [15:46] that's the approach we are currently using when our tests run on phones/tablets [15:47] if it is for touch, I don't understand why the pointer position is wanted at all [15:48] om26er, using evdev relative events to position unity8 cursor exactly where you want might be trick. there are settings like pointer acceleration and speed you would have to consider I think [15:48] *tricky [15:49] greyback, I said absolute move is for touch and relative move is for Pointer (in the context of evdev) [15:50] om26er: ok, gotcha [15:51] dandrader, hmm, their docs don't seem to mention that, thanks for the heads up, will take deeper look once I actually implement the moving pointer [15:51] but I still thought you could absolute move a pointer. Maybe not [15:51] (programmatically, not physically ofc) [15:51] om26er, those are done by mir, using libinput, I think [15:52] greyback, evdev is pretty lowlevel. it doesn't have a concept of pointer. [15:53] greyback, just devices that generate relative_x and relative_y input events === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === peaches is now known as Guest68911 === Guest68911 is now known as safetypeaches === safetypeaches is now known as peaches === peaches is now known as peaches|work === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === peaches|work is now known as peaches