ventrical | goodmorning | 05:08 |
---|---|---|
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader | ||
om26er | How can I query from unity8 the display orientation outside of Qt/QML. | 12:36 |
=== marcusto_ is now known as marcustomlinson_ | ||
greyback | om26er: "outside of qt/qml?" <- I don't understand | 13:27 |
greyback | as a separate process? | 13:27 |
greyback | or are you using autopilot to introspect unity8? | 13:27 |
om26er | greyback, in python or bash | 13:27 |
om26er | or maybe some logs I can read ? | 13:28 |
greyback | om26er: I don't think there is an easy way right now. We've never had to support that function | 13:28 |
greyback | if you need, we can add a dbus interface to unity8 to give you that info | 13:29 |
greyback | but right now, I don't know of an obvious way to do that | 13:30 |
om26er | greyback_, yes, that would be really useful. How much work do you think that is ? | 13:34 |
greyback__ | om26er: not much really, 4 hours maybe, plus landing time. But you need to be specific, orientation is relative to what? (note that the M10 is always to complex case, as the lcd panel is portrait, but the UI defaults to landscape, so *something* is rotation the UI and the input events) | 13:58 |
greyback__ | we just need to be clear on what you're using the information for | 13:58 |
greyback__ | mzanetti: wdyt? om26er wants to fetch the current shell UI orientation for autopilot I guess | 13:59 |
* mzanetti reads scrollback | 13:59 | |
mzanetti | yeah... the question is why would you need that? unless you're writing a test that explicitly tests orientation things (which we already have in our test suite) I think you should not need that... it's just a different size of the window | 14:01 |
mzanetti | but maybe you have a use case for it that I am not aware of right now? | 14:01 |
greyback__ | dednick: just one thing: https://code.launchpad.net/~nick-dedekind/qtubuntu/menuTheme/+merge/296997/comments/795672 | 14:20 |
om26er | mzanetti, autopilot uses screen resolutions to check if an object is within the screen area. | 14:20 |
om26er | mzanetti, the X and Y can be different if its rotated. | 14:21 |
mzanetti | so? | 14:21 |
mzanetti | I mean, there's still a width and a height of the shell which defines the screen area | 14:21 |
om26er | mzanetti, so autopilot needs to know the current orientation to report X and Y accordingly | 14:21 |
mzanetti | hmm... | 14:22 |
mzanetti | no... doesn't line up here... the screen has a certain width and height. it doesn't matter what orientation... width and height might change at any point, but that doesn't change the fact that x and y needs to be within those | 14:23 |
mzanetti | hmm... I think I might know the issue | 14:24 |
mzanetti | where are you getting width and height from? | 14:24 |
mzanetti | om26er, ^ | 14:28 |
om26er | mzanetti, mirout | 14:28 |
mzanetti | right... | 14:29 |
mzanetti | now I understand the issue | 14:29 |
mzanetti | ok, I'd suggest to get width/height from the shell stuff | 14:29 |
mzanetti | I don't remember autopilot syntax | 14:29 |
om26er | mzanetti, is there a dbus interface for that ? | 14:29 |
mzanetti | you'd use the normal autopilot stuff | 14:30 |
mzanetti | how do you find an object by objectName again? | 14:30 |
mzanetti | well, find the object with the name "shell". Get width and height from that. it will be proper, taking orientation into account | 14:30 |
mzanetti | if you *really* need to know orientation (still discouraged for this task IMHO) then this object also has a orientation property | 14:31 |
mzanetti | om26er, does that work for you? | 14:31 |
om26er | mzanetti, I wouldn't want to get the proxy object of unity8 to query screen resolutions. that's a slow process | 14:33 |
om26er | mzanetti, autopilot does a recursive search on the dbus path of a process to get objectName | 14:34 |
mzanetti | om26er, oh well, can you than get the orientation from there for that one test you want to do now? | 14:38 |
mzanetti | s/from/for/ | 14:38 |
om26er | mzanetti, I am not working on a test. I am working on the autopilot tool itself to make it ready for convergence. Currently it keeps a hard-coded list of screen resolutions for different touch devices and does not work under a Mir desktop. | 14:39 |
om26er | there are some APIs in autopilot that rely on screen resolution. | 14:41 |
=== dandrader is now known as dandrader|afk | ||
bregma | om26er, by "screen resolution" do you mean display extents or do you mean pixel density? | 14:49 |
bregma | and does autopilot handle multiple displays with different extents and pixel densities? | 14:49 |
om26er | bregma, display pixels. extents, if you must. | 14:49 |
bregma | right, just making sure it's the same terminology everywhere | 14:50 |
bregma | so people don;t talk past one another | 14:50 |
om26er | bregma, for the Mir backend, autopilot currently does not support multiple displays, something that would need to be fixed before Unity8 is default on the desktop | 14:51 |
bregma | well, truthfully, Unity 8 also needs to be fixed to support that before it's the default on the desktop | 14:51 |
bregma | om26er, I think I'm going to want you in some of my sessions at the upcoming sprint | 14:52 |
om26er | bregma, sure | 14:55 |
=== dandrader|afk is now known as dandrader | ||
=== dpm is now known as dpm-afk | ||
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!