[Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Anthony Liguori]

Hi,

I realize UIs are the third rail of QEMU development, but over the years I've
gotten a lot of feedback from users about our UI.  I think everyone struggles
with the SDL interface and its lack of discoverability but it's worse than I
think most people realize for users that rely on accessibility tools.

The two pieces of feedback I've gotten the most re: accessibility are the lack
of QEMU's enablement for screen readers and the lack of configurable
accelerators.

Since we render our own terminal using a fixed sized font, we don't respect
system font settings which means we ignore if the user has configured large
print.

We also don't integrate at all with screen readers which means that for blind
users, the virtual consoles may as well not even exist.

We also don't allow any type of configuration of accelerators.  For users with
limited dexterity (this is actually more common than you would think), they may
use an input device that only inputs one key at a time.  Holding down two keys
at once is not possible for these users.

These are solved problems though and while we could reinvent all of this
ourselves with SDL, we would be crazy if we did.  Modern toolkits, like GTK,
solve these problems.

By using GTK, we can leverage VteTerminal for screen reader integration and font
configuration.  We can also use GTK's accelerator support to make accelerators
configurable (Gnome provides a global accelerator configuration interface).

I'm not attempting to make a pretty desktop virtualization UI.  Maybe we'll go
there eventually but that's not what this series is about.

This is just attempting to use a richer toolkit such that we can enable basic
accessibility support.  As a consequence, the UI is much more usable even for a
user without accessibility requirements so it's a win-win.

[Qemu-devel] [PATCH 1/6] console: allow VCs to be overridden by UI

[Anthony Liguori]

We want to expose VCs using a VteTerminal widget.  We need access to provide our
own CharDriverState in order to do this.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 console.c   |   14 +++++++++++++-
 console.h   |    6 +++++-
 qemu-char.c |    2 +-
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/console.c b/console.c
index 135394f..d8303af 100644
--- a/console.c
+++ b/console.c
@@ -1510,7 +1510,7 @@ static void text_console_do_init(CharDriverState *chr, DisplayState *ds)
         chr->init(chr);
 }
 
-int text_console_init(QemuOpts *opts, CharDriverState **_chr)
+static int text_console_init(QemuOpts *opts, CharDriverState **_chr)
 {
     CharDriverState *chr;
     TextConsole *s;
@@ -1555,6 +1555,18 @@ int text_console_init(QemuOpts *opts, CharDriverState **_chr)
     return 0;
 }
 
+static VcHandler *vc_handler = text_console_init;
+
+int vc_init(QemuOpts *opts, CharDriverState **_chr)
+{
+    return vc_handler(opts, _chr);
+}
+
+void register_vc_handler(VcHandler *handler)
+{
+    vc_handler = handler;
+}
+
 void text_consoles_set_display(DisplayState *ds)
 {
     int i;
diff --git a/console.h b/console.h
index 6ba0d5d..7225ae6 100644
--- a/console.h
+++ b/console.h
@@ -356,7 +356,6 @@ void vga_hw_text_update(console_ch_t *chardata);
 
 int is_graphic_console(void);
 int is_fixedsize_console(void);
-int text_console_init(QemuOpts *opts, CharDriverState **_chr);
 void text_consoles_set_display(DisplayState *ds);
 void console_select(unsigned int index);
 void console_color_init(DisplayState *ds);
@@ -364,6 +363,11 @@ void qemu_console_resize(DisplayState *ds, int width, int height);
 void qemu_console_copy(DisplayState *ds, int src_x, int src_y,
                        int dst_x, int dst_y, int w, int h);
 
+typedef int (VcHandler)(QemuOpts *, CharDriverState **);
+
+int vc_init(QemuOpts *opts, CharDriverState **_chr);
+void register_vc_handler(VcHandler *handler);
+
 /* sdl.c */
 void sdl_display_init(DisplayState *ds, int full_screen, int no_frame);
 
diff --git a/qemu-char.c b/qemu-char.c
index b1d80dd..4680d3c 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2736,7 +2736,7 @@ static const struct {
     { .name = "socket",    .open = qemu_chr_open_socket },
     { .name = "udp",       .open = qemu_chr_open_udp },
     { .name = "msmouse",   .open = qemu_chr_open_msmouse },
-    { .name = "vc",        .open = text_console_init },
+    { .name = "vc",        .open = vc_init },
 #ifdef _WIN32
     { .name = "file",      .open = qemu_chr_open_win_file_out },
     { .name = "pipe",      .open = qemu_chr_open_win_pipe },
-- 
1.7.4.1

[Qemu-devel] [PATCH 2/6] ui: add basic GTK gui

[Anthony Liguori]

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>
---
 Makefile      |    2 +
 Makefile.objs |    1 +
 configure     |   25 +++-
 console.h     |    4 +
 sysemu.h      |    1 +
 ui/gtk.c      |  551 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 583 insertions(+), 1 deletions(-)
 create mode 100644 ui/gtk.c

diff --git a/Makefile b/Makefile
index e66e885..d90025c 100644
--- a/Makefile
+++ b/Makefile
@@ -120,6 +120,8 @@ ui/cocoa.o: ui/cocoa.m
 
 ui/sdl.o audio/sdlaudio.o ui/sdl_zoom.o baum.o: QEMU_CFLAGS += $(SDL_CFLAGS)
 
+ui/gtk.o: QEMU_CFLAGS += $(GTK_CFLAGS) $(VTE_CFLAGS)
+
 ui/vnc.o: QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
 
 bt-host.o: QEMU_CFLAGS += $(BLUEZ_CFLAGS)
diff --git a/Makefile.objs b/Makefile.objs
index 391e524..09add6e 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -147,6 +147,7 @@ ui-obj-y += keymaps.o
 ui-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o
 ui-obj-$(CONFIG_COCOA) += cocoa.o
 ui-obj-$(CONFIG_CURSES) += curses.o
+ui-obj-$(CONFIG_GTK) += gtk.o
 vnc-obj-y += vnc.o d3des.o
 vnc-obj-y += vnc-enc-zlib.o vnc-enc-hextile.o
 vnc-obj-y += vnc-enc-tight.o vnc-palette.o
diff --git a/configure b/configure
index 037f7f7..7b4a040 100755
--- a/configure
+++ b/configure
@@ -246,7 +246,7 @@ sdl_config="${SDL_CONFIG-${cross_prefix}sdl-config}"
 QEMU_CFLAGS="-fno-strict-aliasing $QEMU_CFLAGS"
 CFLAGS="-g $CFLAGS"
 QEMU_CFLAGS="-Wall -Wundef -Wwrite-strings -Wmissing-prototypes $QEMU_CFLAGS"
-QEMU_CFLAGS="-Wstrict-prototypes -Wredundant-decls $QEMU_CFLAGS"
+QEMU_CFLAGS="-Wredundant-decls $QEMU_CFLAGS"
 QEMU_CFLAGS="-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE $QEMU_CFLAGS"
 QEMU_CFLAGS="-D_FORTIFY_SOURCE=2 $QEMU_CFLAGS"
 QEMU_INCLUDES="-I. -I\$(SRC_PATH) -I\$(SRC_PATH)/fpu"
@@ -1487,6 +1487,23 @@ if test "$sparse" != "no" ; then
 fi
 
 ##########################################
+# GTK probe
+
+if test "$gtk" != "no"; then
+    if $pkg_config gtk+-2.0 --modversion >/dev/null 2>/dev/null && \
+       $pkg_config vte --modversion >/dev/null 2>/dev/null; then
+	gtk_cflags=`$pkg_config --cflags gtk+-2.0 2>/dev/null`
+	gtk_libs=`$pkg_config --libs gtk+-2.0 2>/dev/null`
+	vte_cflags=`$pkg_config --cflags vte 2>/dev/null`
+	vte_libs=`$pkg_config --libs vte 2>/dev/null`
+	libs_softmmu="$gtk_libs $vte_libs $libs_softmmu"
+	gtk="yes"
+    else
+	gtk="no"
+    fi
+fi
+
+##########################################
 # SDL probe
 
 # Look for sdl configuration program (pkg-config or sdl-config).  Try
@@ -2864,6 +2881,7 @@ if test "$darwin" = "yes" ; then
     echo "Cocoa support     $cocoa"
 fi
 echo "SDL support       $sdl"
+echo "GTK support       $gtk"
 echo "curses support    $curses"
 echo "curl support      $curl"
 echo "mingw32 support   $mingw32"
@@ -3147,6 +3165,11 @@ if test "$bluez" = "yes" ; then
   echo "BLUEZ_CFLAGS=$bluez_cflags" >> $config_host_mak
 fi
 echo "GLIB_CFLAGS=$glib_cflags" >> $config_host_mak
+if test "$gtk" = "yes" ; then
+  echo "CONFIG_GTK=y" >> $config_host_mak
+  echo "GTK_CFLAGS=$gtk_cflags" >> $config_host_mak
+  echo "VTE_CFLAGS=$vte_cflags" >> $config_host_mak
+fi
 if test "$xen" = "yes" ; then
   echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
   echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> $config_host_mak
diff --git a/console.h b/console.h
index 7225ae6..c322260 100644
--- a/console.h
+++ b/console.h
@@ -398,4 +398,8 @@ static inline int vnc_display_pw_expire(DisplayState *ds, time_t expires)
 /* curses.c */
 void curses_display_init(DisplayState *ds, int full_screen);
 
+/* gtk.c */
+void early_gtk_display_init(void);
+void gtk_display_init(DisplayState *ds);
+
 #endif
diff --git a/sysemu.h b/sysemu.h
index 9d5ce33..aa0e3e4 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -81,6 +81,7 @@ typedef enum DisplayType
     DT_DEFAULT,
     DT_CURSES,
     DT_SDL,
+    DT_GTK,
     DT_NOGRAPHIC,
     DT_NONE,
 } DisplayType;
diff --git a/ui/gtk.c b/ui/gtk.c
new file mode 100644
index 0000000..502705b
--- /dev/null
+++ b/ui/gtk.c
@@ -0,0 +1,551 @@
+/*
+ * GTK UI
+ *
+ * Copyright IBM, Corp. 2012
+ *
+ * Authors:
+ *  Anthony Liguori   <aliguori@us.ibm.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+#include <gtk/gtk.h>
+#include <gdk/gdkkeysyms.h>
+#include <vte/vte.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <sys/un.h>
+#include <sys/wait.h>
+#include <pty.h>
+#include <math.h>
+
+#include "qemu-common.h"
+#include "console.h"
+#include "sysemu.h"
+#include "qmp-commands.h"
+#include "x_keymap.h"
+#include "keymaps.h"
+
+//#define DEBUG_GTK
+
+#ifdef DEBUG_GTK
+#define dprintf(fmt, ...) printf(fmt, ## __VA_ARGS__)
+#else
+#define dprintf(fmt, ...) do { } while (0)
+#endif
+
+typedef struct VirtualConsole
+{
+    GtkWidget *menu_item;
+    GtkWidget *terminal;
+    GtkWidget *scrolled_window;
+    CharDriverState *chr;
+    int fd;
+} VirtualConsole;
+
+typedef struct GtkDisplayState
+{
+    GtkWidget *window;
+
+    GtkWidget *menu_bar;
+
+    GtkWidget *file_menu_item;
+    GtkWidget *file_menu;
+    GtkWidget *quit_item;
+
+    GtkWidget *view_menu_item;
+    GtkWidget *view_menu;
+    GtkWidget *vga_item;
+
+    GtkWidget *show_tabs_item;
+
+    GtkWidget *vbox;
+    GtkWidget *notebook;
+    GtkWidget *drawing_area;
+    cairo_surface_t *surface;
+    DisplayChangeListener dcl;
+    DisplayState *ds;
+    int button_mask;
+    int last_x;
+    int last_y;
+
+    double scale_x;
+    double scale_y;
+
+    GdkCursor *null_cursor;
+    Notifier mouse_mode_notifier;
+} GtkDisplayState;
+
+static GtkDisplayState *global_state;
+
+/** Utility Functions **/
+
+static void gd_update_cursor(GtkDisplayState *s, gboolean override)
+{
+    GdkWindow *window;
+    bool on_vga;
+
+    window = gtk_widget_get_window(GTK_WIDGET(s->drawing_area));
+
+    on_vga = (gtk_notebook_get_current_page(GTK_NOTEBOOK(s->notebook)) == 0);
+
+    if ((override || on_vga) && kbd_mouse_is_absolute()) {
+	gdk_window_set_cursor(window, s->null_cursor);
+    } else {
+	gdk_window_set_cursor(window, NULL);
+    }
+}
+
+static void gd_update_caption(GtkDisplayState *s)
+{
+    const char *status = "";
+    gchar *title;
+
+    if (!runstate_is_running()) {
+        status = " [Stopped]";
+    }
+
+    if (qemu_name) {
+        title = g_strdup_printf("QEMU (%s)%s", qemu_name, status);
+    } else {
+        title = g_strdup_printf("QEMU%s", status);
+    }
+        
+    gtk_window_set_title(GTK_WINDOW(s->window), title);
+
+    g_free(title);
+}
+
+/** DisplayState Callbacks **/
+
+static void gd_update(DisplayState *ds, int x, int y, int w, int h)
+{
+    GtkDisplayState *s = ds->opaque;
+    int x1, x2, y1, y2;
+
+    dprintf("update(x=%d, y=%d, w=%d, h=%d)\n", x, y, w, h);
+
+    x1 = floor(x * s->scale_x);
+    y1 = floor(y * s->scale_y);
+
+    x2 = ceil(x * s->scale_x + w * s->scale_x);
+    y2 = ceil(y * s->scale_y + h * s->scale_y);
+
+    gtk_widget_queue_draw_area(s->drawing_area, x1, y1, (x2 - x1), (y2 - y1));
+}
+
+static void gd_refresh(DisplayState *ds)
+{
+    vga_hw_update();
+}
+
+static void gd_resize(DisplayState *ds)
+{
+    GtkDisplayState *s = ds->opaque;
+    cairo_format_t kind;
+    int stride;
+
+    dprintf("resize(width=%d, height=%d)\n",
+            ds->surface->width, ds->surface->height);
+
+    if (s->surface) {
+        cairo_surface_destroy(s->surface);
+    }
+
+    switch (ds->surface->pf.bits_per_pixel) {
+    case 8:
+        kind = CAIRO_FORMAT_A8;
+        break;
+    case 16:
+        kind = CAIRO_FORMAT_RGB16_565;
+        break;
+    case 32:
+        kind = CAIRO_FORMAT_RGB24;
+        break;
+    default:
+        g_assert_not_reached();
+        break;
+    }
+
+    stride = cairo_format_stride_for_width(kind, ds->surface->width);
+    g_assert_cmpint(ds->surface->linesize, ==, stride);
+
+    s->surface = cairo_image_surface_create_for_data(ds->surface->data,
+                                                     kind,
+                                                     ds->surface->width,
+                                                     ds->surface->height,
+                                                     ds->surface->linesize);
+
+    gtk_widget_set_size_request(s->drawing_area,
+                                ds->surface->width * s->scale_x,
+                                ds->surface->height * s->scale_y);
+}
+
+/** QEMU Events **/
+
+static void gd_change_runstate(void *opaque, int running, RunState state)
+{
+    GtkDisplayState *s = opaque;
+
+    gd_update_caption(s);
+}
+
+static void gd_mouse_mode_change(Notifier *notify, void *data)
+{
+    gd_update_cursor(container_of(notify, GtkDisplayState, mouse_mode_notifier),
+                     FALSE);
+}
+
+/** GTK Events **/
+
+static gboolean gd_window_close(GtkWidget *widget, GdkEvent *event,
+                                void *opaque)
+{
+    if (!no_quit) {
+        qmp_quit(NULL);
+        return FALSE;
+    }
+
+    return TRUE;
+}
+
+static gboolean gd_draw_event(GtkWidget *widget, cairo_t *cr, void *opaque)
+{
+    GtkDisplayState *s = opaque;
+    int ww, wh;
+    int fbw, fbh;
+
+    fbw = s->ds->surface->width;
+    fbh = s->ds->surface->height;
+
+    gdk_drawable_get_size(gtk_widget_get_window(widget), &ww, &wh);
+
+    cairo_rectangle(cr, 0, 0, ww, wh);
+
+    if (ww != fbw || wh != fbh) {
+        s->scale_x = (double)ww / fbw;
+        s->scale_y = (double)wh / fbh;
+        cairo_scale(cr, s->scale_x, s->scale_y);
+    } else {
+        s->scale_x = 1.0;
+        s->scale_y = 1.0;
+    }
+
+    cairo_set_source_surface(cr, s->surface, 0, 0);
+    cairo_paint(cr);
+
+    return TRUE;
+}
+
+static gboolean gd_expose_event(GtkWidget *widget, GdkEventExpose *expose,
+                                void *opaque)
+{
+    cairo_t *cr;
+    gboolean ret;
+
+    cr = gdk_cairo_create(gtk_widget_get_window(widget));
+    cairo_rectangle(cr,
+                    expose->area.x,
+                    expose->area.y,
+                    expose->area.width,
+                    expose->area.height);
+    cairo_clip(cr);
+
+    ret = gd_draw_event(widget, cr, opaque);
+
+    cairo_destroy(cr);
+
+    return ret;
+}
+
+static gboolean gd_motion_event(GtkWidget *widget, GdkEventMotion *motion,
+                                void *opaque)
+{
+    GtkDisplayState *s = opaque;
+    int dx, dy;
+    int x, y;
+
+    x = motion->x / s->scale_x;
+    y = motion->y / s->scale_y;
+
+    if (kbd_mouse_is_absolute()) {
+        dx = x * 0x7FFF / (s->ds->surface->width - 1);
+        dy = y * 0x7FFF / (s->ds->surface->height - 1);
+    } else if (s->last_x == -1 || s->last_y == -1) {
+        dx = 0;
+        dy = 0;
+    } else {
+        dx = x - s->last_x;
+        dy = y - s->last_y;
+    }
+
+    s->last_x = x;
+    s->last_y = y;
+
+    if (kbd_mouse_is_absolute()) {
+        kbd_mouse_event(dx, dy, 0, s->button_mask);
+    }
+
+    return TRUE;
+}
+
+static gboolean gd_button_event(GtkWidget *widget, GdkEventButton *button,
+                                void *opaque)
+{
+    GtkDisplayState *s = opaque;
+    int dx, dy;
+    int n;
+
+    if (button->button == 1) {
+        n = 0x01;
+    } else if (button->button == 2) {
+        n = 0x04;
+    } else if (button->button == 3) {
+        n = 0x02;
+    } else {
+        n = 0x00;
+    }
+
+    if (button->type == GDK_BUTTON_PRESS) {
+        s->button_mask |= n;
+    } else if (button->type == GDK_BUTTON_RELEASE) {
+        s->button_mask &= ~n;
+    }
+
+    if (kbd_mouse_is_absolute()) {
+        dx = s->last_x * 0x7FFF / (s->ds->surface->width - 1);
+        dy = s->last_y * 0x7FFF / (s->ds->surface->height - 1);
+    } else {
+        dx = 0;
+        dy = 0;
+    }
+
+    kbd_mouse_event(dx, dy, 0, s->button_mask);
+        
+    return TRUE;
+}
+
+static gboolean gd_key_event(GtkWidget *widget, GdkEventKey *key, void *opaque)
+{
+    int gdk_keycode;
+    int qemu_keycode;
+
+    gdk_keycode = key->hardware_keycode;
+
+    if (gdk_keycode < 9) {
+        qemu_keycode = 0;
+    } else if (gdk_keycode < 97) {
+        qemu_keycode = gdk_keycode - 8;
+    } else if (gdk_keycode < 158) {
+        qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
+    } else if (gdk_keycode == 208) { /* Hiragana_Katakana */
+        qemu_keycode = 0x70;
+    } else if (gdk_keycode == 211) { /* backslash */
+        qemu_keycode = 0x73;
+    } else {
+        qemu_keycode = 0;
+    }
+
+    dprintf("translated GDK keycode %d to QEMU keycode %d (%s)\n",
+            gdk_keycode, qemu_keycode,
+            (key->type == GDK_KEY_PRESS) ? "down" : "up");
+
+    if (qemu_keycode & SCANCODE_GREY) {
+        kbd_put_keycode(SCANCODE_EMUL0);
+    }
+
+    if (key->type == GDK_KEY_PRESS) {
+        kbd_put_keycode(qemu_keycode & SCANCODE_KEYCODEMASK);
+    } else if (key->type == GDK_KEY_RELEASE) {
+        kbd_put_keycode(qemu_keycode | SCANCODE_UP);
+    } else {
+        g_assert_not_reached();
+    }
+
+    return FALSE;
+}
+
+/** Window Menu Actions **/
+
+static void gd_menu_quit(GtkMenuItem *item, void *opaque)
+{
+    qmp_quit(NULL);
+}
+
+static void gd_menu_switch_vc(GtkMenuItem *item, void *opaque)
+{
+    GtkDisplayState *s = opaque;
+
+    if (gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s->vga_item))) {
+        gtk_notebook_set_current_page(GTK_NOTEBOOK(s->notebook), 0);
+    }
+}
+
+static void gd_menu_show_tabs(GtkMenuItem *item, void *opaque)
+{
+    GtkDisplayState *s = opaque;
+
+    if (gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s->show_tabs_item))) {
+        gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s->notebook), TRUE);
+    } else {
+        gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s->notebook), FALSE);
+    }
+}
+
+static void gd_change_page(GtkNotebook *nb, gpointer arg1, guint arg2,
+                           gpointer data)
+{
+    GtkDisplayState *s = data;
+
+    if (!gtk_widget_get_realized(s->notebook)) {
+        return;
+    }
+
+    gd_update_cursor(s, TRUE);
+}
+
+void early_gtk_display_init(void)
+{
+}
+
+/** Window Creation **/
+
+static void gd_connect_signals(GtkDisplayState *s)
+{
+    g_signal_connect(s->show_tabs_item, "activate",
+                     G_CALLBACK(gd_menu_show_tabs), s);
+
+    g_signal_connect(s->window, "delete-event",
+                     G_CALLBACK(gd_window_close), s);
+
+    g_signal_connect(s->drawing_area, "expose-event",
+                     G_CALLBACK(gd_expose_event), s);
+    g_signal_connect(s->drawing_area, "motion-notify-event",
+                     G_CALLBACK(gd_motion_event), s);
+    g_signal_connect(s->drawing_area, "button-press-event",
+                     G_CALLBACK(gd_button_event), s);
+    g_signal_connect(s->drawing_area, "button-release-event",
+                     G_CALLBACK(gd_button_event), s);
+    g_signal_connect(s->drawing_area, "key-press-event",
+                     G_CALLBACK(gd_key_event), s);
+    g_signal_connect(s->drawing_area, "key-release-event",
+                     G_CALLBACK(gd_key_event), s);
+
+    g_signal_connect(s->quit_item, "activate",
+                     G_CALLBACK(gd_menu_quit), s);
+    g_signal_connect(s->vga_item, "activate",
+                     G_CALLBACK(gd_menu_switch_vc), s);
+    g_signal_connect(s->notebook, "switch-page",
+                     G_CALLBACK(gd_change_page), s);
+}
+
+static void gd_create_menus(GtkDisplayState *s)
+{
+    GtkStockItem item;
+    GtkAccelGroup *accel_group;
+    GSList *group = NULL;
+    GtkWidget *separator;
+
+    accel_group = gtk_accel_group_new();
+    s->file_menu = gtk_menu_new();
+    gtk_menu_set_accel_group(GTK_MENU(s->file_menu), accel_group);
+    s->file_menu_item = gtk_menu_item_new_with_mnemonic("_File");
+
+    s->quit_item = gtk_image_menu_item_new_from_stock(GTK_STOCK_QUIT, NULL);
+    gtk_stock_lookup(GTK_STOCK_QUIT, &item);
+    gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->quit_item),
+                                 "<QEMU>/File/Quit");
+    gtk_accel_map_add_entry("<QEMU>/File/Quit", item.keyval, item.modifier);
+
+    s->view_menu = gtk_menu_new();
+    gtk_menu_set_accel_group(GTK_MENU(s->view_menu), accel_group);
+    s->view_menu_item = gtk_menu_item_new_with_mnemonic("_View");
+
+    separator = gtk_separator_menu_item_new();
+    gtk_menu_append(GTK_MENU(s->view_menu), separator);
+
+    s->vga_item = gtk_radio_menu_item_new_with_mnemonic(group, "_VGA");
+    group = gtk_radio_menu_item_get_group(GTK_RADIO_MENU_ITEM(s->vga_item));
+    gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->vga_item),
+                                 "<QEMU>/View/VGA");
+    gtk_accel_map_add_entry("<QEMU>/View/VGA", GDK_KEY_1, GDK_CONTROL_MASK | GDK_MOD1_MASK);
+    gtk_menu_append(GTK_MENU(s->view_menu), s->vga_item);
+
+    separator = gtk_separator_menu_item_new();
+    gtk_menu_append(GTK_MENU(s->view_menu), separator);
+
+    s->show_tabs_item = gtk_check_menu_item_new_with_mnemonic("Show _Tabs");
+    gtk_menu_append(GTK_MENU(s->view_menu), s->show_tabs_item);
+
+    g_object_set_data(G_OBJECT(s->window), "accel_group", accel_group);
+    gtk_window_add_accel_group(GTK_WINDOW(s->window), accel_group);
+
+    gtk_menu_append(GTK_MENU(s->file_menu), s->quit_item);
+    gtk_menu_item_set_submenu(GTK_MENU_ITEM(s->file_menu_item), s->file_menu);
+    gtk_menu_shell_append(GTK_MENU_SHELL(s->menu_bar), s->file_menu_item);
+
+    gtk_menu_item_set_submenu(GTK_MENU_ITEM(s->view_menu_item), s->view_menu);
+    gtk_menu_shell_append(GTK_MENU_SHELL(s->menu_bar), s->view_menu_item);
+}
+
+void gtk_display_init(DisplayState *ds)
+{
+    GtkDisplayState *s = g_malloc0(sizeof(*s));
+
+    gtk_init(NULL, NULL);
+
+    ds->opaque = s;
+    s->ds = ds;
+    s->dcl.dpy_update = gd_update;
+    s->dcl.dpy_resize = gd_resize;
+    s->dcl.dpy_refresh = gd_refresh;
+    register_displaychangelistener(ds, &s->dcl);
+
+    s->window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
+    s->vbox = gtk_vbox_new(FALSE, 0);
+    s->notebook = gtk_notebook_new();
+    s->drawing_area = gtk_drawing_area_new();
+    s->menu_bar = gtk_menu_bar_new();
+
+    s->scale_x = 1.0;
+    s->scale_y = 1.0;
+
+    s->null_cursor = gdk_cursor_new(GDK_BLANK_CURSOR);
+
+    s->mouse_mode_notifier.notify = gd_mouse_mode_change;
+    qemu_add_mouse_mode_change_notifier(&s->mouse_mode_notifier);
+    qemu_add_vm_change_state_handler(gd_change_runstate, s);
+
+    gtk_notebook_append_page(GTK_NOTEBOOK(s->notebook), s->drawing_area, gtk_label_new("VGA"));
+
+    gd_create_menus(s);
+
+    gd_connect_signals(s);
+
+    gtk_widget_add_events(s->drawing_area,
+                          GDK_POINTER_MOTION_MASK |
+                          GDK_BUTTON_PRESS_MASK |
+                          GDK_BUTTON_RELEASE_MASK |
+                          GDK_BUTTON_MOTION_MASK |
+                          GDK_SCROLL_MASK |
+                          GDK_KEY_PRESS_MASK);
+    gtk_widget_set_double_buffered(s->drawing_area, FALSE);
+    gtk_widget_set_can_focus(s->drawing_area, TRUE);
+
+    gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s->notebook), FALSE);
+    gtk_notebook_set_show_border(GTK_NOTEBOOK(s->notebook), FALSE);
+
+    gtk_window_set_resizable(GTK_WINDOW(s->window), FALSE);
+
+    gd_update_caption(s);
+
+    gtk_box_pack_start(GTK_BOX(s->vbox), s->menu_bar, FALSE, TRUE, 0);
+    gtk_box_pack_start(GTK_BOX(s->vbox), s->notebook, TRUE, TRUE, 0);
+
+    gtk_container_add(GTK_CONTAINER(s->window), s->vbox);
+
+    gtk_widget_show_all(s->window);
+
+    global_state = s;
+}
-- 
1.7.4.1

