[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [virt-tools-list] [PATCHWORK] [virt-manager] fullscreen behaviour



On 11/19/2009 09:17 AM, Jon Nordby wrote:
> On Thu, Nov 12, 2009 at 8:41 PM, Cole Robinson <crobinso redhat com> wrote:
> 
>>  > No, I intended for it to be at the very top, and works as expected here.
>> I
>>> suspect you are running GNOME with a panel at the top? If so, could you
>> test
>>> if it is positioned correctly when you move the panel to the bottom?
>>
>> Good call, I'm using GNOME with a top panel. Hopefully there is an easy
>> way to work around it.
>>
> 
> I've found no easy way. It seems to me that the only way we get the wanted
> .move() behaviour is when the menuwin is a child of the console topwin and
> not a toplevel window*. For instance when constructing a gtk.Window of type
> gtk.WINDOW_POPUP. However on both window managers I have tested this results
> in a window that will "stick" when you move to different virtual desktops,
> even when calling .unstick() after .show(). This is broken in my opinion.
> Patch showcases this behaviour.
> 
> So the only obvious way I see is to create a child window that has the
> wanted behaviour manually. Which should be possible, but is kinda tiresome.
> So, does anyone have other ideas?
> 
> * even if we were to use the _NET_WORKSPACE attribute to get the panel size,
> xfwm at least will ignore negative y coordinates on .move(). And I have been
> unsuccessful in using .set_override_redirect() to short-circuit the window
> manager. The window would not move at all afterwards.
> 
> I've addressed the other issues, and I'm attaching a patch that applies to
> the previous patch.
> Please test if the window is positioned correct and that it is indeed too
> sticky on Metacity/Compiz.
> 

Yep, everything appears exactly as you described. Maybe we can stick
with the current method, but try to find a way to hide the hide/unhide
the menu if we switch away from the details window, using window signals
or something. This could be risky because if we had some unexpected
false positive or bug, the menu might not unhide.

Also, this behavior reveals a small bug: we should probably kick off the
menu hide timer when mouse leaves the menu, not when it enters the VNC
widget. Otherwise if you switch workspaces while the mouse is over the
menu, it won't hide without switching back to virt-manager.

And this is subjective, but I think 4 seconds for the timer is a bit
long. It seems like just enough time for my brain to say 'disappear
already!' 3 or 2.5 feels better.

Thanks!
Cole


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]