[13:11] <mterry> mzanetti: I assume you saw my note about session-lightdm -- just rip it out for now, not quite ready to land as is
[13:47] <mterry> mzanetti: where are we with the current silo?  (like how close to being done?)
[13:48] <mterry> 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] <mterry> minor issue  :)
[14:07] <mterry> mzanetti: we might want a rush order silo for the media-suggests change...
[14:22] <tsdgeos> pstolowski: do you do model updates from threads?
[14:22] <tsdgeos> from https://errors.ubuntu.com/problem/0168de360a9e17b6337e0304609320555b011747 it seems you do
[14:22] <tsdgeos> that's kind of dangerous last time i read aboutit
[14:25] <pstolowski> 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] <tsdgeos> pstolowski: see taht backtrace
[14:27] <tsdgeos> you're creating a QtConcurrent::run that calls beginResetModel
[14:30] <pstolowski> 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] <pstolowski> tsdgeos, indeed. that sounds like it's a problem.
[14:30] <tsdgeos> well the crash seems to disagree with you :D
[14:31] <tsdgeos> but maybe something else
[14:31] <tsdgeos> i agree
[14:32] <pstolowski> tsdgeos, we do use QtConcurrent to handle child scopes update & reset settings model in response
[15:04] <om26er> Hi! Is there a way to get unity8 pointer co-ordinates ?
[15:04] <om26er> I need that for autopilot where there is a need to do relative moves from the current position of the pointer.
[15:38] <greyback> om26er: nope, that ability is not possible currently. We'd need to add another dbus api for that
[15:38] <greyback> I'd question why relative moves are needed at all
[15:38] <greyback> AP moved the cursor, AP should know where it is, no?
[15:40] <om26er> 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] <om26er> 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] <om26er> so when the test is run for the first time, it won't know the position because there is no way.
[15:42] <greyback> om26er: can it not do an absolute move, and relative from then on?
[15:43] <om26er> 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] <om26er> lets say I move it to ABS position 0,0 first and then move to where I want it to be.
[15:45] <greyback> 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] <om26er> I'll try to use that approach as a stop-gap and see how it behaves
[15:46] <om26er> greyback, for abs move, the pointer does not show, as I said its for Touch
[15:46] <om26er> that's the approach we are currently using when our tests run on phones/tablets
[15:47] <greyback> if it is for touch, I don't understand why the pointer position is wanted at all
[15:48] <dandrader> 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] <dandrader> *tricky
[15:49] <om26er> greyback, I said absolute move is for touch and relative move is for Pointer (in the context of evdev)
[15:50] <greyback> om26er: ok, gotcha
[15:51] <om26er> 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] <greyback> but I still thought you could absolute move a pointer. Maybe not
[15:51] <greyback> (programmatically, not physically ofc)
[15:51] <dandrader> om26er, those are done by mir, using libinput, I think
[15:52] <dandrader> greyback, evdev is pretty lowlevel. it doesn't have a concept of pointer.
[15:53] <dandrader> greyback, just devices that generate relative_x and relative_y input events