[Qemu-devel] [PATCH 3/6] gtk: add virtual console support

[Anthony Liguori]

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>
---
 ui/gtk.c |  138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 138 insertions(+), 0 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index 502705b..bf65a4f 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -35,6 +35,8 @@
 #define dprintf(fmt, ...) do { } while (0)
 #endif
 
+#define MAX_VCS 10
+
 typedef struct VirtualConsole
 {
     GtkWidget *menu_item;
@@ -58,6 +60,9 @@ typedef struct GtkDisplayState
     GtkWidget *view_menu;
     GtkWidget *vga_item;
 
+    int nb_vcs;
+    VirtualConsole vc[MAX_VCS];
+
     GtkWidget *show_tabs_item;
 
     GtkWidget *vbox;
@@ -379,6 +384,15 @@ static void gd_menu_switch_vc(GtkMenuItem *item, void *opaque)
 
     if (gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s->vga_item))) {
         gtk_notebook_set_current_page(GTK_NOTEBOOK(s->notebook), 0);
+    } else {
+        int i;
+
+        for (i = 0; i < s->nb_vcs; i++) {
+            if (gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s->vc[i].menu_item))) {
+                gtk_notebook_set_current_page(GTK_NOTEBOOK(s->notebook), i + 1);
+                break;
+            }
+        }
     }
 }
 
@@ -405,8 +419,124 @@ static void gd_change_page(GtkNotebook *nb, gpointer arg1, guint arg2,
     gd_update_cursor(s, TRUE);
 }
 
+/** Virtual Console Callbacks **/
+
+static int gd_vc_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
+{
+    VirtualConsole *vc = chr->opaque;
+
+    return write(vc->fd, buf, len);
+}
+
+static int nb_vcs;
+static CharDriverState *vcs[MAX_VCS];
+
+static int gd_vc_handler(QemuOpts *opts, CharDriverState **chrp)
+{
+    CharDriverState *chr;
+
+    chr = g_malloc0(sizeof(*chr));
+    chr->chr_write = gd_vc_chr_write;
+
+    *chrp = chr;
+
+    vcs[nb_vcs++] = chr;
+
+    return 0;
+}
+
 void early_gtk_display_init(void)
 {
+    register_vc_handler(gd_vc_handler);
+}
+
+static gboolean gd_vc_in(GIOChannel *chan, GIOCondition cond, void *opaque)
+{
+    VirtualConsole *vc = opaque;
+    uint8_t buffer[1024];
+    ssize_t len;
+
+    len = read(vc->fd, buffer, sizeof(buffer));
+    if (len <= 0) {
+        return FALSE;
+    }
+
+    qemu_chr_be_write(vc->chr, buffer, len);
+
+    return TRUE;
+}
+
+static GSList *gd_vc_init(GtkDisplayState *s, VirtualConsole *vc, int index, GSList *group)
+{
+    const char *label;
+    char buffer[32];
+    char path[32];
+    VtePty *pty;
+    GIOChannel *chan;
+    GtkWidget *scrolled_window;
+    GtkAdjustment *adjustment;
+    int master_fd, slave_fd, ret;
+    struct termios tty;
+
+    snprintf(buffer, sizeof(buffer), "vc%d", index);
+    snprintf(path, sizeof(path), "<QEMU>/View/VC%d", index);
+
+    vc->chr = vcs[index];
+
+    if (vc->chr->label) {
+        label = vc->chr->label;
+    } else {
+        label = buffer;
+    }
+
+    vc->menu_item = gtk_radio_menu_item_new_with_mnemonic(group, label);
+    group = gtk_radio_menu_item_get_group(GTK_RADIO_MENU_ITEM(vc->menu_item));
+    gtk_menu_item_set_accel_path(GTK_MENU_ITEM(vc->menu_item), path);
+    gtk_accel_map_add_entry(path, GDK_KEY_2 + index, GDK_CONTROL_MASK | GDK_MOD1_MASK);
+
+    vc->terminal = vte_terminal_new();
+
+    ret = openpty(&master_fd, &slave_fd, NULL, NULL, NULL);
+    g_assert(ret != -1);
+
+    /* Set raw attributes on the pty. */
+    tcgetattr(slave_fd, &tty);
+    cfmakeraw(&tty);
+    tcsetattr(slave_fd, TCSAFLUSH, &tty);
+
+    pty = vte_pty_new_foreign(master_fd, NULL);
+
+    vte_terminal_set_pty_object(VTE_TERMINAL(vc->terminal), pty);
+
+    vte_terminal_set_scrollback_lines(VTE_TERMINAL(vc->terminal), -1);
+
+    adjustment = vte_terminal_get_adjustment(VTE_TERMINAL(vc->terminal));
+
+    scrolled_window = gtk_scrolled_window_new(NULL, adjustment);
+
+    gtk_container_add(GTK_CONTAINER(scrolled_window), vc->terminal);
+
+    vc->fd = slave_fd;
+    vc->chr->opaque = vc;
+    vc->scrolled_window = scrolled_window;
+
+    gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(vc->scrolled_window), GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC);
+
+    gtk_notebook_append_page(GTK_NOTEBOOK(s->notebook), scrolled_window, gtk_label_new(label));
+    g_signal_connect(vc->menu_item, "activate",
+                     G_CALLBACK(gd_menu_switch_vc), s);
+
+    gtk_menu_append(GTK_MENU(s->view_menu), vc->menu_item);
+
+    qemu_chr_generic_open(vc->chr);
+    if (vc->chr->init) {
+        vc->chr->init(vc->chr);
+    }
+
+    chan = g_io_channel_unix_new(vc->fd);
+    g_io_add_watch(chan, G_IO_IN, gd_vc_in, vc);
+
+    return group;
 }
 
 /** Window Creation **/
@@ -446,6 +576,7 @@ static void gd_create_menus(GtkDisplayState *s)
     GtkAccelGroup *accel_group;
     GSList *group = NULL;
     GtkWidget *separator;
+    int i;
 
     accel_group = gtk_accel_group_new();
     s->file_menu = gtk_menu_new();
@@ -472,6 +603,13 @@ static void gd_create_menus(GtkDisplayState *s)
     gtk_accel_map_add_entry("<QEMU>/View/VGA", GDK_KEY_1, GDK_CONTROL_MASK | GDK_MOD1_MASK);
     gtk_menu_append(GTK_MENU(s->view_menu), s->vga_item);
 
