| === safetypeaches is now known as Guest82846 | ||
| === marcusto_ is now known as marcustomlinson | ||
| === dandrader is now known as dandrader|afk | ||
| 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:11 |
|---|---|---|
| === Guest82846 is now known as peaches | ||
| mterry | mzanetti: where are we with the current silo? (like how close to being done?) | 13:47 |
| 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 |
| ubot5 | 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 |
| mterry | minor issue :) | 13:48 |
| === dandrader_ is now known as dandrader | ||
| mterry | mzanetti: we might want a rush order silo for the media-suggests change... | 14:07 |
| 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:22 |
| 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:25 |
| tsdgeos | pstolowski: see taht backtrace | 14:26 |
| tsdgeos | you're creating a QtConcurrent::run that calls beginResetModel | 14:27 |
| 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:30 |
| tsdgeos | but maybe something else | 14:31 |
| tsdgeos | i agree | 14:31 |
| pstolowski | tsdgeos, we do use QtConcurrent to handle child scopes update & reset settings model in response | 14:32 |
| 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:04 |
| === om26er is now known as om26er1 | ||
| === om26er1 is now known as om26er | ||
| 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:38 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:45 |
| 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:46 |
| greyback | if it is for touch, I don't understand why the pointer position is wanted at all | 15:47 |
| 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:48 |
| om26er | greyback, I said absolute move is for touch and relative move is for Pointer (in the context of evdev) | 15:49 |
| greyback | om26er: ok, gotcha | 15:50 |
| 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:51 |
| dandrader | greyback, evdev is pretty lowlevel. it doesn't have a concept of pointer. | 15:52 |
| dandrader | greyback, just devices that generate relative_x and relative_y input events | 15:53 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!