=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
anpok | alan_g: tested your branch.. now looking at other window type placements.. | 08:42 |
---|---|---|
anpok | +it works.. | 08:42 |
anpok | for a tooltip .. the aux_rect() window specification parameter should be filled, shoudlnt it? | 08:43 |
anpok | I think that case is still wrong in the gdk backend. | 08:43 |
alan_g | @"for a tooltip" the aux_rect() should be used for placement | 08:46 |
alan_g | DId I answer your "needs info"? | 08:46 |
anpok | alan_g: I think what do not understand here is why window_info needs to be updated.. Is the WindowInfo object destroyed when the Window is hidden? | 09:02 |
anpok | Or is WindowInfo kept alive but not updated for some reason when the parent Window is moved around? | 09:03 |
alan_g | anpok: no... the restore_rect is only updated on state transitions. | 09:04 |
anpok | ah! | 09:05 |
alan_g | I think it will be clearer when I update the follow-up branch to fix other issues I found as a result. | 09:05 |
anpok | Now.. ok | 09:05 |
anpok | I thought you would be moving the location of WindowInfo to match the one of Window.. But instead you are preparing WindowInfo for the 'restore' step | 09:06 |
alan_g | Yep | 09:06 |
sil2100 | alf: ping | 09:29 |
duflu | sil2100: Paternity leave :) | 09:31 |
sil2100 | duflu: argh, damn, since he's the only admin of the new repowerd team ;/ | 09:32 |
sil2100 | duflu: thanks for the info | 09:32 |
sil2100 | duflu: do you know till when? | 09:32 |
duflu | Of course. That's how these things always go | 09:32 |
duflu | No I don't know | 09:32 |
alan_g | anpok: while you still remember gtk-mir... When running (e.g.) bin/miral-kiosk --startup gnome-terminal the terminal doesn't paint the full (fullscreen) surface. Is the fix trivial? | 09:36 |
anpok | hm miral-kiosk does not start up for me | 10:01 |
alan_g | Odd. Get an error? | 10:02 |
anpok | ah ok .. the startup or startup-apps does not work | 10:02 |
anpok | http://pastebin.ubuntu.com/19259936/ | 10:02 |
anpok | now it fails with: Error creating terminal: No screen 0 on display "Mir" | 10:04 |
alan_g | anpok: the pastebin looks like trying to start mesa-kms without root | 10:05 |
alan_g | Which is the same code that all the other Mir servers run. Kiosk isn't any different there | 10:05 |
anpok | so I did not manage to get gnome-terminal to start | 10:06 |
alan_g | anpok: gnome-terminal doesn't work as root (without fiddling). try running on X11 | 10:07 |
alan_g | Or... hack scripts/testrun to run kiosk | 10:08 |
anpok | oh i get a bunch of errors with radeonsi now.. | 10:13 |
anpok | so couldnt see it in action yet.. | 10:14 |
alan_g | nm was just a passing thought | 10:14 |
alan_g | anpok: another thought: did you fix this in your gtk-mir travels? lp:1445543 | 10:16 |
=== chihchun is now known as chihchun_afk | ||
=== hikiko is now known as hikiko|ln | ||
=== chihchun_afk is now known as chihchun | ||
bregma | sil2100, alf is gone at least two weeks, supposed to be back 2016.08.02 | 11:23 |
bregma | sil2100, I'm sure canonical IS can probably do something if there's an emergency.... | 11:24 |
=== hikiko|ln is now known as hikiko | ||
anpok | alan_g: something worth trying | 12:00 |
=== chihchun is now known as chihchun_afk | ||
anpok | alan_g: still exists.. the input event reaches gdk.. from then on it is a bit unclear. | 12:20 |
alan_g | anpok: thanks for checking | 12:57 |
anpok | hmm or actually I did not check whether the event reaches the right surface.. | 12:59 |
anpok | Now looking at a ci issue with the nested input device state event tests I added recently.. | 12:59 |
anpok | alan_g: the way that window looks it seems to not receive keyboard focus.. maybe it got mapped to a window type not allowed to receive user input? | 13:02 |
anpok | alan_g: do we have something in scene report showing that? | 13:03 |
alan_g | anpok: I suspect not (yet) | 13:03 |
=== dandrader is now known as dandrader|afk | ||
=== chihchun_afk is now known as chihchun | ||
=== dandrader|afk is now known as dandrader | ||
=== dandrader is now known as dandrader|afk | ||
=== chihchun is now known as chihchun_afk | ||
=== dandrader|afk is now known as dandrader | ||
=== 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!