+    for (i = 0; i < nb_vcs; i++) {
+        VirtualConsole *vc = &s->vc[i];
+
+        group = gd_vc_init(s, vc, i, group);
+        s->nb_vcs++;
+    }
+
     separator = gtk_separator_menu_item_new();
     gtk_menu_append(GTK_MENU(s->view_menu), separator);
 
-- 
1.7.4.1

[Qemu-devel] [PATCH 4/6] gtk: add support for input grabbing

[Anthony Liguori]

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>
---
 ui/gtk.c |  102 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 98 insertions(+), 4 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index bf65a4f..73051db 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -58,6 +58,7 @@ typedef struct GtkDisplayState
 
     GtkWidget *view_menu_item;
     GtkWidget *view_menu;
+    GtkWidget *grab_item;
     GtkWidget *vga_item;
 
     int nb_vcs;
@@ -86,6 +87,11 @@ static GtkDisplayState *global_state;
 
 /** Utility Functions **/
 
+static bool gd_is_grab_active(GtkDisplayState *s)
+{
+    return gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s->grab_item));
+}
+
 static void gd_update_cursor(GtkDisplayState *s, gboolean override)
 {
     GdkWindow *window;
@@ -95,7 +101,8 @@ static void gd_update_cursor(GtkDisplayState *s, gboolean override)
 
     on_vga = (gtk_notebook_get_current_page(GTK_NOTEBOOK(s->notebook)) == 0);
 
-    if ((override || on_vga) && kbd_mouse_is_absolute()) {
+    if ((override || on_vga) &&
+        (kbd_mouse_is_absolute() || gd_is_grab_active(s))) {
 	gdk_window_set_cursor(window, s->null_cursor);
     } else {
 	gdk_window_set_cursor(window, NULL);
@@ -106,15 +113,20 @@ static void gd_update_caption(GtkDisplayState *s)
 {
     const char *status = "";
     gchar *title;
+    const char *grab = "";
+
+    if (gd_is_grab_active(s)) {
+        grab = " - Press Ctrl+Alt+G to release grab";
+    }
 
     if (!runstate_is_running()) {
         status = " [Stopped]";
     }
 
     if (qemu_name) {
-        title = g_strdup_printf("QEMU (%s)%s", qemu_name, status);
+        title = g_strdup_printf("QEMU (%s)%s%s", qemu_name, status, grab);
     } else {
-        title = g_strdup_printf("QEMU%s", status);
+        title = g_strdup_printf("QEMU%s%s", status, grab);
     }
         
     gtk_window_set_title(GTK_WINDOW(s->window), title);
@@ -288,10 +300,44 @@ static gboolean gd_motion_event(GtkWidget *widget, GdkEventMotion *motion,
     s->last_x = x;
     s->last_y = y;
 
-    if (kbd_mouse_is_absolute()) {
+    if (kbd_mouse_is_absolute() || gd_is_grab_active(s)) {
         kbd_mouse_event(dx, dy, 0, s->button_mask);
     }
 
+    if (!kbd_mouse_is_absolute() && gd_is_grab_active(s)) {
+        GdkDrawable *drawable = GDK_DRAWABLE(gtk_widget_get_window(s->drawing_area));
+        GdkDisplay *display = gdk_drawable_get_display(drawable);
+        GdkScreen *screen = gdk_drawable_get_screen(drawable);
+        int x = (int)motion->x_root;
+        int y = (int)motion->y_root;
+
+        /* In relative mode check to see if client pointer hit
+         * one of the screen edges, and if so move it back by
+         * 200 pixels. This is important because the pointer
+         * in the server doesn't correspond 1-for-1, and so
+         * may still be only half way across the screen. Without
+         * this warp, the server pointer would thus appear to hit
+         * an invisible wall */
+        if (x == 0) {
+            x += 200;
+        }
+        if (y == 0) {
+            y += 200;
+        }
+        if (x == (gdk_screen_get_width(screen) - 1)) {
+            x -= 200;
+        }
+        if (y == (gdk_screen_get_height(screen) - 1)) {
+            y -= 200;
+        }
+
+        if (x != (int)motion->x_root || y != (int)motion->y_root) {
+            gdk_display_warp_pointer(display, screen, x, y);
+            s->last_x = -1;
+            s->last_y = -1;
+            return FALSE;
+        }
+    }        
     return TRUE;
 }
 
@@ -407,15 +453,52 @@ static void gd_menu_show_tabs(GtkMenuItem *item, void *opaque)
     }
 }
 
+static void gd_menu_grab_input(GtkMenuItem *item, void *opaque)
+{
+    GtkDisplayState *s = opaque;
+
+    if (gd_is_grab_active(s)) {
+	gdk_keyboard_grab(gtk_widget_get_window(GTK_WIDGET(s->drawing_area)),
+			  FALSE,
+			  GDK_CURRENT_TIME);
+	gdk_pointer_grab(gtk_widget_get_window(GTK_WIDGET(s->drawing_area)),
+			 FALSE, /* All events to come to our window directly */
+			 GDK_POINTER_MOTION_MASK |
+			 GDK_BUTTON_PRESS_MASK |
+			 GDK_BUTTON_RELEASE_MASK |
+			 GDK_BUTTON_MOTION_MASK |
+			 GDK_SCROLL_MASK,
+			 NULL, /* Allow cursor to move over entire desktop */
+                         s->null_cursor,
+			 GDK_CURRENT_TIME);
+    } else {
+	gdk_keyboard_ungrab(GDK_CURRENT_TIME);
+	gdk_pointer_ungrab(GDK_CURRENT_TIME);
+    }
+
+    gd_update_caption(s);
+    gd_update_cursor(s, FALSE);
+}
+
 static void gd_change_page(GtkNotebook *nb, gpointer arg1, guint arg2,
                            gpointer data)
 {
     GtkDisplayState *s = data;
+    gboolean on_vga;
 
     if (!gtk_widget_get_realized(s->notebook)) {
         return;
     }
 
+    on_vga = arg2 == 0;
+
+    if (!on_vga) {
+        gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s->grab_item),
+                                       FALSE);
+    }
+
+    gtk_widget_set_sensitive(s->grab_item, on_vga);
+
     gd_update_cursor(s, TRUE);
 }
 
@@ -566,6 +649,8 @@ static void gd_connect_signals(GtkDisplayState *s)
                      G_CALLBACK(gd_menu_quit), s);
     g_signal_connect(s->vga_item, "activate",
                      G_CALLBACK(gd_menu_switch_vc), s);
+    g_signal_connect(s->grab_item, "activate",
+                     G_CALLBACK(gd_menu_grab_input), s);
     g_signal_connect(s->notebook, "switch-page",
                      G_CALLBACK(gd_change_page), s);
 }
@@ -596,6 +681,15 @@ static void gd_create_menus(GtkDisplayState *s)
     separator = gtk_separator_menu_item_new();
     gtk_menu_append(GTK_MENU(s->view_menu), separator);
 
+    s->grab_item = gtk_check_menu_item_new_with_mnemonic("_Grab Input");
+    gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->grab_item),
+                                 "<QEMU>/View/Grab Input");
+    gtk_accel_map_add_entry("<QEMU>/View/Grab Input", GDK_KEY_g, GDK_CONTROL_MASK | GDK_MOD1_MASK);
+    gtk_menu_append(GTK_MENU(s->view_menu), s->grab_item);
+
+    separator = gtk_separator_menu_item_new();
+    gtk_menu_append(GTK_MENU(s->view_menu), separator);
+
     s->vga_item = gtk_radio_menu_item_new_with_mnemonic(group, "_VGA");
     group = gtk_radio_menu_item_get_group(GTK_RADIO_MENU_ITEM(s->vga_item));
     gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->vga_item),
-- 
1.7.4.1

[Qemu-devel] [PATCH 5/6] gtk: add support for screen scaling and full screen

[Anthony Liguori]

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>
---
 ui/gtk.c |   89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 85 insertions(+), 4 deletions(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index 73051db..b9a9bc3 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -58,6 +58,9 @@ typedef struct GtkDisplayState
 
     GtkWidget *view_menu_item;
     GtkWidget *view_menu;
+    GtkWidget *full_screen_item;
+    GtkWidget *zoom_in_item;
+    GtkWidget *zoom_out_item;
     GtkWidget *grab_item;
     GtkWidget *vga_item;
 
@@ -78,6 +81,7 @@ typedef struct GtkDisplayState
 
     double scale_x;
     double scale_y;
+    gboolean full_screen;
 
     GdkCursor *null_cursor;
     Notifier mouse_mode_notifier;
@@ -102,7 +106,7 @@ static void gd_update_cursor(GtkDisplayState *s, gboolean override)
     on_vga = (gtk_notebook_get_current_page(GTK_NOTEBOOK(s->notebook)) == 0);
 
     if ((override || on_vga) &&
-        (kbd_mouse_is_absolute() || gd_is_grab_active(s))) {
+        (s->full_screen || kbd_mouse_is_absolute() || gd_is_grab_active(s))) {
 	gdk_window_set_cursor(window, s->null_cursor);
     } else {
 	gdk_window_set_cursor(window, NULL);
@@ -194,9 +198,11 @@ static void gd_resize(DisplayState *ds)
                                                      ds->surface->height,
                                                      ds->surface->linesize);
 
-    gtk_widget_set_size_request(s->drawing_area,
-                                ds->surface->width * s->scale_x,
-                                ds->surface->height * s->scale_y);
+    if (!s->full_screen) {
+        gtk_widget_set_size_request(s->drawing_area,
+                                    ds->surface->width * s->scale_x,
+                                    ds->surface->height * s->scale_y);
+    }
 }
 
 /** QEMU Events **/
@@ -453,6 +459,51 @@ static void gd_menu_show_tabs(GtkMenuItem *item, void *opaque)
     }
 }
 
+static void gd_menu_full_screen(GtkMenuItem *item, void *opaque)
+{
+    GtkDisplayState *s = opaque;
+
+    if (gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s->full_screen_item))) {
+        gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s->notebook), FALSE);
+        gtk_widget_set_size_request(s->menu_bar, 0, 0);
+        gtk_widget_set_size_request(s->drawing_area, -1, -1);
+        gtk_window_set_resizable(GTK_WINDOW(s->window), TRUE);
+        gtk_window_fullscreen(GTK_WINDOW(s->window));
+        gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s->grab_item), TRUE);
+        s->full_screen = TRUE;
+    } else {
+        gtk_window_unfullscreen(GTK_WINDOW(s->window));
+        gd_menu_show_tabs(GTK_MENU_ITEM(s->show_tabs_item), s);
+        gtk_widget_set_size_request(s->menu_bar, -1, -1);
+        gtk_widget_set_size_request(s->drawing_area, s->ds->surface->width, s->ds->surface->height);
+        gtk_window_set_resizable(GTK_WINDOW(s->window), FALSE);
+        gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s->grab_item), FALSE);
+        s->full_screen = FALSE;
+    }
+
+    gd_update_cursor(s, FALSE);
+}
+
+static void gd_menu_zoom_in(GtkMenuItem *item, void *opaque)
+{
+    GtkDisplayState *s = opaque;
+
+    s->scale_x *= 1.25;
+    s->scale_y *= 1.25;
+
+    gd_resize(s->ds);
+}
+
+static void gd_menu_zoom_out(GtkMenuItem *item, void *opaque)
+{
+    GtkDisplayState *s = opaque;
+
+    s->scale_x *= .75;
+    s->scale_y *= .75;
+
+    gd_resize(s->ds);
+}
+
 static void gd_menu_grab_input(GtkMenuItem *item, void *opaque)
 {
     GtkDisplayState *s = opaque;
@@ -495,6 +546,9 @@ static void gd_change_page(GtkNotebook *nb, gpointer arg1, guint arg2,
     if (!on_vga) {
         gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s->grab_item),
                                        FALSE);
+    } else if (s->full_screen) {
+        gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s->grab_item),
+                                       TRUE);
     }
 
     gtk_widget_set_sensitive(s->grab_item, on_vga);
@@ -647,6 +701,12 @@ static void gd_connect_signals(GtkDisplayState *s)
 
     g_signal_connect(s->quit_item, "activate",
                      G_CALLBACK(gd_menu_quit), s);
+    g_signal_connect(s->full_screen_item, "activate",
+                     G_CALLBACK(gd_menu_full_screen), s);
+    g_signal_connect(s->zoom_in_item, "activate",
+                     G_CALLBACK(gd_menu_zoom_in), s);
+    g_signal_connect(s->zoom_out_item, "activate",
+                     G_CALLBACK(gd_menu_zoom_out), s);
     g_signal_connect(s->vga_item, "activate",
                      G_CALLBACK(gd_menu_switch_vc), s);
     g_signal_connect(s->grab_item, "activate",
@@ -678,6 +738,27 @@ static void gd_create_menus(GtkDisplayState *s)
     gtk_menu_set_accel_group(GTK_MENU(s->view_menu), accel_group);
     s->view_menu_item = gtk_menu_item_new_with_mnemonic("_View");
 
+    s->full_screen_item = gtk_check_menu_item_new_with_mnemonic("_Full Screen");
+    gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->full_screen_item),
+                                 "<QEMU>/View/Full Screen");
+    gtk_accel_map_add_entry("<QEMU>/View/Full Screen", GDK_KEY_f, GDK_CONTROL_MASK | GDK_MOD1_MASK);
+    gtk_menu_append(GTK_MENU(s->view_menu), s->full_screen_item);
+
+    separator = gtk_separator_menu_item_new();
+    gtk_menu_append(GTK_MENU(s->view_menu), separator);
+
+    s->zoom_in_item = gtk_image_menu_item_new_from_stock(GTK_STOCK_ZOOM_IN, NULL);
+    gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->zoom_in_item),
+                                 "<QEMU>/View/Zoom In");
+    gtk_accel_map_add_entry("<QEMU>/View/Zoom In", GDK_KEY_equal, GDK_CONTROL_MASK | GDK_MOD1_MASK);
+    gtk_menu_append(GTK_MENU(s->view_menu), s->zoom_in_item);
+
+    s->zoom_out_item = gtk_image_menu_item_new_from_stock(GTK_STOCK_ZOOM_OUT, NULL);
+    gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->zoom_out_item),
+                                 "<QEMU>/View/Zoom Out");
+    gtk_accel_map_add_entry("<QEMU>/View/Zoom Out", GDK_KEY_minus, GDK_CONTROL_MASK | GDK_MOD1_MASK);
+    gtk_menu_append(GTK_MENU(s->view_menu), s->zoom_out_item);
+
     separator = gtk_separator_menu_item_new();
     gtk_menu_append(GTK_MENU(s->view_menu), separator);
 
-- 
1.7.4.1

[Qemu-devel] [PATCH 6/6] gtk: make default UI

[Anthony Liguori]

A user can still enable SDL with '-sdl' or '-display sdl' but start making the
default display GTK by default.

I'd also like to deprecate the SDL display and remove it in a few releases.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 vl.c |   38 ++++++++++++++++++++++++--------------
 1 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/vl.c b/vl.c
index d8a521a..ad0b726 100644
--- a/vl.c
+++ b/vl.c
@@ -3220,6 +3220,25 @@ int main(int argc, char **argv, char **envp)
             add_device_config(DEV_VIRTCON, "vc:80Cx24C");
     }
 
+    if (display_type == DT_DEFAULT) {
+#if defined(CONFIG_GTK)
+        display_type = DT_GTK;
+#elif defined(CONFIG_SDL) || defined(CONFIG_COCOA)
+        display_type = DT_SDL;
+#elif defined(CONFIG_VNC)
+        vnc_display = "localhost:0,to=99";
+        show_vnc_port = 1;
+#else
+        display_type = DT_NONE;
+#endif
+    }
+
+#if defined(CONFIG_GTK)
+    if (display_type == DT_GTK) {
+        early_gtk_display_init();
+    }
+#endif
+
     socket_init();
 
     if (qemu_opts_foreach(qemu_find_opts("chardev"), chardev_init_func, NULL, 1) != 0)
@@ -3418,20 +3437,6 @@ int main(int argc, char **argv, char **envp)
     /* just use the first displaystate for the moment */
     ds = get_displaystate();
 
-    if (using_spice)
-        display_remote++;
-    if (display_type == DT_DEFAULT && !display_remote) {
-#if defined(CONFIG_SDL) || defined(CONFIG_COCOA)
-        display_type = DT_SDL;
-#elif defined(CONFIG_VNC)
-        vnc_display = "localhost:0,to=99";
-        show_vnc_port = 1;
-#else
-        display_type = DT_NONE;
-#endif
-    }
-
-
     /* init local displays */
     switch (display_type) {
     case DT_NOGRAPHIC:
@@ -3450,6 +3455,11 @@ int main(int argc, char **argv, char **envp)
         cocoa_display_init(ds, full_screen);
         break;
 #endif
+#if defined(CONFIG_GTK)
+    case DT_GTK:
+        gtk_display_init(ds);
+        break;
+#endif
     default:
         break;
     }
-- 
1.7.4.1

Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Anthony Liguori]

Some screen shots:

http://www.codemonkey.ws/files/qemu-gtk/

Regards,

Anthony Liguori

