=== Malsasa_ is now known as Malsasa === Malsasa is now known as Guest71156 === Malsasa_ is now known as Malsasa === anpok_ is now known as anpok === JMulholland_ is now known as JMulholland [09:14] mzanetti: any idea what this is? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1329141 [09:14] Ubuntu bug 1329141 in unity8 (Ubuntu) "Two underscores in .desktop file name causes assumption that this is an appId and app is rejected." [Undecided,New] [09:14] it's still New on our side [09:14] and marked as lt-blocker [09:15] looking === alan_g is now known as alan_g|lunch === MacSlow is now known as MacSlow|lunch [12:38] mzanetti, do you know what's Qt's definition of "physical pixel" and "device-independend pixel"? [12:39] dandrader, not sure I get the question [12:39] device-independent pixel = physical pixel * QT_DEVICE_PIXEL_RATIO [12:40] mzanetti, the actual pixels in a bitmap hold by a QImage, are they physical pixels or device-independent pixels? [12:40] device-independent. however, if you don't export QT_DEVICE_PIXEL_RATIO it'll be the same [12:40] on Mir we'll also use GRID_UNIT_PX to modify the value [12:41] dandrader: you've seen http://doc.qt.io/qt-5/highdpi.html ? [12:41] mzanetti, so it doesn't match this definition: https://en.wikipedia.org/wiki/Device_independent_pixel [12:41] greyback, no [12:41] dandrader: no it doesn't, Qt's interpretation doesn't relate to any physical measurement === MacSlow|lunch is now known as MacSlow [12:42] dandrader: it's really just a scaling factor for the UI [12:42] well, the distribution/device manufacturer needs to relate it to a physical measurement by exporting the correct QT_DEVICE_PIXEL_RATIO var [12:42] which are aren't :D [12:43] exactly [12:43] given that the physical measurement differs quite a lot between our devices [12:43] we're not guaranteeing that 1GU is 0.5cm or anything like that [12:43] I think we wanted to... but then we decided to change it to be display width / 40 [12:43] "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] maybe I should check the definition of "logical resolution" .... [12:44] you can't but not sure if you even should [12:45] 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] dandrader, when it comes to unity, you should probably just use grid units and that's it === alan_g|lunch is now known as alan_g [13:06] mzanetti, didn't Saviq come up with a solution for this "can't merge new features while vivid is frozen" issue? [13:06] dandrader, we did, and then they froze the solution, too ;) [13:06] :D [13:07] dandrader, I added a branch that "fixes" the dialer [13:07] mzanetti, I saw that and even filled in its description [13:08] right... had to run to a meeting [13:31] does anyone know what component/sourcecode has the "message" button from the messaging menu? [13:32] unping [13:32] just found it [13:54] greyback, how do you test the DPR stuff? [13:54] dandrader: for the qtubuntu stuff, I use mir_proving_server [13:56] I usually try a simple enough qml file [13:56] and maybe a qt demo or two [13:57] note that QT_DEVICE_PIXEL_RATIO also works on X11, so you can try those same demos on your desktop and compare === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [15:24] greyback, who uses this DBus window stack from qtmir? [15:24] hud did [15:24] i guess noone does now [15:25] dandrader: hud isn't dead, this it still available [15:25] it's a long time zombie :D [15:25] greyback, what do you mean by "available"? I can get it on the phone? [15:25] but i guess we should bring it back for the desktop [15:25] at lesat [15:27] 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] greyback, it seems to belong to unity8, not qtmir, what do you think? [15:28] dandrader: probably [15:28] 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] greyback, I don't know. what's the use case? [15:30] dandrader: third party docks - like AWN or cairo dock [15:32] autopilot would be interested in that stuff too [15:32] as would anyone who uses xwininfo/xdotool [15:33] and using apparmor to police it [15:33] just a proposition [15:34] 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] dandrader: qtmir has to know a bit about focus, to tell the client "your window is focused" [15:36] greyback, it gets it from the QQuickItem API of MirSurfaceItem [15:37] greyback, namely QQuickItem::activeFocus [15:37] dandrader: I know [15:37] so qtmir needs to know that. So qtmir can export that data via dbus [15:38] 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] perhaps its own library [15:39] ok, will leave it alone then :) [15:39] for now, please do :) [15:39] let's discuss it at the sprint [15:40] * greyback took a note === Malsasa is now known as Guest99529 === Malsasa_ is now known as Malsasa === dandrader is now known as dandrader|lunch === alan_g is now known as alan_g|EOD === dandrader|lunch is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [20:44] tedg: still need that email when you get the chance [22:45] 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] 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?