[01:24] <nhaines> I was wondering whether there was a way to allow HUD to appear over a GTK top level window.  I'lm looking at a program that is fullscreen with no menus, but would benefit by having HUD integration when running under Ubuntu.
[02:00] <smspillaz> nhaines: as long as the window is not override redirect the hud should work fine
[04:39] <nhaines> smspillaz: It must do that, then.  I'm looking at PyRoom and was considering creating a menu tree to allow for HUD interaction.  But while HUD captures the Alt key, it never appears.
[04:39] <nhaines> smspillaz: Unfortunately, I'm not a GUI programmer, but I guess I have some research to do.  Thanks for a starting point.  :)
[04:40] <smspillaz> nhaines: yeah, getting the shell to stack above fullscreen windows is a bit of a strange usecase at the moment
[04:40] <smspillaz> I remember brandontschafer tried to make it work without too much success
[04:40] <smspillaz> its not really designed to do that
[04:51] <nhaines> smspillaz: when I researched it it did look like a weird corner case.  And I imagine it'd be easier to do with specific toolkits instead of universally.
[04:51] <smspillaz> nhaines: the problem is with unity itself, not your application
[04:51] <smspillaz> or rather, unity sits in an area thats not very clearly defined by the EWMH
[04:52] <smspillaz> the EWMH and the ICCCM mind you
[04:52] <smspillaz> basically, every other desktop will have its menus be override redirect windows which take a grab
[04:53] <smspillaz> unity can't do that because we need to support the XDnD case from the dash
[04:53] <smspillaz> so the "dash" is actually defined as a panel so that it stacks on top of normal windows
[04:53] <smspillaz> we looked into making the dash a "fullscreen" type window, but thats also tricky because then it will cause the input window to be unredirected
[05:31] <nhaines> smspillaz: oh, I understood that it was a Unity issue.  But I figured GTK had a better chance of having a workaround or solution rather than random GUI toolkit.
[05:32] <smspillaz> yeah
[05:32] <smspillaz> its "fixable" but not without a lot of effort
[05:32] <smspillaz> I think given the fact that the current incarnation of unity is "legacy" that won't really happen
[05:32] <nhaines> PyRoom is a "distraction-free" text editor.  So we specifically don't want the Unity panel or the app indicators or notification windows popping up.
[05:33] <nhaines> Otherwise it'd be a quick fix to just run maximized the entire time.
[05:33] <smspillaz> yeah :/
[05:34] <nhaines> So it's not like PyRoom is a standard use case either.  :)
[05:34] <nhaines> Ooh!  Any idea if UnityNext + Mir will address this issue?
[05:34] <smspillaz> nhaines: I guess you can add it to the list of "things that UnityNext will address"
[05:34] <smspillaz> (that list is really really really really long by the way)
[05:35] <smspillaz> nhaines: I can say as much as this: anything is addressable, no matter what codebase you're running on, its just a matter of whether or not the engineers want to address it on *this* rewrite ;-)
[05:35] <nhaines> smspillaz: granted.  ;)
[05:36] <nhaines> Well, I will say that Unity is beautiful and the shell plus HUD and even the voice search is what I want my computing to be.  And that's ignoring the fact that Ubuntu Touch is stunning.
[05:36] <smspillaz> :)
[05:37] <nhaines> I am also really sad that smart scopes got pushed back a cycle, but it's tempered by my hate for unannounced post-beta FFes from Canonical.  ;)
[05:38] <nhaines> But seriously, I'm looking at PyRoom and thinking "shortcut key-only commands are horrible.  If only we had a powerful way to expose commands" when I realized HUD was that way.  Ah well.  :)
[05:39] <smspillaz> nhaines: guess there's no reason why a temporary workaround couldn't be "run in hud capable mode" which just runs pyroom maximized
[05:41] <nhaines> smspillaz: I considered that last night as well.  We just might as well have it be option in the preferences window.
[05:48] <nhaines> smspillaz: I know that a HUD goal was to undterstand command synonyms for searching.  I was thrilled to see it in Ubuntu Touch.  Is there any work I can plan for now in PyRoom on Ubuntu 13.04 that will make this automagically happen when it's available maybe in 13.10?
[05:48] <smspillaz> nhaines: I don't know about the HUD goals, I just maintain the shell/wm integration in unity-legacy
[05:48] <smspillaz> ask tedg
[05:49] <nhaines> smspillaz: thanks.
[05:50] <nhaines> I'll take a pass at the mobile API and then I'll shoot him an email or something.
[06:04] <nhaines> smspillaz: actually, I've been noticing in raring that the Unity Launcher doesn't always slide in when I push past the left side of the screen.  Are you the one I shake my fist at about that?
[06:04] <nhaines> (It's random and I'm trying to narrow it down a bit more before I starting with the bug reports.)
[06:05] <smspillaz> nhaines: ask andyrock
[06:06] <smspillaz> or Trevinho
[06:06] <smspillaz> nhaines: in any case, its pressure based, you have to push your mouse against the side of the screen for a bit
[06:07] <smspillaz> (its designed to prevent it from accidentally coming out when you mouse to the back button on browsers for instance
[06:07] <nhaines> smspillaz:  yes, my favorite feature.  But occasionally it just won't come up and I have to open the Dash.  It seems to start working again after that.
[06:07] <smspillaz> *shrug*
[06:08] <nhaines> Never a problem in quantal, but I can't figure out why it's stopping (or when) in raring.  I might experiment more this weekend.
[06:08] <nhaines> In any case, never fear.  If I figure it out it's going on launchpad.  :)
[06:09] <smspillaz> nhaines: could have been when we moved to the upstream pressure patches
[06:09] <smspillaz> ask brandontschafer
[06:09] <smspillaz> I think he was doing the work for that
[06:10] <nhaines> smspillaz: thanks.  Can I find him in here later?
[06:10] <smspillaz> yeah PST I think
[06:11] <nhaines> Which is my time zone so that's perfect.  Great.  :)
[06:11] <smspillaz> isn't it like 1am for you ?
[06:11] <nhaines> 11pm.
[06:11] <smspillaz> I always get confused about SFO time
[06:11] <nhaines> 1am comes all too soon, don't worry.  ;)