On 02/19/2012 05:44 PM, Anthony Liguori wrote:
> Hi,
>
> I realize UIs are the third rail of QEMU development, but over the years I've
> gotten a lot of feedback from users about our UI.  I think everyone struggles
> with the SDL interface and its lack of discoverability but it's worse than I
> think most people realize for users that rely on accessibility tools.
>
> The two pieces of feedback I've gotten the most re: accessibility are the lack
> of QEMU's enablement for screen readers and the lack of configurable
> accelerators.
>
> Since we render our own terminal using a fixed sized font, we don't respect
> system font settings which means we ignore if the user has configured large
> print.
>
> We also don't integrate at all with screen readers which means that for blind
> users, the virtual consoles may as well not even exist.
>
> We also don't allow any type of configuration of accelerators.  For users with
> limited dexterity (this is actually more common than you would think), they may
> use an input device that only inputs one key at a time.  Holding down two keys
> at once is not possible for these users.
>
> These are solved problems though and while we could reinvent all of this
> ourselves with SDL, we would be crazy if we did.  Modern toolkits, like GTK,
> solve these problems.
>
> By using GTK, we can leverage VteTerminal for screen reader integration and font
> configuration.  We can also use GTK's accelerator support to make accelerators
> configurable (Gnome provides a global accelerator configuration interface).
>
> I'm not attempting to make a pretty desktop virtualization UI.  Maybe we'll go
> there eventually but that's not what this series is about.
>
> This is just attempting to use a richer toolkit such that we can enable basic
> accessibility support.  As a consequence, the UI is much more usable even for a
> user without accessibility requirements so it's a win-win.
>
>

Re: [Qemu-devel] [PATCH 4/6] gtk: add support for input grabbing

[Anthony Liguori]

On 02/19/2012 05:45 PM, Anthony Liguori wrote:
> 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>
> ---
>   ui/gtk.c |  102 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>   1 files changed, 98 insertions(+), 4 deletions(-)
>
> diff --git a/ui/gtk.c b/ui/gtk.c
> index bf65a4f..73051db 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
> @@ -58,6 +58,7 @@ typedef struct GtkDisplayState
>
>       GtkWidget *view_menu_item;
>       GtkWidget *view_menu;
> +    GtkWidget *grab_item;
>       GtkWidget *vga_item;
>
>       int nb_vcs;
> @@ -86,6 +87,11 @@ static GtkDisplayState *global_state;
>
>   /** Utility Functions **/
>
> +static bool gd_is_grab_active(GtkDisplayState *s)
> +{
> +    return gtk_check_menu_item_get_active(GTK_CHECK_MENU_ITEM(s->grab_item));
> +}
> +
>   static void gd_update_cursor(GtkDisplayState *s, gboolean override)
>   {
>       GdkWindow *window;
> @@ -95,7 +101,8 @@ static void gd_update_cursor(GtkDisplayState *s, gboolean override)
>
>       on_vga = (gtk_notebook_get_current_page(GTK_NOTEBOOK(s->notebook)) == 0);
>
> -    if ((override || on_vga)&&  kbd_mouse_is_absolute()) {
> +    if ((override || on_vga)&&
> +        (kbd_mouse_is_absolute() || gd_is_grab_active(s))) {
>   	gdk_window_set_cursor(window, s->null_cursor);
>       } else {
>   	gdk_window_set_cursor(window, NULL);
> @@ -106,15 +113,20 @@ static void gd_update_caption(GtkDisplayState *s)
>   {
>       const char *status = "";
>       gchar *title;
> +    const char *grab = "";
> +
> +    if (gd_is_grab_active(s)) {
> +        grab = " - Press Ctrl+Alt+G to release grab";
> +    }
>
>       if (!runstate_is_running()) {
>           status = " [Stopped]";
>       }
>
>       if (qemu_name) {
> -        title = g_strdup_printf("QEMU (%s)%s", qemu_name, status);
> +        title = g_strdup_printf("QEMU (%s)%s%s", qemu_name, status, grab);
>       } else {
> -        title = g_strdup_printf("QEMU%s", status);
> +        title = g_strdup_printf("QEMU%s%s", status, grab);
>       }
>
>       gtk_window_set_title(GTK_WINDOW(s->window), title);
> @@ -288,10 +300,44 @@ static gboolean gd_motion_event(GtkWidget *widget, GdkEventMotion *motion,
>       s->last_x = x;
>       s->last_y = y;
>
> -    if (kbd_mouse_is_absolute()) {
> +    if (kbd_mouse_is_absolute() || gd_is_grab_active(s)) {
>           kbd_mouse_event(dx, dy, 0, s->button_mask);
>       }
>
> +    if (!kbd_mouse_is_absolute()&&  gd_is_grab_active(s)) {
> +        GdkDrawable *drawable = GDK_DRAWABLE(gtk_widget_get_window(s->drawing_area));
> +        GdkDisplay *display = gdk_drawable_get_display(drawable);
> +        GdkScreen *screen = gdk_drawable_get_screen(drawable);
> +        int x = (int)motion->x_root;
> +        int y = (int)motion->y_root;
> +
> +        /* In relative mode check to see if client pointer hit
> +         * one of the screen edges, and if so move it back by
> +         * 200 pixels. This is important because the pointer
> +         * in the server doesn't correspond 1-for-1, and so
> +         * may still be only half way across the screen. Without
> +         * this warp, the server pointer would thus appear to hit
> +         * an invisible wall */
> +        if (x == 0) {
> +            x += 200;
> +        }
> +        if (y == 0) {
> +            y += 200;
> +        }
> +        if (x == (gdk_screen_get_width(screen) - 1)) {
> +            x -= 200;
> +        }
> +        if (y == (gdk_screen_get_height(screen) - 1)) {
> +            y -= 200;
> +        }
> +
> +        if (x != (int)motion->x_root || y != (int)motion->y_root) {
> +            gdk_display_warp_pointer(display, screen, x, y);
> +            s->last_x = -1;
> +            s->last_y = -1;
> +            return FALSE;
> +        }

This clause is almost verbatim from gtk-vnc.  The long helpful comment indicates 
that it probably wasn't written by me :-)

I'll throw in the gtk-vnc copyright statement in the next round.

Regards,

Anthony Liguori

> +    }
>       return TRUE;
>   }
>
> @@ -407,15 +453,52 @@ static void gd_menu_show_tabs(GtkMenuItem *item, void *opaque)
>       }
>   }
>
> +static void gd_menu_grab_input(GtkMenuItem *item, void *opaque)
> +{
> +    GtkDisplayState *s = opaque;
> +
> +    if (gd_is_grab_active(s)) {
> +	gdk_keyboard_grab(gtk_widget_get_window(GTK_WIDGET(s->drawing_area)),
> +			  FALSE,
> +			  GDK_CURRENT_TIME);
> +	gdk_pointer_grab(gtk_widget_get_window(GTK_WIDGET(s->drawing_area)),
> +			 FALSE, /* All events to come to our window directly */
> +			 GDK_POINTER_MOTION_MASK |
> +			 GDK_BUTTON_PRESS_MASK |
> +			 GDK_BUTTON_RELEASE_MASK |
> +			 GDK_BUTTON_MOTION_MASK |
> +			 GDK_SCROLL_MASK,
> +			 NULL, /* Allow cursor to move over entire desktop */
> +                         s->null_cursor,
> +			 GDK_CURRENT_TIME);
> +    } else {
> +	gdk_keyboard_ungrab(GDK_CURRENT_TIME);
> +	gdk_pointer_ungrab(GDK_CURRENT_TIME);
> +    }
> +
> +    gd_update_caption(s);
> +    gd_update_cursor(s, FALSE);
> +}
> +
>   static void gd_change_page(GtkNotebook *nb, gpointer arg1, guint arg2,
>                              gpointer data)
>   {
>       GtkDisplayState *s = data;
> +    gboolean on_vga;
>
>       if (!gtk_widget_get_realized(s->notebook)) {
>           return;
>       }
>
> +    on_vga = arg2 == 0;
> +
> +    if (!on_vga) {
> +        gtk_check_menu_item_set_active(GTK_CHECK_MENU_ITEM(s->grab_item),
> +                                       FALSE);
> +    }
> +
> +    gtk_widget_set_sensitive(s->grab_item, on_vga);
> +
>       gd_update_cursor(s, TRUE);
>   }
>
> @@ -566,6 +649,8 @@ static void gd_connect_signals(GtkDisplayState *s)
>                        G_CALLBACK(gd_menu_quit), s);
>       g_signal_connect(s->vga_item, "activate",
>                        G_CALLBACK(gd_menu_switch_vc), s);
> +    g_signal_connect(s->grab_item, "activate",
> +                     G_CALLBACK(gd_menu_grab_input), s);
>       g_signal_connect(s->notebook, "switch-page",
>                        G_CALLBACK(gd_change_page), s);
>   }
> @@ -596,6 +681,15 @@ static void gd_create_menus(GtkDisplayState *s)
>       separator = gtk_separator_menu_item_new();
>       gtk_menu_append(GTK_MENU(s->view_menu), separator);
>
> +    s->grab_item = gtk_check_menu_item_new_with_mnemonic("_Grab Input");
> +    gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->grab_item),
> +                                 "<QEMU>/View/Grab Input");
> +    gtk_accel_map_add_entry("<QEMU>/View/Grab Input", GDK_KEY_g, GDK_CONTROL_MASK | GDK_MOD1_MASK);
> +    gtk_menu_append(GTK_MENU(s->view_menu), s->grab_item);
> +
> +    separator = gtk_separator_menu_item_new();
> +    gtk_menu_append(GTK_MENU(s->view_menu), separator);
> +
>       s->vga_item = gtk_radio_menu_item_new_with_mnemonic(group, "_VGA");
>       group = gtk_radio_menu_item_get_group(GTK_RADIO_MENU_ITEM(s->vga_item));
>       gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->vga_item),

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Roy Tam]

2012/2/20 Anthony Liguori <aliguori@us.ibm.com>:
> A user can still enable SDL with '-sdl' or '-display sdl' but start making the
> default display GTK by default.
>
> I'd also like to deprecate the SDL display and remove it in a few releases.
>

So, will a win32 native UI be written? If not, it will be nice to keep
SDL because GTK huge and not that portable for win32 users. (Live
example is FreeArc(GTK) vs PeaZip(QT))

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Anthony Liguori]

On 02/19/2012 06:15 PM, Roy Tam wrote:
> 2012/2/20 Anthony Liguori<aliguori@us.ibm.com>:
>> A user can still enable SDL with '-sdl' or '-display sdl' but start making the
>> default display GTK by default.
>>
>> I'd also like to deprecate the SDL display and remove it in a few releases.
>>
>
> So, will a win32 native UI be written?

Certainly not by me :-)  It sounds easy to do but it's not.  I don't know of a 
widely available terminal widget for Windows.  Also, when you look at this GTK 
UI, there's not a whole lot different in terms of what a Windows UI would look like.

> If not, it will be nice to keep
> SDL because GTK huge and not that portable for win32 users.

Neither are true.  GTK is a reasonably small dependency especially given that 
GLIB is a mandatory dependency.  I can't imagine that in terms of binary size, 
libsdl is much bigger than gtk/gdk.

And Windows is extremely well supported by GTK so the portability comment is 
incorrect.

> (Live
> example is FreeArc(GTK) vs PeaZip(QT))

I don't view QT as an option for a couple reasons.  KDE is a second class 
citizen in Linux.  Most distributions default to Gnome these days and GTK is the 
toolkit of choice.

QT is also primarily a C++ framework, not a C framework.  We already make use of 
glib and GTK integration with a glib application is super easy and nice.  QT 
integration would be much less natural.

But I'm not attempting to remove anything in this series.  Let's see how things 
actually work and then in a couple releases, we can make decisions about SDL and 
what to do with other platforms.

I'd prefer to have a single UI but I'm not in a position to rule out platform 
specific UIs at the moment.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Roy Tam]

2012/2/20 Anthony Liguori <anthony@codemonkey.ws>:
> On 02/19/2012 06:15 PM, Roy Tam wrote:
>>
>> 2012/2/20 Anthony Liguori<aliguori@us.ibm.com>:
>>>
>>> A user can still enable SDL with '-sdl' or '-display sdl' but start
>>> making the
>>> default display GTK by default.
>>>
>>> I'd also like to deprecate the SDL display and remove it in a few
>>> releases.
>>>
>>
>> So, will a win32 native UI be written?
>
>
> Certainly not by me :-)  It sounds easy to do but it's not.  I don't know of
> a widely available terminal widget for Windows.  Also, when you look at this
> GTK UI, there's not a whole lot different in terms of what a Windows UI
> would look like.
>
>
>> If not, it will be nice to keep
>> SDL because GTK huge and not that portable for win32 users.
>
>
> Neither are true.  GTK is a reasonably small dependency especially given
> that GLIB is a mandatory dependency.  I can't imagine that in terms of
> binary size, libsdl is much bigger than gtk/gdk.

You didn't count pango, cairo, and libpng in. GTK + GDK + cairo +
pango + libpng consume 7.17MB binary size (glib binary is 1.77MB which
doesn't count in as SDL version uses glib too), on the contrary
SDL.dll is single binary and just ~300KB in size
(http://www.libsdl.org/release/SDL-1.2.15-win32.zip).
Not to mention the troublesome of recompiling GTK and its dependencies.

>
> And Windows is extremely well supported by GTK so the portability comment is
> incorrect.
>

I didn't mean the portability of function but portability of binary
(no troublesome and hidden settings, easy to put in USB stick and run
everywhere)

>
>> (Live
>> example is FreeArc(GTK) vs PeaZip(QT))
>
>
> I don't view QT as an option for a couple reasons.  KDE is a second class
> citizen in Linux.  Most distributions default to Gnome these days and GTK is
> the toolkit of choice.
>
> QT is also primarily a C++ framework, not a C framework.  We already make
> use of glib and GTK integration with a glib application is super easy and
> nice.  QT integration would be much less natural.
>
> But I'm not attempting to remove anything in this series.  Let's see how
> things actually work and then in a couple releases, we can make decisions
> about SDL and what to do with other platforms.
>
> I'd prefer to have a single UI but I'm not in a position to rule out
> platform specific UIs at the moment.
>
> Regards,
>
> Anthony Liguori
>
>

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

On Feb 19, 2012 7:50 PM, "Roy Tam" <roytam@gmail.com> wrote:
>
> 2012/2/20 Anthony Liguori <anthony@codemonkey.ws>:
> > On 02/19/2012 06:15 PM, Roy Tam wrote:
> >>
> >> 2012/2/20 Anthony Liguori<aliguori@us.ibm.com>:
> >>>
> >>> A user can still enable SDL with '-sdl' or '-display sdl' but start
> >>> making the
> >>> default display GTK by default.
> >>>
> >>> I'd also like to deprecate the SDL display and remove it in a few
> >>> releases.
> >>>
> >>
> >> So, will a win32 native UI be written?
> >
> >
> > Certainly not by me :-)  It sounds easy to do but it's not.  I don't
know of
> > a widely available terminal widget for Windows.  Also, when you look at
this
> > GTK UI, there's not a whole lot different in terms of what a Windows UI
> > would look like.
> >
> >
> >> If not, it will be nice to keep
> >> SDL because GTK huge and not that portable for win32 users.
> >
> >
> > Neither are true.  GTK is a reasonably small dependency especially given
> > that GLIB is a mandatory dependency.  I can't imagine that in terms of
> > binary size, libsdl is much bigger than gtk/gdk.
>
> You didn't count pango, cairo, and libpng in. GTK + GDK + cairo +
> pango + libpng consume 7.17MB binary size (glib binary is 1.77MB which
> doesn't count in as SDL version uses glib too), on the contrary
> SDL.dll is single binary and just ~300KB in size
> (http://www.libsdl.org/release/SDL-1.2.15-win32.zip).
> Not to mention the troublesome of recompiling GTK and its dependencies.

7MB is far from huge.  Having to deal with a few dlls doesn't seem like
much of a burden to me.

>
> >
> > And Windows is extremely well supported by GTK so the portability
comment is
> > incorrect.
> >
>
> I didn't mean the portability of function but portability of binary
> (no troublesome and hidden settings, easy to put in USB stick and run
> everywhere)

Considering that you probably cannot even buy a USB stick smaller than 32MB
today, I don't see the logic here.

Regards,

Anthony Liguori

> >
> >> (Live
> >> example is FreeArc(GTK) vs PeaZip(QT))
> >
> >
> > I don't view QT as an option for a couple reasons.  KDE is a second
class
> > citizen in Linux.  Most distributions default to Gnome these days and
GTK is
> > the toolkit of choice.
> >
> > QT is also primarily a C++ framework, not a C framework.  We already
make
> > use of glib and GTK integration with a glib application is super easy
and
> > nice.  QT integration would be much less natural.
> >
> > But I'm not attempting to remove anything in this series.  Let's see how
> > things actually work and then in a couple releases, we can make
decisions
> > about SDL and what to do with other platforms.
> >
> > I'd prefer to have a single UI but I'm not in a position to rule out
> > platform specific UIs at the moment.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> >

[-- Attachment #2: Type: text/html, Size: 3981 bytes --]

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Brad Smith]

On 19/02/12 8:10 PM, Anthony Liguori wrote:
>> If not, it will be nice to keep
>> SDL because GTK huge and not that portable for win32 users.
>
> Neither are true. GTK is a reasonably small dependency especially given
> that GLIB is a mandatory dependency. I can't imagine that in terms of
> binary size, libsdl is much bigger than gtk/gdk.

Double check your facts. That's not even close to being true.

SDL is a tiny fraction of Gtk+.

Just as an example taking a look at package sizes..

549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries)
excluding Glib2 and what it depends on. Glib2 and dependencies are 14.5MB
(5 libraries). The two in total drag in 12 libraries at 31MBs. That's IMO
a fair bit larger than QEMU itself at 25.9MB.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Anthony Liguori]

On 02/19/2012 08:24 PM, Brad Smith wrote:
> On 19/02/12 8:10 PM, Anthony Liguori wrote:
>>> If not, it will be nice to keep
>>> SDL because GTK huge and not that portable for win32 users.
>>
>> Neither are true. GTK is a reasonably small dependency especially given
>> that GLIB is a mandatory dependency. I can't imagine that in terms of
>> binary size, libsdl is much bigger than gtk/gdk.
>
> Double check your facts. That's not even close to being true.
>
> SDL is a tiny fraction of Gtk+.
>
> Just as an example taking a look at package sizes..
>
> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries)
> excluding Glib2 and what it depends on.

