| === c74d is now known as Guest21388 | ||
| === ara is now known as Guest22932 | ||
| === c74d is now known as Guest61567 | ||
| === chrisccoulson_ is now known as chrisccoulson | ||
| === greyback__ is now known as greyback | ||
| mpt | So, here’s a puzzle | 13:46 |
|---|---|---|
| mpt | Let’s say Mir is responsible for docking windows (like docking Inkscape’s palettes inside its document windows) | 13:46 |
| mpt | So that the window decorations can be consistent regardless of whether a window is docked or not | 13:47 |
| mpt | What if the app puts the dockable windows inside a scrolling pane in its window (as in Inkscape)? How would the app represent the scrolling pane to Mir? | 13:48 |
| greyback | mpt: is there an app that does that already? | 13:53 |
| mpt | greyback, you mean, besides Inkscape? | 13:54 |
| greyback | mpt: ah, I misread you, sorry. | 13:54 |
| greyback | I'd need to check, but I suspect in that case, the actual dockable window is destroyed, and everyting it contained was reparented inside the scrollable pane of the main window | 13:55 |
| mpt | Yes, LibreOffice | 13:55 |
| greyback | I don't see how else it would work, say if you scroll that pane so part of the "dockable window" is occluded - it would be horribly complex to try telling the compositor to only draw the bottom bit of that dockable window | 13:56 |
| mpt | I think one pleasant side-effect of handling docking in Mir is supposed to be that the app doesn’t have to destroy and recreate everything | 13:56 |
| greyback | mpt: if it wants to integrate the contents of that dockable window into the main UI, it's probably easier just to reparent, than trying to reposition a child window | 13:57 |
| mpt | That makes sense to me — especially if the docked window has to (for example) get wider | 13:58 |
| mpt | But Mir would still need to handle the clipping case so that it can render the docked window’s window controls | 13:59 |
| mpt | If it isn’t doing *that*, then there’s no point in Mir handling docked windows at all, that I can see. | 13:59 |
| mpt | The original problem to be solved is that the title bars of docked palettes in (for example) LibreOffice vs. Inkscape are gratuitously inconsistent. | 14:01 |
| greyback | mpt: to solve that issue, could have the app use freestyle surfaces for palettes and draw their own decoration, so it matches | 14:09 |
| greyback | just an idea | 14:10 |
| mpt | greyback, yes, that would make LibreOffice’s docked vs. undocked palette consistent. But it wouldn’t make LibreOffice’s undocked palette consistent with Inkscape’s or any other app’s. | 14:32 |
| greyback | mpt: true, but while docked, they are not windows any more, they are widgets drawn as part of the main window. In that situation, how they draw a "decoration" is up to them, not mir. So only way to make them consistent is to patch those apps | 14:42 |
| mpt | greyback, I think “how they draw a ‘decoration’ is up to them” is the problem to be solved. Because if it is up to the app, I can’t see how they could possibly do it in a way that won’t get out of date as soon as the OS theme changes. | 14:46 |
| greyback | mpt: yeah. We could offer a widget to app devs for decorations, one that we can theme as we wish. Could also be used by apps which want to draw their own decoration too, but then will customize it (e.g. chromium). | 14:49 |
| mpt | That might work better, yes | 14:52 |
| mpt | It seems to me that docked windows have custom controls in their “title bars” much more often than undocked windows do, too | 14:53 |
| mpt | (which is why Inkscape’s undocked windows have two title bars each, for example) | 14:56 |
| seb128 | hum, bug #1445542 ... is mir/unity8 handling multiple surfaces now? | 16:39 |
| ubot5 | bug 1445542 in gtk+3.0 (Ubuntu) "Using the Mir backend, secondary windows of GTK apps open behind the primary window" [Undecided,New] https://launchpad.net/bugs/1445542 | 16:39 |
| seb128 | greyback, ^ | 16:39 |
| greyback | seb128: mir/unity8 not handling separate surfaces still | 16:39 |
| seb128 | greyback, can you comment on that bug? means the gtk part is invalid? | 16:40 |
| greyback | seb128: hmm duflu marked gtk as affected, he's testing with stock mir, not qtmir/unity8 | 16:42 |
| seb128 | greyback, oh ok, so maybe different issues | 16:42 |
| greyback | yeah, I suspect so | 16:42 |
| === chihchun is now known as chihchun_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!