[09:14] <tsdgeos> mzanetti: any idea what this is? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1329141
[09:14] <tsdgeos> it's still New on our side
[09:14] <tsdgeos> and marked as lt-blocker
[09:15] <mzanetti> looking
[12:38] <dandrader> mzanetti, do you know what's Qt's definition of "physical pixel" and "device-independend pixel"?
[12:39] <mzanetti> dandrader, not sure I get the question
[12:39] <mzanetti> device-independent pixel = physical pixel * QT_DEVICE_PIXEL_RATIO
[12:40] <dandrader> mzanetti, the actual pixels in a bitmap hold by a QImage, are they physical pixels or device-independent pixels?
[12:40] <mzanetti> device-independent. however, if you don't export QT_DEVICE_PIXEL_RATIO it'll be the same
[12:40] <mzanetti> on Mir we'll also use GRID_UNIT_PX to modify the value
[12:41] <greyback> dandrader: you've seen http://doc.qt.io/qt-5/highdpi.html ?
[12:41] <dandrader> mzanetti, so it doesn't match this definition: https://en.wikipedia.org/wiki/Device_independent_pixel
[12:41] <dandrader> greyback, no
[12:41] <greyback> dandrader: no it doesn't, Qt's interpretation doesn't relate to any physical measurement
[12:42] <greyback> dandrader: it's really just a scaling factor for the UI
[12:42] <mzanetti> well, the distribution/device manufacturer needs to relate it to a physical measurement by exporting the correct QT_DEVICE_PIXEL_RATIO var
[12:42] <mzanetti> which are aren't :D
[12:43] <greyback> exactly
[12:43] <mzanetti> given that the physical measurement differs quite a lot between our devices
[12:43] <greyback> we're not guaranteeing that 1GU is 0.5cm or anything like that
[12:43] <mzanetti> I think we wanted to... but then we decided to change it to be display width / 40
[12:43] <dandrader> "3840x2160 pixels, resulting in a logical resolution of 192 DPI, whereas older monitors have around 1920x1080 pixels at 96 DPI." <- how can it tell de DPI without know how big (in mm) the display is?
[12:44] <dandrader> maybe I should check the definition of "logical resolution" ....
[12:44] <mzanetti> you can't but not sure if you even should
[12:45] <greyback> dandrader: don't get too bogged down in the terminology, I think it's all a bit messy/inconsistent. We're not reviewing Qt's decision here
[12:46] <mzanetti> dandrader, when it comes to unity, you should probably just use grid units and that's it
[13:06] <dandrader> mzanetti, didn't Saviq come up with a solution for this "can't merge new features while vivid is frozen" issue?
[13:06] <Saviq> dandrader, we did, and then they froze the solution, too ;)
[13:06] <dandrader> :D
[13:07] <mzanetti> dandrader, I added a branch that "fixes" the dialer
[13:07] <dandrader> mzanetti, I saw that and even filled in its description
[13:08] <mzanetti> right... had to run to a meeting
[13:31] <seb128> does anyone know what component/sourcecode has the "message" button from the messaging menu?
[13:32] <seb128> unping
[13:32] <seb128> just found it
[13:54] <dandrader> greyback, how do you test the DPR stuff?
[13:54] <greyback> dandrader: for the qtubuntu stuff, I use mir_proving_server
[13:56] <greyback> I usually try a simple enough qml file
[13:56] <greyback> and maybe a qt demo or two
[13:57] <greyback> note that QT_DEVICE_PIXEL_RATIO also works on X11, so you can try those same demos on your desktop and compare
[15:24] <dandrader> greyback, who uses this DBus window stack from qtmir?
[15:24] <tsdgeos> hud did
[15:24] <tsdgeos> i guess noone does now
[15:25] <greyback> dandrader: hud isn't dead, this it still available
[15:25] <tsdgeos> it's a long time zombie :D
[15:25] <dandrader> greyback, what do you mean by "available"? I can get it on the phone?
[15:25] <tsdgeos> but i guess we should bring it back for the desktop
[15:25] <tsdgeos> at lesat
[15:27] <greyback> dandrader: it used to be still running (sdk apps used to need it for something), but I don't see it there any more. libhud2 is being installed still.
[15:27] <dandrader> greyback, it seems to belong to unity8, not qtmir, what do you think?
[15:28] <greyback> dandrader: probably
[15:28] <greyback> dandrader: depends on how we want the desktop to work. Would you like to export a dbus api to allow third party apps to manipulate windows? I'm tempted to
[15:29] <dandrader> greyback, I don't know. what's the use case?
[15:30] <greyback> dandrader: third party docks - like AWN or cairo dock
[15:32] <greyback> autopilot would be interested in that stuff too
[15:32] <greyback> as would anyone who uses xwininfo/xdotool
[15:33] <greyback> and using apparmor to police it
[15:33] <greyback> just a proposition
[15:34] <dandrader> greyback, but it has the concept of focused window, which qtmir won't know about in the future. that's the biggest push for having it in unity8
[15:35] <greyback> dandrader: qtmir has to know a bit about focus, to tell the client "your window is focused"
[15:36] <dandrader> greyback, it gets it from the QQuickItem API of MirSurfaceItem
[15:37] <dandrader> greyback, namely QQuickItem::activeFocus
[15:37] <greyback> dandrader: I know
[15:37] <greyback> so qtmir needs to know that. So qtmir can export that data via dbus
[15:38] <greyback> I've not decided if that dbus stuff should be in unity8 or not. Having it qtmir means any shell written using it will have the same dbus api
[15:38] <greyback> perhaps its own library
[15:39] <dandrader> ok, will leave it alone then :)
[15:39] <greyback> for now, please do :)
[15:39] <greyback> let's discuss it at the sprint
[15:40]  * greyback took a note
[20:44] <mhall119> tedg: still need that email when you get the chance
[22:45] <sidi> How can you set breakpoints on Unity's code? I've built it, run it with advanced-debug, but gdb can't put breakpoints on fn names, seems to be attached to compiz.
[22:48] <sidi> also is there any way to access the Application behind a window? especially, from the DecoratedWindow object? or at least the app's PID without having to go through xdotools?