I don't see how 17.3MB qualifies as "huge".

Regards,

Anthony Liguori

  Glib2 and dependencies are 14.5MB
> (5 libraries). The two in total drag in 12 libraries at 31MBs. That's IMO
> a fair bit larger than QEMU itself at 25.9MB.
>

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Roy Tam]

2012/2/20 Anthony Liguori <anthony@codemonkey.ws>:
> On 02/19/2012 08:24 PM, Brad Smith wrote:
>>
>> On 19/02/12 8:10 PM, Anthony Liguori wrote:
>>>>
>>>> If not, it will be nice to keep
>>>> SDL because GTK huge and not that portable for win32 users.
>>>
>>>
>>> Neither are true. GTK is a reasonably small dependency especially given
>>> that GLIB is a mandatory dependency. I can't imagine that in terms of
>>> binary size, libsdl is much bigger than gtk/gdk.
>>
>>
>> Double check your facts. That's not even close to being true.
>>
>> SDL is a tiny fraction of Gtk+.
>>
>> Just as an example taking a look at package sizes..
>>
>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries)
>> excluding Glib2 and what it depends on.
>
>
> I don't see how 17.3MB qualifies as "huge".

You have to compare the SDL library with GTK and its dependencies.
SDL is "small" while 32-times-bigger GTK libraries should qualify as "huge".

>
> Regards,
>
> Anthony Liguori
>
>
>  Glib2 and dependencies are 14.5MB
>>
>> (5 libraries). The two in total drag in 12 libraries at 31MBs. That's IMO
>> a fair bit larger than QEMU itself at 25.9MB.
>>
>

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Brad Smith]

On 19/02/12 9:44 PM, Anthony Liguori wrote:
> On 02/19/2012 08:24 PM, Brad Smith wrote:
>> On 19/02/12 8:10 PM, Anthony Liguori wrote:
>>>> If not, it will be nice to keep
>>>> SDL because GTK huge and not that portable for win32 users.
>>>
>>> Neither are true. GTK is a reasonably small dependency especially given
>>> that GLIB is a mandatory dependency. I can't imagine that in terms of
>>> binary size, libsdl is much bigger than gtk/gdk.
>>
>> Double check your facts. That's not even close to being true.
>>
>> SDL is a tiny fraction of Gtk+.
>>
>> Just as an example taking a look at package sizes..
>>
>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries)
>> excluding Glib2 and what it depends on.
>
> I don't see how 17.3MB qualifies as "huge".

It's FAR from small not to mention dragging in A LOT of libraries for what?
A prettier looking UI?

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Anthony Liguori]

On 02/19/2012 08:52 PM, Brad Smith wrote:
> On 19/02/12 9:44 PM, Anthony Liguori wrote:
>> On 02/19/2012 08:24 PM, Brad Smith wrote:
>>> On 19/02/12 8:10 PM, Anthony Liguori wrote:
>>>>> If not, it will be nice to keep
>>>>> SDL because GTK huge and not that portable for win32 users.
>>>>
>>>> Neither are true. GTK is a reasonably small dependency especially given
>>>> that GLIB is a mandatory dependency. I can't imagine that in terms of
>>>> binary size, libsdl is much bigger than gtk/gdk.
>>>
>>> Double check your facts. That's not even close to being true.
>>>
>>> SDL is a tiny fraction of Gtk+.
>>>
>>> Just as an example taking a look at package sizes..
>>>
>>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries)
>>> excluding Glib2 and what it depends on.
>>
>> I don't see how 17.3MB qualifies as "huge".
>
> It's FAR from small not to mention dragging in A LOT of libraries for what?
> A prettier looking UI?

An accessible UI that meets the most basic definition of usable.  Sit someone 
down with the SDL interface for the first time, how in the world are they 
supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt?

If they somehow figure that out and think to type help in the monitor, they need 
to someone figure out to use Ctrl-PageUp to actually read the help text.

If you don't want to have to worry about dependencies, use an OS that has a 
proper package management system so you don't have to deal with these things.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 5/6] gtk: add support for screen scaling and full screen

[Paolo Bonzini]

On 02/20/2012 12:45 AM, Anthony Liguori wrote:
> +static void gd_menu_zoom_in(GtkMenuItem *item, void *opaque)
> +{
> +    GtkDisplayState *s = opaque;
> +
> +    s->scale_x *= 1.25;
> +    s->scale_y *= 1.25;
> +
> +    gd_resize(s->ds);
> +}
> +
> +static void gd_menu_zoom_out(GtkMenuItem *item, void *opaque)
> +{
> +    GtkDisplayState *s = opaque;
> +
> +    s->scale_x *= .75;
> +    s->scale_y *= .75;

This should be /= 1.25, because the inverse of 1.25 is _not_ 0.75. :)

Paolo

Re: [Qemu-devel] [PATCH 1/6] console: allow VCs to be overridden by UI

[Gerd Hoffmann]

On 02/20/12 00:44, Anthony Liguori wrote:
> We want to expose VCs using a VteTerminal widget.  We need access to provide our
> own CharDriverState in order to do this.

/me wonders why you touch vc's at all for this.  Doesn't it make alot
more sense to just have a -chardev vte (which then opens a new tab in
the ui or something simliar)?

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Kevin Wolf]

Am 20.02.2012 00:44, schrieb Anthony Liguori:
> Hi,
> 
> I realize UIs are the third rail of QEMU development, but over the years I've
> gotten a lot of feedback from users about our UI.  I think everyone struggles
> with the SDL interface and its lack of discoverability but it's worse than I
> think most people realize for users that rely on accessibility tools.
> 
> The two pieces of feedback I've gotten the most re: accessibility are the lack
> of QEMU's enablement for screen readers and the lack of configurable
> accelerators.
> 
> Since we render our own terminal using a fixed sized font, we don't respect
> system font settings which means we ignore if the user has configured large
> print.
> 
> We also don't integrate at all with screen readers which means that for blind
> users, the virtual consoles may as well not even exist.
> 
> We also don't allow any type of configuration of accelerators.  For users with
> limited dexterity (this is actually more common than you would think), they may
> use an input device that only inputs one key at a time.  Holding down two keys
> at once is not possible for these users.
> 
> These are solved problems though and while we could reinvent all of this
> ourselves with SDL, we would be crazy if we did.  Modern toolkits, like GTK,
> solve these problems.
> 
> By using GTK, we can leverage VteTerminal for screen reader integration and font
> configuration.  We can also use GTK's accelerator support to make accelerators
> configurable (Gnome provides a global accelerator configuration interface).
> 
> I'm not attempting to make a pretty desktop virtualization UI.  Maybe we'll go
> there eventually but that's not what this series is about.
> 
> This is just attempting to use a richer toolkit such that we can enable basic
> accessibility support.  As a consequence, the UI is much more usable even for a
> user without accessibility requirements so it's a win-win.

It's not quite obvious what the build dependencies are. In my case I had
to install vte-devel. Especially if we're going to make it the default,
I think configure should print a helpful warning. (In fact, SDL has the
same problem and I have answered too many questions of users that
wondered why no window appeared, not understanding that they built only
VNC).

I think the series is a good start, just some random thoughts and things
that I noticed:

* git complains about some trailing whitespace

* Half of the menu entries appears to be translated by the libraries
  used. Give me something that is all German or something that is all
  English. Mixed languages looks unprofessional.

* Ctrl-Alt-= as shortcut for Zoom In isn't easy to remember and only
  makes some sense on a US keyboard layout.

* The monitor display size always has the same size as the VGA tab now.
  That can be quite small in text mode and you can't resize any more.

* The window has a button for maximising, but it doesn't really do
  anything.

* Ctrl-PgDn/PgUp does change the tab as I expected on VGA, it's ignored
  by the monitor and the serial0 tabs. parallel0 segfaults on any key
  press.

* When the tab bar is enables, the cursor up key in the VGA tab selects
  the tab bar. It also is sent to the guest the first time, but when
  the tab bar is selected, the guest doesn't get any input any more.
  Makes it rather hard to use the shell history in the guest.

Kevin

Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Kevin Wolf]

Am 20.02.2012 13:17, schrieb Kevin Wolf:
> Am 20.02.2012 00:44, schrieb Anthony Liguori:
>> Hi,
>>
>> I realize UIs are the third rail of QEMU development, but over the years I've
>> gotten a lot of feedback from users about our UI.  I think everyone struggles
>> with the SDL interface and its lack of discoverability but it's worse than I
>> think most people realize for users that rely on accessibility tools.
>>
>> The two pieces of feedback I've gotten the most re: accessibility are the lack
>> of QEMU's enablement for screen readers and the lack of configurable
>> accelerators.
>>
>> Since we render our own terminal using a fixed sized font, we don't respect
>> system font settings which means we ignore if the user has configured large
>> print.
>>
>> We also don't integrate at all with screen readers which means that for blind
>> users, the virtual consoles may as well not even exist.
>>
>> We also don't allow any type of configuration of accelerators.  For users with
>> limited dexterity (this is actually more common than you would think), they may
>> use an input device that only inputs one key at a time.  Holding down two keys
>> at once is not possible for these users.
>>
>> These are solved problems though and while we could reinvent all of this
>> ourselves with SDL, we would be crazy if we did.  Modern toolkits, like GTK,
>> solve these problems.
>>
>> By using GTK, we can leverage VteTerminal for screen reader integration and font
>> configuration.  We can also use GTK's accelerator support to make accelerators
>> configurable (Gnome provides a global accelerator configuration interface).
>>
>> I'm not attempting to make a pretty desktop virtualization UI.  Maybe we'll go
>> there eventually but that's not what this series is about.
>>
>> This is just attempting to use a richer toolkit such that we can enable basic
>> accessibility support.  As a consequence, the UI is much more usable even for a
>> user without accessibility requirements so it's a win-win.
> 
> It's not quite obvious what the build dependencies are. In my case I had
> to install vte-devel. Especially if we're going to make it the default,
> I think configure should print a helpful warning. (In fact, SDL has the
> same problem and I have answered too many questions of users that
> wondered why no window appeared, not understanding that they built only
> VNC).
> 
> I think the series is a good start, just some random thoughts and things
> that I noticed:
> 
> * git complains about some trailing whitespace
> 
> * Half of the menu entries appears to be translated by the libraries
>   used. Give me something that is all German or something that is all
>   English. Mixed languages looks unprofessional.
> 
> * Ctrl-Alt-= as shortcut for Zoom In isn't easy to remember and only
>   makes some sense on a US keyboard layout.
> 
> * The monitor display size always has the same size as the VGA tab now.
>   That can be quite small in text mode and you can't resize any more.
> 
> * The window has a button for maximising, but it doesn't really do
>   anything.
> 
> * Ctrl-PgDn/PgUp does change the tab as I expected on VGA, it's ignored
>   by the monitor and the serial0 tabs. parallel0 segfaults on any key
>   press.
> 
> * When the tab bar is enables, the cursor up key in the VGA tab selects
>   the tab bar. It also is sent to the guest the first time, but when
>   the tab bar is selected, the guest doesn't get any input any more.
>   Makes it rather hard to use the shell history in the guest.

There's more fun...

* The F10 key activates the menu instead of being passed to the guest.
  Just like cursor up even when the keyboard is grabbed. Makes sendkey
  close to the primary interface for keyboard. :-(

* On one start something went wrong, apparently with the zoom (at least
  I saw for a moment how half a letter was rendered over the whole
  screen). Hung my machine until the OOM killer came to the rescue...

Kevin

Re: [Qemu-devel] [PATCH 1/6] console: allow VCs to be overridden by UI

[Anthony Liguori]

On 02/20/2012 03:17 AM, Gerd Hoffmann wrote:
> On 02/20/12 00:44, Anthony Liguori wrote:
>> We want to expose VCs using a VteTerminal widget.  We need access to provide our
>> own CharDriverState in order to do this.
>
> /me wonders why you touch vc's at all for this.  Doesn't it make alot
> more sense to just have a -chardev vte (which then opens a new tab in
> the ui or something simliar)?

Does it?  That's essentially exactly what -chardev vc does today.  vc currently 
works across all UIs (VNC, SDL, etc).  It seems a bit odd to me to have to use a 
different argument for the GTK UI.

Regards,

Anthony Liguori

>
> cheers,
>    Gerd
>
>

Re: [Qemu-devel] [PATCH 5/6] gtk: add support for screen scaling and full screen

[Anthony Liguori]

On 02/20/2012 01:41 AM, Paolo Bonzini wrote:
> On 02/20/2012 12:45 AM, Anthony Liguori wrote:
>> +static void gd_menu_zoom_in(GtkMenuItem *item, void *opaque)
>> +{
>> +    GtkDisplayState *s = opaque;
>> +
>> +    s->scale_x *= 1.25;
>> +    s->scale_y *= 1.25;
>> +
>> +    gd_resize(s->ds);
>> +}
>> +
>> +static void gd_menu_zoom_out(GtkMenuItem *item, void *opaque)
>> +{
>> +    GtkDisplayState *s = opaque;
>> +
>> +    s->scale_x *= .75;
>> +    s->scale_y *= .75;
>
> This should be /= 1.25, because the inverse of 1.25 is _not_ 0.75. :)

Indeed, thanks :-)

Regards,

Anthony Liguori

>
> Paolo
>

Re: [Qemu-devel] [PATCH 1/6] console: allow VCs to be overridden by UI

[Gerd Hoffmann]

On 02/20/12 14:45, Anthony Liguori wrote:
> On 02/20/2012 03:17 AM, Gerd Hoffmann wrote:
>> On 02/20/12 00:44, Anthony Liguori wrote:
>>> We want to expose VCs using a VteTerminal widget.  We need access to
>>> provide our
>>> own CharDriverState in order to do this.
>>
>> /me wonders why you touch vc's at all for this.  Doesn't it make alot
>> more sense to just have a -chardev vte (which then opens a new tab in
>> the ui or something simliar)?
> 
> Does it?  That's essentially exactly what -chardev vc does today.  vc
> currently works across all UIs (VNC, SDL, etc).

They all use the qemu terminal emulation and render the chars on a
displaysurface.

> It seems a bit odd to
> me to have to use a different argument for the GTK UI.

Why is this odd?  gtk *is* different, it takes the character stream and
sends them off to the terminal emulation widget.  That allows to do
stuff vc can't handle by design, for example placing vte in a new window
instead of a tab so you can watch vga and serial console side-by-side.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Anthony Liguori]

On 02/20/2012 06:17 AM, Kevin Wolf wrote:
> Am 20.02.2012 00:44, schrieb Anthony Liguori:
>> I'm not attempting to make a pretty desktop virtualization UI.  Maybe we'll go
>> there eventually but that's not what this series is about.
>>
>> This is just attempting to use a richer toolkit such that we can enable basic
>> accessibility support.  As a consequence, the UI is much more usable even for a
>> user without accessibility requirements so it's a win-win.
>
> It's not quite obvious what the build dependencies are. In my case I had
> to install vte-devel. Especially if we're going to make it the default,
> I think configure should print a helpful warning. (In fact, SDL has the
> same problem and I have answered too many questions of users that
> wondered why no window appeared, not understanding that they built only
> VNC).

Ok, I'll try to do something here.

> I think the series is a good start, just some random thoughts and things
> that I noticed:
>
> * git complains about some trailing whitespace

Ack.

> * Half of the menu entries appears to be translated by the libraries
>    used. Give me something that is all German or something that is all
>    English. Mixed languages looks unprofessional.

This is because of the use of stock items.  I can overload the labels and force 
english menu names.  I can also add some basic internationalization and make 
greater use of stock item names.

I would actually prefer the later approach although practically speaking, the 
monitor would remain in English.  Would this seem awkward?

What's preferable for non-native English speakers?

> * Ctrl-Alt-= as shortcut for Zoom In isn't easy to remember and only
>    makes some sense on a US keyboard layout.

There doesn't appear to be a stock accelerator for Zoom in GTK.  Firefox 
advertises Ctrl-+ as the zoom in accelerator but apparently accepts Ctrl-+ or 
Ctrl-=.

I'd be happy with just doing Ctrl-Alt-+.  It's a little more awkward to type but 
that seems to be the standard.

> * The monitor display size always has the same size as the VGA tab now.
>    That can be quite small in text mode and you can't resize any more.

This should be fixable.  It will just take a little logic.

> * The window has a button for maximising, but it doesn't really do
>    anything.

This is your Window Manager.  We call gtk_window_set_resizable(False) and that 
should cause the maximize button to disappear.  Indeed, if you look at the 
screenshots I posted, there isn't a maximize button.

