If you're full screen, you probably expect Ctrl-Q to go to the guest,
not the host. I think restricting certain menus is the right way to
handle this generally speaking.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1361367806-4599-10-git-send-email-aliguori@us.ibm.com
This includes a de_DE translation from Kevin Wolf and an it translation from
Paolo Bonzini.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1361367806-4599-8-git-send-email-aliguori@us.ibm.com
Basic menu items to enter full screen mode and zoom in/out. Unlike SDL, we
don't allow arbitrary scaling based on window resizing. The current behavior
with SDL causes a lot of problems for me.
Sometimes I accidentally resize the window a tiny bit while trying to move it
(Ubuntu's 1-pixel window decorations don't help here). After that, scaling is
now active and if the screen changes size again, badness ensues since the
aspect ratio is skewed.
Allowing zooming by 25% in and out should cover most use cases. We can add a
more flexible scaling later but for now, I think this is a more friendly
behavior.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1361367806-4599-7-git-send-email-aliguori@us.ibm.com
There is a small deviation from SDL's behavior here. Instead of Ctrl+Alt
triggering grab, we now use Ctrl-Alt-g to trigger grab.
GTK will not accept Ctrl+Alt as an accelerator since it just consists of
modifiers. Having grab as a proper accelerator is important as it allows a user
to override the accelerator for accessibility purposes.
We also are not automatically grabbing on left-click. Besides the inability to
tie mouse clicks to an accelerator, I think this behavior is hard to discover
and since it only happens depending on the guest state, it can lead to confusing
behavior.
This can be changed in the future if there's a strong resistence to dropping
left-click-to-grab, but I think we're better off dropping it.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1361367806-4599-6-git-send-email-aliguori@us.ibm.com
This enables VteTerminal to be used to render the text consoles. VteTerminal is
the same widget used by gnome-terminal which means it's VT100 emulation is as
good as they come.
It's also screen reader accessible, supports copy/paste, proper scrolling and
most of the other features you would expect from a terminal widget.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1361367806-4599-5-git-send-email-aliguori@us.ibm.com
This is minimalistic and just contains the basic widget infrastructure. The GUI
consists of a menu and a GtkNotebook. To start with, the notebook has its tabs
hidden which provides a UI that looks very similar to SDL with the exception of
the menu bar.
The menu bar allows a user to toggle the visibility of the tabs. Cairo is used
for rendering.
I used gtk-vnc as a reference. gtk-vnc solves the same basic problems as QEMU
since it was originally written as a remote display for QEMU. So for the most
part, the approach to rendering and keyboard handling should be pretty solid for
GTK.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1361367806-4599-4-git-send-email-aliguori@us.ibm.com
Anthony Liguori