> * Ctrl-PgDn/PgUp does change the tab as I expected on VGA, it's ignored
>    by the monitor and the serial0 tabs.

This is something that probably needs some work.  Right now we propagate all key 
presses which is what allows the accelerators to work.  What we probably should 
do is check the key presses against only the accelerators we want to work and 
propagate those.

This is a bit tricky though.  The end effect would be that Ctrl-PgDn would stop 
working on the VGA tab.  I think this is expected behavior.

> parallel0 segfaults on any key
>    press.

Curious, I'll look into this.

>
> * When the tab bar is enables, the cursor up key in the VGA tab selects
>    the tab bar. It also is sent to the guest the first time, but when
>    the tab bar is selected, the guest doesn't get any input any more.
>    Makes it rather hard to use the shell history in the guest.

Yeah, this is the result of always propagating key presses.  I'll look into this 
a bit more.

Thanks for the feedback!

Regards,

Anthony Liguori

>
> Kevin
>

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Stefano Stabellini]

On Mon, 20 Feb 2012, Anthony Liguori wrote:
> On 02/19/2012 08:52 PM, Brad Smith wrote:
> > On 19/02/12 9:44 PM, Anthony Liguori wrote:
> >> On 02/19/2012 08:24 PM, Brad Smith wrote:
> >>> On 19/02/12 8:10 PM, Anthony Liguori wrote:
> >>>>> If not, it will be nice to keep
> >>>>> SDL because GTK huge and not that portable for win32 users.
> >>>>
> >>>> Neither are true. GTK is a reasonably small dependency especially given
> >>>> that GLIB is a mandatory dependency. I can't imagine that in terms of
> >>>> binary size, libsdl is much bigger than gtk/gdk.
> >>>
> >>> Double check your facts. That's not even close to being true.
> >>>
> >>> SDL is a tiny fraction of Gtk+.
> >>>
> >>> Just as an example taking a look at package sizes..
> >>>
> >>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries)
> >>> excluding Glib2 and what it depends on.
> >>
> >> I don't see how 17.3MB qualifies as "huge".
> >
> > It's FAR from small not to mention dragging in A LOT of libraries for what?
> > A prettier looking UI?
> 
> An accessible UI that meets the most basic definition of usable.  Sit someone 
> down with the SDL interface for the first time, how in the world are they 
> supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt?

I think that having a GTK UI is quite important for QEMU and having it
be the default is also a good idea.

BUT we should not deprecate and plan to remove SDL.

Do we really want to force everybody that uses QEMU on X11 to compile
the entire set of GTK dependencies?
Keep in mind that QEMU is not just used on Linux distros but it also
used as a component in other projects that might have very different
constraints.
I think that having a lightweight graphical UI with very few and small
dependencies is NOT something we should give up.

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Anthony Liguori]

On 02/20/2012 08:06 AM, Stefano Stabellini wrote:
> On Mon, 20 Feb 2012, Anthony Liguori wrote:
>> On 02/19/2012 08:52 PM, Brad Smith wrote:
>>> On 19/02/12 9:44 PM, Anthony Liguori wrote:
>>>> On 02/19/2012 08:24 PM, Brad Smith wrote:
>>>>> On 19/02/12 8:10 PM, Anthony Liguori wrote:
>>>>>>> If not, it will be nice to keep
>>>>>>> SDL because GTK huge and not that portable for win32 users.
>>>>>>
>>>>>> Neither are true. GTK is a reasonably small dependency especially given
>>>>>> that GLIB is a mandatory dependency. I can't imagine that in terms of
>>>>>> binary size, libsdl is much bigger than gtk/gdk.
>>>>>
>>>>> Double check your facts. That's not even close to being true.
>>>>>
>>>>> SDL is a tiny fraction of Gtk+.
>>>>>
>>>>> Just as an example taking a look at package sizes..
>>>>>
>>>>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries)
>>>>> excluding Glib2 and what it depends on.
>>>>
>>>> I don't see how 17.3MB qualifies as "huge".
>>>
>>> It's FAR from small not to mention dragging in A LOT of libraries for what?
>>> A prettier looking UI?
>>
>> An accessible UI that meets the most basic definition of usable.  Sit someone
>> down with the SDL interface for the first time, how in the world are they
>> supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt?
>
> I think that having a GTK UI is quite important for QEMU and having it
> be the default is also a good idea.
>
> BUT we should not deprecate and plan to remove SDL.

Actually, I think Cairo can be a better SDL than SDL.

It doesn't have the same level of backend support (or input support) as SDL 
does, but it can render to Win32, Quartz, and a raw X11 window.

> Do we really want to force everybody that uses QEMU on X11 to compile
> the entire set of GTK dependencies?
> Keep in mind that QEMU is not just used on Linux distros but it also
> used as a component in other projects that might have very different
> constraints.
> I think that having a lightweight graphical UI with very few and small
> dependencies is NOT something we should give up.

If we went in a different direction with SDL, I wouldn't mind it so much.  For 
instance, removing the console emulation and reducing the use of magic accelerators.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Anthony Liguori]

On 02/20/2012 06:47 AM, Kevin Wolf wrote:
> Am 20.02.2012 13:17, schrieb Kevin Wolf:
>> Am 20.02.2012 00:44, schrieb Anthony Liguori:
>>> Hi,
>>>
>>> I realize UIs are the third rail of QEMU development, but over the years I've
>>> gotten a lot of feedback from users about our UI.  I think everyone struggles
>>> with the SDL interface and its lack of discoverability but it's worse than I
>>> think most people realize for users that rely on accessibility tools.
>>>
>>> The two pieces of feedback I've gotten the most re: accessibility are the lack
>>> of QEMU's enablement for screen readers and the lack of configurable
>>> accelerators.
>>>
>>> Since we render our own terminal using a fixed sized font, we don't respect
>>> system font settings which means we ignore if the user has configured large
>>> print.
>>>
>>> We also don't integrate at all with screen readers which means that for blind
>>> users, the virtual consoles may as well not even exist.
>>>
>>> We also don't allow any type of configuration of accelerators.  For users with
>>> limited dexterity (this is actually more common than you would think), they may
>>> use an input device that only inputs one key at a time.  Holding down two keys
>>> at once is not possible for these users.
>>>
>>> These are solved problems though and while we could reinvent all of this
>>> ourselves with SDL, we would be crazy if we did.  Modern toolkits, like GTK,
>>> solve these problems.
>>>
>>> By using GTK, we can leverage VteTerminal for screen reader integration and font
>>> configuration.  We can also use GTK's accelerator support to make accelerators
>>> configurable (Gnome provides a global accelerator configuration interface).
>>>
>>> I'm not attempting to make a pretty desktop virtualization UI.  Maybe we'll go
>>> there eventually but that's not what this series is about.
>>>
>>> This is just attempting to use a richer toolkit such that we can enable basic
>>> accessibility support.  As a consequence, the UI is much more usable even for a
>>> user without accessibility requirements so it's a win-win.
>>
>> It's not quite obvious what the build dependencies are. In my case I had
>> to install vte-devel. Especially if we're going to make it the default,
>> I think configure should print a helpful warning. (In fact, SDL has the
>> same problem and I have answered too many questions of users that
>> wondered why no window appeared, not understanding that they built only
>> VNC).
>>
>> I think the series is a good start, just some random thoughts and things
>> that I noticed:
>>
>> * git complains about some trailing whitespace
>>
>> * Half of the menu entries appears to be translated by the libraries
>>    used. Give me something that is all German or something that is all
>>    English. Mixed languages looks unprofessional.
>>
>> * Ctrl-Alt-= as shortcut for Zoom In isn't easy to remember and only
>>    makes some sense on a US keyboard layout.
>>
>> * The monitor display size always has the same size as the VGA tab now.
>>    That can be quite small in text mode and you can't resize any more.
>>
>> * The window has a button for maximising, but it doesn't really do
>>    anything.
>>
>> * Ctrl-PgDn/PgUp does change the tab as I expected on VGA, it's ignored
>>    by the monitor and the serial0 tabs. parallel0 segfaults on any key
>>    press.
>>
>> * When the tab bar is enables, the cursor up key in the VGA tab selects
>>    the tab bar. It also is sent to the guest the first time, but when
>>    the tab bar is selected, the guest doesn't get any input any more.
>>    Makes it rather hard to use the shell history in the guest.
>
> There's more fun...
>
> * The F10 key activates the menu instead of being passed to the guest.
>    Just like cursor up even when the keyboard is grabbed. Makes sendkey
>    close to the primary interface for keyboard. :-(

Yes, this is all because of return TRUE on keyboard handling.

> * On one start something went wrong, apparently with the zoom (at least
>    I saw for a moment how half a letter was rendered over the whole
>    screen). Hung my machine until the OOM killer came to the rescue...

Interesting, will look into this.

Regards,

Anthony Liguori

> Kevin
>

Re: [Qemu-devel] [PATCH 1/6] console: allow VCs to be overridden by UI

[Anthony Liguori]

On 02/20/2012 07:59 AM, Gerd Hoffmann wrote:
> On 02/20/12 14:45, Anthony Liguori wrote:
>> On 02/20/2012 03:17 AM, Gerd Hoffmann wrote:
>>> On 02/20/12 00:44, Anthony Liguori wrote:
>>>> We want to expose VCs using a VteTerminal widget.  We need access to
>>>> provide our
>>>> own CharDriverState in order to do this.
>>>
>>> /me wonders why you touch vc's at all for this.  Doesn't it make alot
>>> more sense to just have a -chardev vte (which then opens a new tab in
>>> the ui or something simliar)?
>>
>> Does it?  That's essentially exactly what -chardev vc does today.  vc
>> currently works across all UIs (VNC, SDL, etc).
>
> They all use the qemu terminal emulation and render the chars on a
> displaysurface.
>
>> It seems a bit odd to
>> me to have to use a different argument for the GTK UI.
>
> Why is this odd?  gtk *is* different, it takes the character stream and
> sends them off to the terminal emulation widget.  That allows to do
> stuff vc can't handle by design, for example placing vte in a new window
> instead of a tab so you can watch vga and serial console side-by-side.

This would require touching a fair bit of code that handles things like 
defaults.  I'm not sure that having the distinction makes anything easier to 
implement.

One thing I was contemplating but ultimately didn't do was QOM-ification of the 
GTK front end.  I couldn't rationalize why you would need to set settings but 
now I think maybe it would be more useful.

So I'll take a pass in the next series at QOM-ification.  I think I'll stick 
with 'vc' but this would effectively be only for legacy syntax.

Regards,

Anthony Liguori

>
> cheers,
>    Gerd
>
>

Re: [Qemu-devel] [PATCH 1/6] console: allow VCs to be overridden by UI

[Gerd Hoffmann]

  Hi,

> This would require touching a fair bit of code that handles things like
> defaults.  I'm not sure that having the distinction makes anything
> easier to implement.

/me suggests to simply have no default terminals with qemu -gtk.

> One thing I was contemplating but ultimately didn't do was QOM-ification
> of the GTK front end.  I couldn't rationalize why you would need to set
> settings but now I think maybe it would be more useful.

With a vte chardev you have an object you can attach settings to, i.e.
-chardev vte,mode={tab,window}.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Kevin Wolf]

Am 20.02.2012 15:04, schrieb Anthony Liguori:
>> * Half of the menu entries appears to be translated by the libraries
>>    used. Give me something that is all German or something that is all
>>    English. Mixed languages looks unprofessional.
> 
> This is because of the use of stock items.  I can overload the labels and force 
> english menu names.  I can also add some basic internationalization and make 
> greater use of stock item names.
> 
> I would actually prefer the later approach although practically speaking, the 
> monitor would remain in English.  Would this seem awkward?
> 
> What's preferable for non-native English speakers?

If we get a clean and logical separation (e.g. all the menu items are
translated and all the output in the monitor is English), I think that
would be fine.

>> * Ctrl-Alt-= as shortcut for Zoom In isn't easy to remember and only
>>    makes some sense on a US keyboard layout.
> 
> There doesn't appear to be a stock accelerator for Zoom in GTK.  Firefox 
> advertises Ctrl-+ as the zoom in accelerator but apparently accepts Ctrl-+ or 
> Ctrl-=.
> 
> I'd be happy with just doing Ctrl-Alt-+.  It's a little more awkward to type but 
> that seems to be the standard.

That would be better. We could still accept Ctrl-Alt-= additionally like
you describe for Firefox.

>> * The window has a button for maximising, but it doesn't really do
>>    anything.
> 
> This is your Window Manager.  We call gtk_window_set_resizable(False) and that 
> should cause the maximize button to disappear.  Indeed, if you look at the 
> screenshots I posted, there isn't a maximize button.

Just checked again and it doesn't seem to be there. I almost thought I
had been dreaming when I wrote this, but in fact switching to fullscreen
and back gives me the button. Can you reproduce it this way?

(But I won't run more tests while writing an email, the OOM killer
always kills Thunderbird first... Means that the bug is reproducible at
least.)

>> * Ctrl-PgDn/PgUp does change the tab as I expected on VGA, it's ignored
>>    by the monitor and the serial0 tabs.
> 
> This is something that probably needs some work.  Right now we propagate all key 
> presses which is what allows the accelerators to work.  What we probably should 
> do is check the key presses against only the accelerators we want to work and 
> propagate those.
> 
> This is a bit tricky though.  The end effect would be that Ctrl-PgDn would stop 
> working on the VGA tab.  I think this is expected behavior.

Yes, I think this is fine. And in this case it would also be fine if it
didn't work in other tabs. Consistency is probably most important here.

Kevin

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Stefano Stabellini]

On Mon, 20 Feb 2012, Anthony Liguori wrote:
> On 02/20/2012 08:06 AM, Stefano Stabellini wrote:
> > On Mon, 20 Feb 2012, Anthony Liguori wrote:
> >> On 02/19/2012 08:52 PM, Brad Smith wrote:
> >>> On 19/02/12 9:44 PM, Anthony Liguori wrote:
> >>>> On 02/19/2012 08:24 PM, Brad Smith wrote:
> >>>>> On 19/02/12 8:10 PM, Anthony Liguori wrote:
> >>>>>>> If not, it will be nice to keep
> >>>>>>> SDL because GTK huge and not that portable for win32 users.
> >>>>>>
> >>>>>> Neither are true. GTK is a reasonably small dependency especially given
> >>>>>> that GLIB is a mandatory dependency. I can't imagine that in terms of
> >>>>>> binary size, libsdl is much bigger than gtk/gdk.
> >>>>>
> >>>>> Double check your facts. That's not even close to being true.
> >>>>>
> >>>>> SDL is a tiny fraction of Gtk+.
> >>>>>
> >>>>> Just as an example taking a look at package sizes..
> >>>>>
> >>>>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries)
> >>>>> excluding Glib2 and what it depends on.
> >>>>
> >>>> I don't see how 17.3MB qualifies as "huge".
> >>>
> >>> It's FAR from small not to mention dragging in A LOT of libraries for what?
> >>> A prettier looking UI?
> >>
> >> An accessible UI that meets the most basic definition of usable.  Sit someone
> >> down with the SDL interface for the first time, how in the world are they
> >> supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt?
> >
> > I think that having a GTK UI is quite important for QEMU and having it
> > be the default is also a good idea.
> >
> > BUT we should not deprecate and plan to remove SDL.
> 
> Actually, I think Cairo can be a better SDL than SDL.
> 
> It doesn't have the same level of backend support (or input support) as SDL 
> does, but it can render to Win32, Quartz, and a raw X11 window.

Cairo seems to be quite popular and well maintained, however I am not
sure how well it would work without GTK.

Granted that I don't particularly care about which library we use for
rendering the "lightweight UI", if the entire UI can be written in
Cairo, without any other library or dependency of any kind, then it
is probably OK to replace SDL with Cairo.


> > Do we really want to force everybody that uses QEMU on X11 to compile
> > the entire set of GTK dependencies?
> > Keep in mind that QEMU is not just used on Linux distros but it also
> > used as a component in other projects that might have very different
> > constraints.
> > I think that having a lightweight graphical UI with very few and small
> > dependencies is NOT something we should give up.
> 
> If we went in a different direction with SDL, I wouldn't mind it so much.  For 
> instance, removing the console emulation and reducing the use of magic accelerators.

Strictly speaking the console emulation is not part of the SDL UI, also
we need to keep it because of VNC.
But I agree that the SDL UI should stay light and simple, rather than
duplicating the fully featured desktop experience that is going to be
provided by GTK.

Re: [Qemu-devel] [PATCH 6/6] gtk: make default UI

[Roy Tam]

2012/2/20 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> On Mon, 20 Feb 2012, Anthony Liguori wrote:
>> On 02/20/2012 08:06 AM, Stefano Stabellini wrote:
>> > On Mon, 20 Feb 2012, Anthony Liguori wrote:
>> >> On 02/19/2012 08:52 PM, Brad Smith wrote:
>> >>> On 19/02/12 9:44 PM, Anthony Liguori wrote:
>> >>>> On 02/19/2012 08:24 PM, Brad Smith wrote:
>> >>>>> On 19/02/12 8:10 PM, Anthony Liguori wrote:
>> >>>>>>> If not, it will be nice to keep
>> >>>>>>> SDL because GTK huge and not that portable for win32 users.
>> >>>>>>
>> >>>>>> Neither are true. GTK is a reasonably small dependency especially given
>> >>>>>> that GLIB is a mandatory dependency. I can't imagine that in terms of
>> >>>>>> binary size, libsdl is much bigger than gtk/gdk.
>> >>>>>
>> >>>>> Double check your facts. That's not even close to being true.
>> >>>>>
>> >>>>> SDL is a tiny fraction of Gtk+.
>> >>>>>
>> >>>>> Just as an example taking a look at package sizes..
>> >>>>>
>> >>>>> 549KB for SDL vs 17.3MB for just Gtk+ and its dependencies (7 libraries)
>> >>>>> excluding Glib2 and what it depends on.
>> >>>>
>> >>>> I don't see how 17.3MB qualifies as "huge".
>> >>>
>> >>> It's FAR from small not to mention dragging in A LOT of libraries for what?
>> >>> A prettier looking UI?
>> >>
>> >> An accessible UI that meets the most basic definition of usable.  Sit someone
>> >> down with the SDL interface for the first time, how in the world are they
>> >> supposed to figure out that you hit Ctrl+Alt+2 to get to a command prompt?
>> >
>> > I think that having a GTK UI is quite important for QEMU and having it
>> > be the default is also a good idea.
>> >
>> > BUT we should not deprecate and plan to remove SDL.
>>
>> Actually, I think Cairo can be a better SDL than SDL.
>>
>> It doesn't have the same level of backend support (or input support) as SDL
>> does, but it can render to Win32, Quartz, and a raw X11 window.
>
> Cairo seems to be quite popular and well maintained, however I am not
> sure how well it would work without GTK.
>
> Granted that I don't particularly care about which library we use for
> rendering the "lightweight UI", if the entire UI can be written in
> Cairo, without any other library or dependency of any kind, then it
> is probably OK to replace SDL with Cairo.
>

cairo handles display only, you have to deal with input for each
platform (which is handled by SDL)

>
>> > Do we really want to force everybody that uses QEMU on X11 to compile
>> > the entire set of GTK dependencies?
>> > Keep in mind that QEMU is not just used on Linux distros but it also
>> > used as a component in other projects that might have very different
>> > constraints.
>> > I think that having a lightweight graphical UI with very few and small
>> > dependencies is NOT something we should give up.
>>
>> If we went in a different direction with SDL, I wouldn't mind it so much.  For
>> instance, removing the console emulation and reducing the use of magic accelerators.
>
> Strictly speaking the console emulation is not part of the SDL UI, also
> we need to keep it because of VNC.
> But I agree that the SDL UI should stay light and simple, rather than
> duplicating the fully featured desktop experience that is going to be
> provided by GTK.

Re: [Qemu-devel] [PATCH 1/6] console: allow VCs to be overridden by UI

[Anthony Liguori]

On 02/20/2012 08:27 AM, Gerd Hoffmann wrote:
>    Hi,
>
>> This would require touching a fair bit of code that handles things like
>> defaults.  I'm not sure that having the distinction makes anything
>> easier to implement.
>
> /me suggests to simply have no default terminals with qemu -gtk.
>
>> One thing I was contemplating but ultimately didn't do was QOM-ification
>> of the GTK front end.  I couldn't rationalize why you would need to set
>> settings but now I think maybe it would be more useful.
>
> With a vte chardev you have an object you can attach settings to, i.e.
> -chardev vte,mode={tab,window}.

Right, but you could do the same with QOM, it would look like:

GtkDisplay is-a UserInterface (maybe?)
   has-a GtkVirtualConsole "vc0"
   has-a GtkVirtualConsole "vc1"
   ...

GtkVirtualConsole could have a "mode" property.


So from a UI perspective, you would do something like:

-gtk -set /ui/vc0.mode=tab

I think it makes more sense overall as a sub-property of the main ui object 
verses a property of a character device (which is only tangentially related to 
the UI itself).

Regards,

Anthony Liguori

>
> cheers,
>    Gerd
>
>

Re: [Qemu-devel] [PATCH 2/6] ui: add basic GTK gui

[Stefan Weil]

Am 20.02.2012 00:45, schrieb Anthony Liguori:
> 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>
> ---
> Makefile | 2 +
> Makefile.objs | 1 +
> configure | 25 +++-
> console.h | 4 +
> sysemu.h | 1 +
> ui/gtk.c | 551 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 6 files changed, 583 insertions(+), 1 deletions(-)
> create mode 100644 ui/gtk.c
>

This patch compiles, but does not provide the minimalistic interface
because the hooks in vl.c are missing. Parts of patch 6 might be
moved to patch 2.

Patch 2 could also be improved by removing the dependency on VTE.
For some platforms (w32), providing VTE is really a big challenge.
I did not find a precompiled version and still did not succeed
in compiling it because of a large and still incomplete dependency
chain...

What about offering compilation without VTE also in the "final"
version of the GTK gui (--enable-vte, --disable-vte)?

These includes in ui/gtk.c were not needed:

+#include <vte/vte.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <sys/un.h>
+#include <sys/wait.h>
+#include <pty.h>

If the version using VTE needs them, qemu_socket.h should be
used (needed for w32 which does neither have sys/socket.h
nor pty.h). Maybe most of these includes are not needed at all
(relict from VNC?).

With a patched vl.c and ui/gtk.c, the new GUI starts on w32
but does not work stable.
After some minutes, the GUI freezes (no more updates, menu no
longer working).

The configuration support still does not work as expected:

configure should support --enable-gtk, --disable-gtk with the
usual semantic (no GTK UI if --disable-gtk was given, fail if
--enable-gtk was given and GTK is not found, provide help message).

The GTK user interface is a good starting point for a more
powerful and user friendly interface.

Nevertheless SDL should not be removed for the next few years.
I would not mind if buggy features like zooming were removed
from SDL again, but having a GUI which also works with framebuffers
(without X) and which has much less requirements than GTK+-2.0
(and perhaps also a reduced risk of security problems)
is a good feature.

Cheers,
Stefan Weil

PS: git complains about whitespace at eol in some of the patches,
and checkpatch.pl is also very noisy :-)

Re: [Qemu-devel] [PATCH 3/6] gtk: add virtual console support

[Stefan Weil]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

Am 20.02.2012 00:45, schrieb Anthony Liguori:
> 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>
> ---
> ui/gtk.c | 138 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 138 insertions(+), 0 deletions(-)
>


The new code uses VtePty and some functions which were added to
VteTerminal in 2010, so this is a rather new interface:

    commit dd08c50c6a6dd4349d3cbce271ddf4b741db8861
    Autor: Christian Persch <chpe@gnome.org> Do Jan 14 18:08:33 2010
    Eintragender: Christian Persch <chpe@gnome.org> Mi Mär 17 18:22:15 2010

    Add VtePty and adapt the VteTerminal APIs to it

    Add VtePty as a GObject holding the info about the PTY. Add new API to
    VteTerminal to set a VtePty, and deprecate the old API that takes a FD
    to the PTY. Also deprecate the whole of the undocumented _vte_pty_*()
    APIs.

    Add vte_terminal_fork_command_full() variant that allow providing a
    custom child setup function and that returns a GError on failure.


=> It does not work with Debian stable and other "old" distributions.

configure detects GTK+ and VTE, but make fails.

Regards,

Stefan Weil




[-- Attachment #2: Type: text/html, Size: 2691 bytes --]

Re: [Qemu-devel] [PATCH 2/6] ui: add basic GTK gui

[Anthony Liguori]

On 02/20/2012 02:45 PM, Stefan Weil wrote:
> Am 20.02.2012 00:45, schrieb Anthony Liguori:
>> 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>
>> ---
>> Makefile | 2 +
>> Makefile.objs | 1 +
>> configure | 25 +++-
>> console.h | 4 +
>> sysemu.h | 1 +
>> ui/gtk.c | 551 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 6 files changed, 583 insertions(+), 1 deletions(-)
>> create mode 100644 ui/gtk.c
>>
>
> This patch compiles, but does not provide the minimalistic interface
> because the hooks in vl.c are missing. Parts of patch 6 might be
> moved to patch 2.

Yes, that's intentional in order to avoid bad bisecting.  I could make a 
-display gtk flag though and just not make it the default until the last patch. 
  I'll update accordingly.

> Patch 2 could also be improved by removing the dependency on VTE.
> For some platforms (w32), providing VTE is really a big challenge.
> I did not find a precompiled version and still did not succeed
> in compiling it because of a large and still incomplete dependency
> chain...

I'm not a big fan of this.  Would hosting dependencies on qemu.org help address 
this problem?

In order to do this, we would have to have mirror all of the dependencies onto 
git.qemu.org and create a super repository with submodules and a build script to 
cross compile all of the dependencies.  I don't think it's a huge effort.

> What about offering compilation without VTE also in the "final"
> version of the GTK gui (--enable-vte, --disable-vte)?

That's a pretty significant reduction in functionality.  I'd rather try to 
provide the dependencies directly.

>
> These includes in ui/gtk.c were not needed:
>
> +#include <vte/vte.h>
> +#include <sys/types.h>
> +#include <sys/socket.h>
> +#include <sys/un.h>
> +#include <sys/wait.h>
> +#include <pty.h>
>
> If the version using VTE needs them, qemu_socket.h should be
> used (needed for w32 which does neither have sys/socket.h
> nor pty.h). Maybe most of these includes are not needed at all
> (relict from VNC?).

They are needed but not in this patch.  I missed this bit as I was extracting 
patches.

>
> With a patched vl.c and ui/gtk.c, the new GUI starts on w32
> but does not work stable.
> After some minutes, the GUI freezes (no more updates, menu no
> longer working).

My guess is that this has to do with the way the Win32 main loops work.   I'm 
not sure how to fix this since IIUC, the problem is that we basically have two 
loops for Win32, one that calls select() on fds and another that uses 
WaitForEvent or whatever the win32 function is.

> The configuration support still does not work as expected:
>
> configure should support --enable-gtk, --disable-gtk with the
> usual semantic (no GTK UI if --disable-gtk was given, fail if
> --enable-gtk was given and GTK is not found, provide help message).

Oh, I'll look into that.  I expect that it should work.

> The GTK user interface is a good starting point for a more
> powerful and user friendly interface.
>
> Nevertheless SDL should not be removed for the next few years.
> I would not mind if buggy features like zooming were removed
> from SDL again, but having a GUI which also works with framebuffers
> (without X) and which has much less requirements than GTK+-2.0
> (and perhaps also a reduced risk of security problems)
> is a good feature.

As I mentioned in another thread, I'd be very happy to keep the SDL interface if 
we removed the ugly bits (like the virtual console emulation).

>
> Cheers,
> Stefan Weil
>
> PS: git complains about whitespace at eol in some of the patches,
> and checkpatch.pl is also very noisy :-)

Yes, I'm aware.  I'll address it in the next round.

Thanks for the feedback.

Regards,

Anthony Liguori

>
>

Re: [Qemu-devel] [PATCH 5/6] gtk: add support for screen scaling and full screen

[Stefan Weil]

Am 20.02.2012 00:45, schrieb Anthony Liguori:
> 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>
> ---
> ui/gtk.c | 89 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
> 1 files changed, 85 insertions(+), 4 deletions(-)
>
> diff --git a/ui/gtk.c b/ui/gtk.c
> index 73051db..b9a9bc3 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
[...]
> + s->zoom_in_item = 
> gtk_image_menu_item_new_from_stock(GTK_STOCK_ZOOM_IN, NULL);
> + gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->zoom_in_item),
> + "<QEMU>/View/Zoom In");
> + gtk_accel_map_add_entry("<QEMU>/View/Zoom In", GDK_KEY_equal, 
> GDK_CONTROL_MASK | GDK_MOD1_MASK);
> + gtk_menu_append(GTK_MENU(s->view_menu), s->zoom_in_item);
> +
> + s->zoom_out_item = 
> gtk_image_menu_item_new_from_stock(GTK_STOCK_ZOOM_OUT, NULL);
> + gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->zoom_out_item),
> + "<QEMU>/View/Zoom Out");
> + gtk_accel_map_add_entry("<QEMU>/View/Zoom Out", GDK_KEY_minus, 
> GDK_CONTROL_MASK | GDK_MOD1_MASK);
> + gtk_menu_append(GTK_MENU(s->view_menu), s->zoom_out_item);
> +
> separator = gtk_separator_menu_item_new();
> gtk_menu_append(GTK_MENU(s->view_menu), separator);

I think GDK_KEY_plus would be a better choice instead of GDK_KEY_equal
because that's the key used to zoom in by GNOME terminal, most web browsers
and many more programs.

Usually there is also a "Zoom 100 %" with GDK_KEY_0 which resets
zooming to 100 %.

Regards,

Stefan Weil

Re: [Qemu-devel] [PATCH 3/6] gtk: add virtual console support

[Stefan Weil]

Am 20.02.2012 00:45, schrieb Anthony Liguori:
> 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>
> ---
> ui/gtk.c | 138 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 138 insertions(+), 0 deletions(-)
>
> diff --git a/ui/gtk.c b/ui/gtk.c
> index 502705b..bf65a4f 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
[...]
> +static int gd_vc_handler(QemuOpts *opts, CharDriverState **chrp)
> +{
> + CharDriverState *chr;
> +
> + chr = g_malloc0(sizeof(*chr));

Some time ago, there was a decision to prefer g_new / g_new0:

     chr = g_new0(CharDriverState, 1);

In function gtk_display_init there is also a g_malloc0 which
should be replaced by g_new0.

Regards,

Stefan Weil

Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Stefan Weil]

Am 20.02.2012 00:44, schrieb Anthony Liguori:
> Hi,
>
> I realize UIs are the third rail of QEMU development, but over the 
> years I've
> gotten a lot of feedback from users about our UI. I think everyone 
> struggles
> with the SDL interface and its lack of discoverability but it's worse 
> than I
> think most people realize for users that rely on accessibility tools.
>
> The two pieces of feedback I've gotten the most re: accessibility are 
> the lack
> of QEMU's enablement for screen readers and the lack of configurable
> accelerators.
>
> Since we render our own terminal using a fixed sized font, we don't 
> respect
> system font settings which means we ignore if the user has configured 
> large
> print.
>
> We also don't integrate at all with screen readers which means that 
> for blind
> users, the virtual consoles may as well not even exist.
>
> We also don't allow any type of configuration of accelerators. For 
> users with
> limited dexterity (this is actually more common than you would think), 
> they may
> use an input device that only inputs one key at a time. Holding down 
> two keys
> at once is not possible for these users.
>
> These are solved problems though and while we could reinvent all of this
> ourselves with SDL, we would be crazy if we did. Modern toolkits, like 
> GTK,
> solve these problems.
>
> By using GTK, we can leverage VteTerminal for screen reader 
> integration and font
> configuration. We can also use GTK's accelerator support to make 
> accelerators
> configurable (Gnome provides a global accelerator configuration 
> interface).
>
> I'm not attempting to make a pretty desktop virtualization UI. Maybe 
> we'll go
> there eventually but that's not what this series is about.
>
> This is just attempting to use a richer toolkit such that we can 
> enable basic
> accessibility support. As a consequence, the UI is much more usable 
> even for a
> user without accessibility requirements so it's a win-win.

This first version of the new GTK UI still shares some problems with
the SDL UI and adds new ones:

It's quite common for the VGA code to set a very small size (e.g. 1 x 1 
pixel)
during boot. MIPS Malta does (if no VGA module like cirrusfb is loaded,
it will never set a different size), and even the 386 / x86_64 emulation
has a (very short) time were the display size is unusually small.

This results in a very small window size which is only limited by the 
display manager.
Usually it is so small that any user interaction with the window becomes 
difficult.

The GDK UI increases the problem because it also resizes the monitor, 
serial and
all other text consoles. On Ubuntu, I get a Malta serial console with 7 
characters
in 5 rows, and the serial output also wraps after 7 characters.

Zooming changes the number of rows and lines, not the size of the characters
in all text consoles.

There is also a new kind of QEMU crash:

The program '<unknown>' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
   (Details: serial 28914 error_code 11 request_code 53 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() 
function.)

I just got it while writing this mail when I wanted to check some facts.

Program '<unknown>' is not user friendly (crashing never is, but when it
crashes, at least the error message should be good :-)).
The bug also occurred a second time when I started MIPS Malta
(when the Linux kernel loaded module cirrusfb), so it seems to be
reproducible.

Regards,
Stefan Weil

Re: [Qemu-devel] [PATCH 3/6] gtk: add virtual console support

[Anthony Liguori]

On 02/25/2012 10:21 AM, Stefan Weil wrote:
> Am 20.02.2012 00:45, schrieb Anthony Liguori:
>> 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>
>> ---
>> ui/gtk.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 138 insertions(+), 0 deletions(-)
>>
>> diff --git a/ui/gtk.c b/ui/gtk.c
>> index 502705b..bf65a4f 100644
>> --- a/ui/gtk.c
>> +++ b/ui/gtk.c
> [...]
>> +static int gd_vc_handler(QemuOpts *opts, CharDriverState **chrp)
>> +{
>> + CharDriverState *chr;
>> +
>> + chr = g_malloc0(sizeof(*chr));
>
> Some time ago, there was a decision to prefer g_new / g_new0:

I'm not sure where the book of decisions is kept, but I certainly don't agree. 
a = malloc(sizeof(*a)) is an incredibly common pattern in QEMU.

It would be silly to change this pattern without good cause.

Regards,

Anthony Liguori

>
> chr = g_new0(CharDriverState, 1);
>
> In function gtk_display_init there is also a g_malloc0 which
> should be replaced by g_new0.
>
> Regards,
>
> Stefan Weil
>
>

Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Anthony Liguori]

On 02/25/2012 11:02 AM, Stefan Weil wrote:
> Am 20.02.2012 00:44, schrieb Anthony Liguori:
>> Hi,
>>
>> I realize UIs are the third rail of QEMU development, but over the years I've
>> gotten a lot of feedback from users about our UI. I think everyone struggles
>> with the SDL interface and its lack of discoverability but it's worse than I
>> think most people realize for users that rely on accessibility tools.
>>
>> The two pieces of feedback I've gotten the most re: accessibility are the lack
>> of QEMU's enablement for screen readers and the lack of configurable
>> accelerators.
>>
>> Since we render our own terminal using a fixed sized font, we don't respect
>> system font settings which means we ignore if the user has configured large
>> print.
>>
>> We also don't integrate at all with screen readers which means that for blind
>> users, the virtual consoles may as well not even exist.
>>
>> We also don't allow any type of configuration of accelerators. For users with
>> limited dexterity (this is actually more common than you would think), they may
>> use an input device that only inputs one key at a time. Holding down two keys
>> at once is not possible for these users.
>>
>> These are solved problems though and while we could reinvent all of this
>> ourselves with SDL, we would be crazy if we did. Modern toolkits, like GTK,
>> solve these problems.
>>
>> By using GTK, we can leverage VteTerminal for screen reader integration and font
>> configuration. We can also use GTK's accelerator support to make accelerators
>> configurable (Gnome provides a global accelerator configuration interface).
>>
>> I'm not attempting to make a pretty desktop virtualization UI. Maybe we'll go
>> there eventually but that's not what this series is about.
>>
>> This is just attempting to use a richer toolkit such that we can enable basic
>> accessibility support. As a consequence, the UI is much more usable even for a
>> user without accessibility requirements so it's a win-win.
>
> This first version of the new GTK UI still shares some problems with
> the SDL UI and adds new ones:
>
> It's quite common for the VGA code to set a very small size (e.g. 1 x 1 pixel)
> during boot. MIPS Malta does (if no VGA module like cirrusfb is loaded,
> it will never set a different size), and even the 386 / x86_64 emulation
> has a (very short) time were the display size is unusually small.

It doesn't.  It cycles through modes 640x480, 720x400, then VGA modes.  It never 
resizes to 1x1.

But..  GTK should handle this better.  Even if the drawing area sets the size to 
1x1, the window should maintain a size at least large enough to render the menu 
bar properly.

> This results in a very small window size which is only limited by the display
> manager.
> Usually it is so small that any user interaction with the window becomes difficult.
>
> The GDK UI increases the problem because it also resizes the monitor, serial and
> all other text consoles. On Ubuntu, I get a Malta serial console with 7 characters
> in 5 rows, and the serial output also wraps after 7 characters.

I'm going to fix the terminal widths to something reasonable so that shouldn't 
be a problem anymore.

> Zooming changes the number of rows and lines, not the size of the characters
> in all text consoles.

I'm going to disable zooming when VGA is not the current tab.


> There is also a new kind of QEMU crash:
>
> The program '<unknown>' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadAlloc (insufficient resources for operation)'.
> (Details: serial 28914 error_code 11 request_code 53 minor_code 0)
> (Note to programmers: normally, X errors are reported asynchronously;
> that is, you will receive the error a while after causing it.
> To debug your program, run it with the --sync command line
> option to change this behavior. You can then get a meaningful
> backtrace from your debugger if you break on the gdk_x_error() function.)
>
> I just got it while writing this mail when I wanted to check some facts.
>
> Program '<unknown>' is not user friendly (crashing never is, but when it
> crashes, at least the error message should be good :-)).
> The bug also occurred a second time when I started MIPS Malta
> (when the Linux kernel loaded module cirrusfb), so it seems to be
> reproducible.

Sounds like malloc failure.

Regards,

Anthony Liguori

>
> Regards,
> Stefan Weil
>
>

Re: [Qemu-devel] [PATCH 3/6] gtk: add virtual console support

[Stefan Weil]

Am 25.02.2012 20:49, schrieb Anthony Liguori:
> On 02/25/2012 10:21 AM, Stefan Weil wrote:
>> Am 20.02.2012 00:45, schrieb Anthony Liguori:
>>> 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>
>>> ---
>>> ui/gtk.c | 138 
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 files changed, 138 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/ui/gtk.c b/ui/gtk.c
>>> index 502705b..bf65a4f 100644
>>> --- a/ui/gtk.c
>>> +++ b/ui/gtk.c
>> [...]
>>> +static int gd_vc_handler(QemuOpts *opts, CharDriverState **chrp)
>>> +{
>>> + CharDriverState *chr;
>>> +
>>> + chr = g_malloc0(sizeof(*chr));
>>
>> Some time ago, there was a decision to prefer g_new / g_new0:
>
> I'm not sure where the book of decisions is kept, but I certainly 
> don't agree. a = malloc(sizeof(*a)) is an incredibly common pattern in 
> QEMU.
>
> It would be silly to change this pattern without good cause.
>
> Regards,
>
> Anthony Liguori

Hi Anthony,

there is no book of decisions for QEMU, but there is best practice.
As far as I remember this topic was first discussed in this
qemu-devel thread:

http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg01988.html

a = malloc(sizeof(*a)) is no longer a valid pattern for QEMU
since you introduced glib-2.0. Those calls were converted
to a = g_malloc(sizeof(*a)) which was reasonable for a simple
automated code conversion.

I also used the g_malloc pattern in my patch, but was convinced
that glib-2.0 offers a better alternative using g_new.

Kind regards,

Stefan Weil

Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Stefan Weil]

[-- Attachment #1: Type: text/plain, Size: 5409 bytes --]

Am 25.02.2012 21:11, schrieb Anthony Liguori:
> On 02/25/2012 11:02 AM, Stefan Weil wrote:
>> Am 20.02.2012 00:44, schrieb Anthony Liguori:
>>> Hi,
>>>
>>> I realize UIs are the third rail of QEMU development, but over the 
>>> years I've
>>> gotten a lot of feedback from users about our UI. I think everyone 
>>> struggles
>>> with the SDL interface and its lack of discoverability but it's 
>>> worse than I
>>> think most people realize for users that rely on accessibility tools.
>>>
>>> The two pieces of feedback I've gotten the most re: accessibility 
>>> are the lack
>>> of QEMU's enablement for screen readers and the lack of configurable
>>> accelerators.
>>>
>>> Since we render our own terminal using a fixed sized font, we don't 
>>> respect
>>> system font settings which means we ignore if the user has 
>>> configured large
>>> print.
>>>
>>> We also don't integrate at all with screen readers which means that 
>>> for blind
>>> users, the virtual consoles may as well not even exist.
>>>
>>> We also don't allow any type of configuration of accelerators. For 
>>> users with
>>> limited dexterity (this is actually more common than you would 
>>> think), they may
>>> use an input device that only inputs one key at a time. Holding down 
>>> two keys
>>> at once is not possible for these users.
>>>
>>> These are solved problems though and while we could reinvent all of 
>>> this
>>> ourselves with SDL, we would be crazy if we did. Modern toolkits, 
>>> like GTK,
>>> solve these problems.
>>>
>>> By using GTK, we can leverage VteTerminal for screen reader 
>>> integration and font
>>> configuration. We can also use GTK's accelerator support to make 
>>> accelerators
>>> configurable (Gnome provides a global accelerator configuration 
>>> interface).
>>>
>>> I'm not attempting to make a pretty desktop virtualization UI. Maybe 
>>> we'll go
>>> there eventually but that's not what this series is about.
>>>
>>> This is just attempting to use a richer toolkit such that we can 
>>> enable basic
>>> accessibility support. As a consequence, the UI is much more usable 
>>> even for a
>>> user without accessibility requirements so it's a win-win.
>>
>> This first version of the new GTK UI still shares some problems with
>> the SDL UI and adds new ones:
>>
>> It's quite common for the VGA code to set a very small size (e.g. 1 x 
>> 1 pixel)
>> during boot. MIPS Malta does (if no VGA module like cirrusfb is loaded,
>> it will never set a different size), and even the 386 / x86_64 emulation
>> has a (very short) time were the display size is unusually small.
>
> It doesn't.  It cycles through modes 640x480, 720x400, then VGA 
> modes.  It never resizes to 1x1.
>
> But..  GTK should handle this better.  Even if the drawing area sets 
> the size to 1x1, the window should maintain a size at least large 
> enough to render the menu bar properly. ss/ssssssssssssss/

Just run QEMU on a sufficiently slow host, for example QEMU in QEMU,
or slow down the execution of QEMU by other means, then you will see
which window sizes are then selected. Maybe you also need -singlestep.
You _will_ get a very small window!

I just got it using this call on a netbook running Ubuntu:

qemu-system-i386 -L pc-bios -singlestep -d in_asm,out_asm

Don't use KVM, of course - we want to slow down QEMU!
Adding strace is also a good way to reduce execution speed.

Cheers,

Stefan Weil

PS. qemu-system-i386 crashed like qemu-system-mipsel before
when it tried to switch from the small window to the normal size:

The program '<unknown>' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
   (Details: serial 351 error_code 11 request_code 53 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() 
function.)

Debugging X errors is a bit difficult, but I finally got this backtrace:

Breakpoint 3, 0x00438196 in _XError () from /usr/lib/libX11.so.6
(gdb) i s
#0  0x00438196 in _XError () from /usr/lib/libX11.so.6
#1  0x0043e92f in ?? () from /usr/lib/libX11.so.6
#2  0x0043f356 in _XEventsQueued () from /usr/lib/libX11.so.6
#3  0x0043f3e9 in _XFlush () from /usr/lib/libX11.so.6
#4  0x00417101 in XFlush () from /usr/lib/libX11.so.6
#5  0x00936cb4 in gdk_display_flush () from /usr/lib/libgdk-x11-2.0.so.0
#6  0x00928f7a in gdk_window_process_all_updates () from 
/usr/lib/libgdk-x11-2.0.so.0
#7  0x005c676f in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#8  0x00905358 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#9  0x00176661 in ?? () from /lib/libglib-2.0.so.0
#10 0x001785e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#11 0x8013d4a0 in glib_select_poll (rfds=0xbfffef04, wfds=0xbfffee84, 
xfds=0xbfffee04,
     err=false) at /home/stefan/src/qemu/qemu.org/qemu/main-loop.c:287
#12 0x8013d696 in main_loop_wait (nonblocking=0)
     at /home/stefan/src/qemu/qemu.org/qemu/main-loop.c:463
#13 0x80131b40 in main_loop () at 
/home/stefan/src/qemu/qemu.org/qemu/vl.c:1482
#14 0x80138985 in main (argc=6, argv=0xbffff344, envp=0xbffff360)
     at /home/stefan/src/qemu/qemu.org/qemu/vl.c:3541


[-- Attachment #2: Type: text/html, Size: 8198 bytes --]

Re: [Qemu-devel] [PATCH 3/6] gtk: add virtual console support

[Anthony Liguori]

On 02/25/2012 02:22 PM, Stefan Weil wrote:
> Am 25.02.2012 20:49, schrieb Anthony Liguori:
>> On 02/25/2012 10:21 AM, Stefan Weil wrote:
>>> Am 20.02.2012 00:45, schrieb Anthony Liguori:
>>>> 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>
>>>> ---
>>>> ui/gtk.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 files changed, 138 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/ui/gtk.c b/ui/gtk.c
>>>> index 502705b..bf65a4f 100644
>>>> --- a/ui/gtk.c
>>>> +++ b/ui/gtk.c
>>> [...]
>>>> +static int gd_vc_handler(QemuOpts *opts, CharDriverState **chrp)
>>>> +{
>>>> + CharDriverState *chr;
>>>> +
>>>> + chr = g_malloc0(sizeof(*chr));
>>>
>>> Some time ago, there was a decision to prefer g_new / g_new0:
>>
>> I'm not sure where the book of decisions is kept, but I certainly don't agree.
>> a = malloc(sizeof(*a)) is an incredibly common pattern in QEMU.
>>
>> It would be silly to change this pattern without good cause.
>>
>> Regards,
>>
>> Anthony Liguori
>
> Hi Anthony,
>
> there is no book of decisions for QEMU, but there is best practice.
> As far as I remember this topic was first discussed in this
> qemu-devel thread:
>
> http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg01988.html
>
> a = malloc(sizeof(*a)) is no longer a valid pattern for QEMU
> since you introduced glib-2.0. Those calls were converted
> to a = g_malloc(sizeof(*a)) which was reasonable for a simple
> automated code conversion.
>
> I also used the g_malloc pattern in my patch, but was convinced
> that glib-2.0 offers a better alternative using g_new.

I meant g_malloc of course.

If we want to have a "best practice", we should document it in CODING_STYLE. 
But I wouldn't agree with such a patch to coding style anyway.

Regards,

Anthony Liguori

>
> Kind regards,
>
> Stefan Weil
>
>

[Qemu-devel] Very small VGA window sizes (was: Re: [PATCH 0/6] Add GTK UI to enable basic accessibility)

[Stefan Weil]

[-- Attachment #1: Type: text/plain, Size: 3996 bytes --]

Am 25.02.2012 22:15, schrieb Stefan Weil:
> Am 25.02.2012 21:11, schrieb Anthony Liguori:
>> On 02/25/2012 11:02 AM, Stefan Weil wrote:
>>> Am 20.02.2012 00:44, schrieb Anthony Liguori:
>>>> Hi,
>>>>
>>>> I realize UIs are the third rail of QEMU development, but over the 
>>>> years I've
>>>> gotten a lot of feedback from users about our UI. I think everyone 
>>>> struggles
>>>> with the SDL interface and its lack of discoverability but it's 
>>>> worse than I
>>>> think most people realize for users that rely on accessibility tools.
>>>>
>>>> The two pieces of feedback I've gotten the most re: accessibility 
>>>> are the lack
>>>> of QEMU's enablement for screen readers and the lack of configurable
>>>> accelerators.
>>>>
>>>> Since we render our own terminal using a fixed sized font, we don't 
>>>> respect
>>>> system font settings which means we ignore if the user has 
>>>> configured large
>>>> print.
>>>>
>>>> We also don't integrate at all with screen readers which means that 
>>>> for blind
>>>> users, the virtual consoles may as well not even exist.
>>>>
>>>> We also don't allow any type of configuration of accelerators. For 
>>>> users with
>>>> limited dexterity (this is actually more common than you would 
>>>> think), they may
>>>> use an input device that only inputs one key at a time. Holding 
>>>> down two keys
>>>> at once is not possible for these users.
>>>>
>>>> These are solved problems though and while we could reinvent all of 
>>>> this
>>>> ourselves with SDL, we would be crazy if we did. Modern toolkits, 
>>>> like GTK,
>>>> solve these problems.
>>>>
>>>> By using GTK, we can leverage VteTerminal for screen reader 
>>>> integration and font
>>>> configuration. We can also use GTK's accelerator support to make 
>>>> accelerators
>>>> configurable (Gnome provides a global accelerator configuration 
>>>> interface).
>>>>
>>>> I'm not attempting to make a pretty desktop virtualization UI. 
>>>> Maybe we'll go
>>>> there eventually but that's not what this series is about.
>>>>
>>>> This is just attempting to use a richer toolkit such that we can 
>>>> enable basic
>>>> accessibility support. As a consequence, the UI is much more usable 
>>>> even for a
>>>> user without accessibility requirements so it's a win-win.
>>>
>>> This first version of the new GTK UI still shares some problems with
>>> the SDL UI and adds new ones:
>>>
>>> It's quite common for the VGA code to set a very small size (e.g. 1 
>>> x 1 pixel)
>>> during boot. MIPS Malta does (if no VGA module like cirrusfb is loaded,
>>> it will never set a different size), and even the 386 / x86_64 
>>> emulation
>>> has a (very short) time were the display size is unusually small.
>>
>> It doesn't.  It cycles through modes 640x480, 720x400, then VGA 
>> modes.  It never resizes to 1x1.
>>
>> But..  GTK should handle this better.  Even if the drawing area sets 
>> the size to 1x1, the window should maintain a size at least large 
>> enough to render the menu bar properly. ss/ssssssssssssss/
>
> Just run QEMU on a sufficiently slow host, for example QEMU in QEMU,
> or slow down the execution of QEMU by other means, then you will see
> which window sizes are then selected. Maybe you also need -singlestep.
> You _will_ get a very small window!
>
> I just got it using this call on a netbook running Ubuntu:
>
> qemu-system-i386 -L pc-bios -singlestep -d in_asm,out_asm
>
> Don't use KVM, of course - we want to slow down QEMU!
> Adding strace is also a good way to reduce execution speed.
>
> Cheers,
>
> Stefan Weil


This also works to get the small window:

gdb --args i386-softmmu/qemu-system-i386 -L pc-bios -singlestep

Set a breakpoint on gd_resize and run. Here is the result (2nd hit of
the breakpoint):

Breakpoint 2, gd_resize (ds=0x809f7c40) at 
/home/stefan/src/qemu/qemu.org/qemu/ui/gtk.c:182
182        GtkDisplayState *s = ds->opaque;
2: ds->surface->width = 9
1: ds->surface->height = 1

So the new window is 9 x 1 pixels.

Regards,
Stefan Weil


[-- Attachment #2: Type: text/html, Size: 6324 bytes --]