[Qemu-devel] scrollable window

[Qemu-devel] scrollable window

[Jim C. Brown]

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

I personally feel that a scrollable window is not very useful unless your host
resolution is smaller than your guest resolution. Hard to see what the point is
really... especially if you want to use full screens and mouse pointer
grabbing. Besides, it just looks ugly. I feel the conventional qemu window
simply looks more natural.

Anyways, this is a version of gtk2.c which gives the wanted scrolling feature.
I just started on this so expect ease-of-use bugs. :D Should work on windows
as well, but I have not been able to test this myself yet.

Should work with the latest gtk patches and files, just substitute that
gtk2.c (the scrolless one) with this version.

Current issues:

No fullscreen support. (Having a scrolled window in fullscreen mode may not
make a lot of sense anyways, but resizing the window and getting rid of the
scrollbars should be done.) Ctrl-Alt-F is recognized and its usage is untested
and likely to cause breakage. :D

When resolution of guest is smaller than the window, the window should
arguably be resized. Right now one just sees extra grey areas in the right and
bottom sides of the window.

The window can't be made smaller than 720x400.

Arguably, the scrollbars should disappear if the guest resolution completely
fits into the window - but this may be a matter of preferance.

When moving the mouse, the "viewport" should probably move as the mouse moves
around. Right now it just moves into the edge and disappears, requiring that
the grab be ended and the scrollbars manually adjusted in order to see the mouse pointer
again. This is very difficult to do without some sort of guest OS support
though.
	This would be vastly easier if mouse grabbing was not done. But then
	one would have problems with the host and guest pointers getting out
	of sync, which has been a well discussed topic.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

[-- Attachment #2: gtk2.c --]
[-- Type: text/plain, Size: 22188 bytes --]

/*
 * QEMU GTK2 display driver
 * based on SDL driver by Fabrice
 * 
 * Copyright (c) 2005 Jim Brown
 * 
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
 * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 * THE SOFTWARE.
 */
#include "vl.h"

#include <gtk/gtk.h>
#include <gdk/gdk.h>

#include "fullscreen.h"

/* define our own bitshift enums to allow qemugtk to know difference between left and right alt - something gtk doesnt provide in its modifiers mask. this uses qemu's own modifier_state[] map in order to guess correctly */
typedef enum
{
	gtkshiftleft = 1 << 0,
	gtkshiftright = 1 << 1,
	gtkcontrolleft = 1 << 2,
	gtkcontrolright = 1 << 3,
	gtkaltleft = 1 << 4,
	gtkaltright = 1 << 5,
	gtkcapslock = 1 << 6
} gtk2keymod;


static GtkWidget *window, *swindow;
static GtkWidget *event_port;
static GdkImage *image=NULL;
static GdkCursor *invisible_cursor;
static int ox = 0, oy = 0;
static int gui_grab; /* if true, all keyboard/mouse events are grabbed */
static int last_vm_running;
static int gui_saved_grab;
static int gui_fullscreen;
static int gui_key_modifier_pressed;
static int gui_keysym;
static int gui_fullscreen_initial_grab;
static int gui_grab_code = gtkaltleft | gtkcontrolleft;
static uint8_t modifiers_state[256];
static unsigned int cw, ch;
static gint cx, cy;

static gboolean gtk2_expose(GtkWidget *wid, GdkEventExpose *event)
{
    gdk_draw_image(event_port->window, wid->style->fg_gc[GTK_WIDGET_STATE(wid)], image, event->area.x, event->area.y, event->area.x, event->area.y, event->area.width, event->area.height);
    return TRUE;
}

static void gtk2_update(DisplayState *ds, int x, int y, int w, int h)
{
    //    printf("updating x=%d y=%d w=%d h=%d\n", x, y, w, h);
    GdkEventExpose ev;
    ev.area.x = x;
    ev.area.y = y;
    ev.area.width = w;
    ev.area.height = h;
    /* catch the first resize done by the init function - make sure we don't **
    ** try to draw an image until screen has been finalized/realized/etc */
    if (event_port->window != NULL)
	gtk2_expose(event_port, &ev);
}

static void gtk2_resize(DisplayState *ds, int w, int h)
{

    //    printf(" resizing to %d %d\n", w, h);

    if (gui_fullscreen)
    {
	if (cw != w || ch != h)
	{
	    fullscreen_switch(cx, cy, w, h); /* changing video modes */
/* apparently GTK enjoys moving static windows all over the place while
they are being resized - so we have to be tricky */
	    gtk_window_move(GTK_WINDOW(window), cx, cy);
	    gtk_window_move(GTK_WINDOW(window), 0, 0);
	}
    }

    cw = w; ch = h;

    if (image)
	 g_object_unref(image);

/* gdk_visual_get_best_with_depth() ??? but then how to paint onto window? */
    image = gdk_image_new(GDK_IMAGE_NORMAL, gdk_visual_get_system(), w, h);
    gdk_image_set_colormap(image, gdk_colormap_get_system());

    gtk_widget_set_size_request(swindow, w, h);
    gtk_widget_set_size_request(event_port, w, h);

    ds->data = image->mem;
    ds->linesize = image->bpl;
    ds->depth = image->bits_per_pixel;
    ds->width = w;
    ds->height = h;
    gtk2_update(ds, 0, 0, w, h);
}

/* generic keyboard conversion */

#include "gdk_keysym.h"
#include "keymaps.c"

static kbd_layout_t *kbd_layout = NULL;

static uint8_t gtk2_keyevent_to_keycode_generic(const GdkEventKey *ev)
{
    int keysym;
    /* workaround for X11+SDL bug with AltGR - is it still needed for Gtk2? */
    keysym = ev->keyval;
    if (keysym == 0 && ev->hardware_keycode == 113)
	keysym = GDK_Mode_switch;
    return keysym2scancode(kbd_layout, keysym);
}

/* specific keyboard conversions from scan codes */

#if defined(_WIN32)

#include <windows.h>

static UINT vk2scan(UINT vk)
{
	return MapVirtualKey(vk,0);
}
static uint8_t gtk2_keyevent_to_keycode(const GdkEventKey *ev)
{   
    return (uint8_t)vk2scan((UINT)(ev->hardware_keycode));
}

#else

static const uint8_t x_keycode_to_pc_keycode[61] = {
   0xc7,      /*  97  Home   */
   0xc8,      /*  98  Up     */
   0xc9,      /*  99  PgUp   */
   0xcb,      /* 100  Left   */
   0x4c,        /* 101  KP-5   */
   0xcd,      /* 102  Right  */
   0xcf,      /* 103  End    */
   0xd0,      /* 104  Down   */
   0xd1,      /* 105  PgDn   */
   0xd2,      /* 106  Ins    */
   0xd3,      /* 107  Del    */
   0x9c,      /* 108  Enter  */
   0x9d,      /* 109  Ctrl-R */
   0x0,       /* 110  Pause  */
   0xb7,      /* 111  Print  */
   0xb5,      /* 112  Divide */
   0xb8,      /* 113  Alt-R  */
   0xc6,      /* 114  Break  */   
   0xdb,         /* 115 windows left button */
   0xdc,         /* 116 windows right button */
   0xdd,         /* 117 right menu button */
   0x0,         /* 118 */
   0x0,         /* 119 */
   0x70,         /* 120 Hiragana_Katakana */
   0x0,         /* 121 */
   0x0,         /* 122 */
   0x73,         /* 123 backslash */
   0x0,         /* 124 */
   0x0,         /* 125 */
   0x0,         /* 126 */
   0x0,         /* 127 */
   0x0,         /* 128 */
   0x79,         /* 129 Henkan */
   0x0,         /* 130 */
   0x7b,         /* 131 Muhenkan */
   0x0,         /* 132 */
   0x7d,         /* 133 Yen */
   0x0,         /* 134 */
   0x0,         /* 135 */
   0x47,         /* 136 KP_7 */
   0x48,         /* 137 KP_8 */
   0x49,         /* 138 KP_9 */
   0x4b,         /* 139 KP_4 */
   0x4c,         /* 140 KP_5 */
   0x4d,         /* 141 KP_6 */
   0x4f,         /* 142 KP_1 */
   0x50,         /* 143 KP_2 */
   0x51,         /* 144 KP_3 */
   0x52,         /* 145 KP_0 */
   0x53,         /* 146 KP_. */
   0x47,         /* 147 KP_HOME */
   0x48,         /* 148 KP_UP */
   0x49,         /* 149 KP_PgUp */
   0x4b,         /* 150 KP_Left */
   0x4c,         /* 151 KP_ */
   0x4d,         /* 152 KP_Right */
   0x4f,         /* 153 KP_End */
   0x50,         /* 154 KP_Down */
   0x51,         /* 155 KP_PgDn */
   0x52,         /* 156 KP_Ins */
   0x53,         /* 157 KP_Del */
};

static uint8_t gtk2_keyevent_to_keycode(const GdkEventKey *ev)
{
    int keycode;

    keycode = ev->hardware_keycode;

    if (keycode < 9) {
	keycode = 0;
    } else if (keycode < 97) {
	keycode -= 8; /* just an offset */
    } else if (keycode < 158) {
	/* use conversion table */
	keycode = x_keycode_to_pc_keycode[keycode - 97];
    } else {
	keycode = 0;
    }
    return keycode;
}

#endif

static void reset_keys(void)
{
    int i;
    for(i = 0; i < 256; i++) {
	if (modifiers_state[i]) {
	    if (i & 0x80)
		kbd_put_keycode(0xe0);
	    kbd_put_keycode(i | 0x80);
	    modifiers_state[i] = 0;
	}
    }
}

/* convert GDK modifiers and invoke ugly hack to distinguish
between left and right shift/control/alt */
static guint gtk2_GetModState(const GdkEventKey *ev)
{
	guint key = 0, keyval = ev->keyval, state = ev->state;
	switch(keyval)
	{
		case GDK_Shift_L:
			if (ev->type != GDK_KEY_RELEASE)
				key |= gtkshiftleft;
			keyval = 1;
			break;
		case GDK_Shift_R:
			if (ev->type != GDK_KEY_RELEASE)
				key |= gtkshiftright;
			keyval = 1;
			break;
		case GDK_Control_L:
			if (ev->type != GDK_KEY_RELEASE)
				key |= gtkcontrolleft;
			keyval = 2;
			break;
		case GDK_Control_R:
			if (ev->type != GDK_KEY_RELEASE)
				key |= gtkcontrolright;
			keyval = 2;
			break;
		case GDK_Alt_L:
			if (ev->type != GDK_KEY_RELEASE)
				key |= gtkaltleft;
			keyval = 3;
			break;
		case GDK_Alt_R:
			if (ev->type != GDK_KEY_RELEASE)
				key |= gtkaltright;
			keyval = 3;
			break;
		case GDK_Caps_Lock:
			if (ev->type != GDK_KEY_RELEASE)
				key |= gtkcapslock;
			keyval = 4;
			break;
		default:
			keyval = 0;
			break;
	}
	if (keyval != 1 && (state & GDK_SHIFT_MASK))
	{
		if (modifiers_state[0x2a])
			key |= gtkshiftleft;
		if (modifiers_state[0x36])
			key |= gtkshiftright;
	}
	if (keyval != 2 && (state & GDK_CONTROL_MASK))
	{
		if (modifiers_state[0x1d])
			key |= gtkcontrolleft;
		if (modifiers_state[0x9d])
			key |= gtkcontrolright;
	}
	if (keyval != 3 && (state & GDK_MOD1_MASK)) /* fixme: need to do a check to make sure that alt is mapped to GDK_MOD1_MASK in the GDK_Keymap */
	{
		if (modifiers_state[0x38])
			key |= gtkaltleft;
		if (modifiers_state[0xb8])
			key |= gtkaltright;
	}
	if (keyval != 4 && (state & GDK_LOCK_MASK))
		key |= gtkcapslock;
	return key;
}

static void gtk2_process_key(GdkEventKey *ev)
{
    int keycode, v;

    if (ev->keyval == GDK_Pause) {
	/* specific case */
	v = 0;
	if (ev->type == GDK_KEY_RELEASE)
	    v |= 0x80;
	kbd_put_keycode(0xe1);
	kbd_put_keycode(0x1d | v);
	kbd_put_keycode(0x45 | v);
	return;
    }

    if (kbd_layout) {
	keycode = gtk2_keyevent_to_keycode_generic(ev);
    } else {
	keycode = gtk2_keyevent_to_keycode(ev);
    }

    switch(keycode) {
    case 0x00:
	/* sent when leaving window: reset the modifiers state */
	reset_keys();
	return;
    case 0x2a:                          /* Left Shift */
    case 0x36:                          /* Right Shift */
    case 0x1d:                          /* Left CTRL */
    case 0x9d:                          /* Right CTRL */
    case 0x38:                          /* Left ALT */
    case 0xb8:                         /* Right ALT */
	if (ev->type == GDK_KEY_RELEASE)
	    modifiers_state[keycode] = 0;
	else
	    modifiers_state[keycode] = 1;
	break;
    case 0x45: /* num lock */
    case 0x3a: /* caps lock */
	/* GTK does send the key up event, so we dont generate it */
	/*kbd_put_keycode(keycode);
	kbd_put_keycode(keycode | 0x80);
	return;*/
	break;
    }

    /* now send the key code */
    if (keycode & 0x80)
	kbd_put_keycode(0xe0);
    if (ev->type == GDK_KEY_RELEASE)
	kbd_put_keycode(keycode | 0x80);
    else
	kbd_put_keycode(keycode & 0x7f);
}

static void gtk2_update_caption(void)
{
    char buf[1024];
    strcpy(buf, "QEMU Gtk");
    if (!vm_running) {
	strcat(buf, " [Stopped]");
    }
    if (gui_grab) {
	strcat(buf, " - Press Ctrl-Alt to exit grab");
    }
    gtk_window_set_title(GTK_WINDOW(window), buf);
}

/* what a nasty hack. this should be a part of the GDK, not external!!! */
#include "gdk_set_window_pointer.c"

static void gtk2_grab_start(void)
{
    gint y;
    guint events;
    GdkModifierType state; /* dummy var */
    events = GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_SCROLL_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK;
    y = gdk_pointer_grab(event_port->window, TRUE, events, event_port->window, invisible_cursor, GDK_CURRENT_TIME);
    if (y)
	printf("GTK Warning - pointer grab failed!\n");
    y = gdk_keyboard_grab(event_port->window, TRUE, GDK_CURRENT_TIME);
    if (y)
	printf("GTK Warning - keyboard grab failed!\n");
    /* do a dummy read to avoid moving mouse - set ox and oy to stay in sync */
    gdk_window_get_pointer(event_port->window, &ox, &oy, &state);
    gui_grab = 1;
    gtk2_update_caption();
}

static void gtk2_grab_end(void)
{
    gdk_pointer_ungrab(GDK_CURRENT_TIME);
    gdk_keyboard_ungrab(GDK_CURRENT_TIME);
    gdk_window_set_pointer(event_port->window, cx, cy);
    gui_grab = 0;
    gtk2_update_caption();
}

static gboolean gtk2_send_mouse_event(GtkWidget *wid, GdkEvent *ev)
{
    int x, y, dx, dy, dz, state, buttons;

    if (ev->type == GDK_2BUTTON_PRESS || ev->type == GDK_3BUTTON_PRESS)
	return TRUE; /* double or triple click - superflurious - ignore */

    if (gui_grab)
    {

    if (ev->type == GDK_MOTION_NOTIFY && ev->motion.is_hint)
    {
	gdk_window_get_pointer(ev->motion.window, &x, &y, (GdkModifierType*)&state);
    }
    else
    {
	x = ev->motion.x;
	y = ev->motion.y;
	/* scroll.state occupies a different position in the union */
	if (ev->type == GDK_SCROLL)
	state = ev->scroll.state;
	else
	state = ev->motion.state;
    }

    dx = x - ox;
    dy = y - oy;
    // prevent infinite looping - 2.6.X
    if ((ev->type == GDK_MOTION_NOTIFY) && (dx == 0) && (dy == 0)) return TRUE;
    dz = 0;
    ox = x;
    oy = y;

    buttons = 0;
    if ((state & GDK_BUTTON1_MASK))
	buttons |= MOUSE_EVENT_LBUTTON;
    if ((state & GDK_BUTTON3_MASK))
	buttons |= MOUSE_EVENT_RBUTTON;
    if ((state & GDK_BUTTON2_MASK))
	buttons |= MOUSE_EVENT_MBUTTON;

    if (ev->type == GDK_BUTTON_PRESS)
    {
	if (ev->button.button == 1)
	    buttons |= MOUSE_EVENT_LBUTTON;
	if (ev->button.button == 3)
	    buttons |= MOUSE_EVENT_RBUTTON;
	if (ev->button.button == 2)
	    buttons |= MOUSE_EVENT_MBUTTON;
    }
    else if (ev->type == GDK_BUTTON_RELEASE)
    {
    /* not sure if this is really necessary, but just to be on the safe side **
    ** reset qemu's mask so that a button thats being released will be shown **
    * missing from the mask (which lets the guest know the button was relased */
	buttons = 0;

	if ((state & GDK_BUTTON1_MASK) && ev->button.button != 1)
	    buttons |= MOUSE_EVENT_LBUTTON;
	if ((state & GDK_BUTTON3_MASK) && ev->button.button != 3)
	    buttons |= MOUSE_EVENT_RBUTTON;
	if ((state & GDK_BUTTON2_MASK) && ev->button.button != 2)
	    buttons |= MOUSE_EVENT_MBUTTON;
    }
    else if (ev->type == GDK_SCROLL)
    {
	/* test wheel - copied from Sebastien Bechet's gtk.c */
	if (ev->scroll.direction == GDK_SCROLL_UP)
	    dz--;
	if (ev->scroll.direction == GDK_SCROLL_DOWN)
	    dz++;
    }

    if (ev->type == GDK_MOTION_NOTIFY)
    {
	/* wrap the x,y coordinates back onto the window */
	if (ev->motion.x <= (cw/4))
	    x = ((3*cw/4)-1);
	if (ev->motion.y <= (ch/4))
	    y = ((3*ch/4)-1);
	if (ev->motion.x >= (3*cw/4))
	    x = (cw/4)+1;
	if (ev->motion.y >= (3*ch/4))
	    y = (ch/4)+1;

	/* make internal mouse move invisible */
	ox = x;
	oy = y;

	gdk_window_set_pointer(event_port->window, (gint)x, (gint)y);
    }

    kbd_mouse_event(dx, dy, dz, buttons);

    }
    else
    {

    if (ev->type == GDK_BUTTON_PRESS && ev->button.button == 1)
    {
	/* start grabbing all events */
	gtk2_grab_start();
    }

    }
    return TRUE;
}

static void toggle_full_screen(DisplayState *ds)
{
    gui_fullscreen = !gui_fullscreen;
    gtk2_resize(ds, image->width, image->height);
    if (gui_fullscreen) {
	gui_saved_grab = gui_grab;
	gtk2_grab_start();
	gtk_window_get_position(GTK_WINDOW(window), &cx, &cy);
	gtk_window_move(GTK_WINDOW(window), 0, 0);
	fullscreen_switch(cx, cy, ds->width, ds->height);
    } else {
	fullscreen_reset();
	gtk_window_move(GTK_WINDOW(window), cx, cy);
	if (!gui_saved_grab)
	    gtk2_grab_end();
    }
    vga_invalidate_display();
    vga_update_display();
}

static gboolean gtk2_key_press(GtkWidget *wid, GdkEventKey *ev, DisplayState *ds)
{
	int mod_state;
	    if (ev->type == GDK_KEY_PRESS) {
		mod_state = (gtk2_GetModState(ev) & (int)gui_grab_code) == (int)gui_grab_code;
		gui_key_modifier_pressed = mod_state;
		if (gui_key_modifier_pressed) {
		    int keycode;
		    keycode = gtk2_keyevent_to_keycode(ev);
		    switch(keycode) {
		    case 0x21: /* 'f' key on US keyboard */
			toggle_full_screen(ds);
			gui_keysym = 1;
			break;
		    case 0x02 ... 0x0a: /* '1' to '9' keys */ 
			console_select(keycode - 0x02);
			if (is_active_console(vga_console)) {
			    /* tell the vga console to redisplay itself */
			    vga_invalidate_display();
			} else {
			    /* display grab if going to a text console */
			    if (gui_grab)
				gtk2_grab_end();
			}
			gui_keysym = 1;
			break;
		    default:
			break;
		    }
		} else if (!is_active_console(vga_console)) {
		    int keysym;
		    keysym = 0;
		    if (ev->state & GDK_CONTROL_MASK) {
			switch(ev->keyval) {
			case GDK_Up: keysym = QEMU_KEY_CTRL_UP; break;
			case GDK_Down: keysym = QEMU_KEY_CTRL_DOWN; break;
			case GDK_Left: keysym = QEMU_KEY_CTRL_LEFT; break;
			case GDK_Right: keysym = QEMU_KEY_CTRL_RIGHT; break;
			case GDK_Home: keysym = QEMU_KEY_CTRL_HOME; break;
			case GDK_End: keysym = QEMU_KEY_CTRL_END; break;
			case GDK_Page_Up: keysym = QEMU_KEY_CTRL_PAGEUP; break;
			case GDK_Page_Down: keysym = QEMU_KEY_CTRL_PAGEDOWN; break;
			default: break;
			}
		    } else {
			switch(ev->keyval) {
			case GDK_Up: keysym = QEMU_KEY_UP; break;
			case GDK_Down: keysym = QEMU_KEY_DOWN; break;
			case GDK_Left: keysym = QEMU_KEY_LEFT; break;
			case GDK_Right: keysym = QEMU_KEY_RIGHT; break;
			case GDK_Home: keysym = QEMU_KEY_HOME; break;
			case GDK_End: keysym = QEMU_KEY_END; break;
			case GDK_Page_Up: keysym = QEMU_KEY_PAGEUP; break;
			case GDK_Page_Down: keysym = QEMU_KEY_PAGEDOWN; break;
			case GDK_BackSpace: keysym = QEMU_KEY_BACKSPACE; break;
			case GDK_Delete: keysym = QEMU_KEY_DELETE; break;
			default: break;
			}
		    }
		    if (keysym) {
			kbd_put_keysym(keysym);
		    } /*else if (ev->key.keysym.unicode != 0) {
			kbd_put_keysym(ev->key.keysym.unicode);
		    }*/
		}
	    } else if (ev->type == GDK_KEY_RELEASE) {
		mod_state = (gtk2_GetModState(ev) & gui_grab_code);
		if (!mod_state) {
		    if (gui_key_modifier_pressed) {
			if (gui_keysym == 0) {
			    /* exit/enter grab if pressing Ctrl-Alt */
			    if (!gui_grab)
				gtk2_grab_start();
			    else
				gtk2_grab_end();
			    /* SDL does not send back all the
			       modifiers key, so we must correct it */
			    reset_keys();
			    return TRUE;
			}
			gui_key_modifier_pressed = 0;
			gui_keysym = 0;
		    }
		}
	    }
	    if (is_active_console(vga_console)) 
		gtk2_process_key(ev);
	return TRUE;
}

static void gtk2_refresh(DisplayState *ds)
{
    if (last_vm_running != vm_running) {
	last_vm_running = vm_running;
	gtk2_update_caption();
    }
    if (ds->data != image->mem)
    {
	ds->data = image->mem;
    }

    if (is_active_console(vga_console))                                         
	vga_update_display();                                                   
    while (gtk_events_pending())
	gtk_main_iteration();
}

static void gtk2_cleanup(void) 
{
    if (gtk_main_level() != 0)
	gtk_main_quit();
    fullscreen_cleanup();
}

static gboolean gtk2_deletewin(void)
{
    /* signal qemu that its time to shut itself off - this is the place that we hook to trap attempts to close the main qemu window */
    qemu_system_shutdown_request();
    return FALSE;
    return TRUE; /* dont close the window right away! give qemu time to think */
}

static void gtk2_destroy(void)
{
    /* ideally we would call a hook here so qemu could clean itself up */
    gtk2_cleanup();
}

void gtk2_display_init(DisplayState *ds, int full_screen)
{
    int events;

#if defined(__APPLE__)
    /* always use generic keymaps */
    if (!keyboard_layout)
	keyboard_layout = "en-us";
#endif
    if(keyboard_layout) {
	kbd_layout = init_keyboard_layout(keyboard_layout);
	if (!kbd_layout)
	    exit(1);
    }

    if (!gtk_init_check (0,NULL))
    {
	fprintf(stderr, "Could not load GTK\n");
	exit(0);
    }
    fullscreen_init();

/* note: adding GDK_DRAG_* and GDK_DROP_* would provide a mechanism for supporting drag and drop between host and guest */
    events = GDK_EXPOSURE_MASK | GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK | GDK_KEY_PRESS_MASK | GDK_KEY_RELEASE_MASK | GDK_ENTER_NOTIFY_MASK | GDK_LEAVE_NOTIFY_MASK | GDK_FOCUS_CHANGE_MASK | GDK_SCROLL_MASK | GDK_STRUCTURE_MASK;

    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    swindow = gtk_scrolled_window_new(NULL,NULL);
    event_port = gtk_event_box_new();
    gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(swindow), GTK_POLICY_ALWAYS, GTK_POLICY_ALWAYS);
    gtk_container_add(GTK_CONTAINER(window), swindow);
    gtk_scrolled_window_add_with_viewport(GTK_SCROLLED_WINDOW(swindow), event_port);
    gtk_widget_set_events(event_port, events);
    gtk_window_set_default_size(GTK_WINDOW(window), 720, 400);
    gtk_widget_set_size_request(window, 720, 400);
    gtk_widget_set_size_request(swindow, 720, 400);
    gtk_widget_set_size_request(event_port, 720, 400);
    gtk_window_set_gravity(GTK_WINDOW(window), GDK_GRAVITY_STATIC);
    gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);

    g_signal_connect(G_OBJECT(window), "delete_event", G_CALLBACK(gtk2_deletewin), NULL);
    g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk2_destroy), NULL);
    gtk_container_set_border_width(GTK_CONTAINER(window), 0);

    g_signal_connect(G_OBJECT(event_port), "expose_event", G_CALLBACK(gtk2_expose), NULL);
    g_signal_connect(G_OBJECT(event_port), "motion_notify_event", G_CALLBACK(gtk2_send_mouse_event), NULL);
    g_signal_connect(G_OBJECT(event_port), "button_press_event", G_CALLBACK(gtk2_send_mouse_event), NULL);
    g_signal_connect(G_OBJECT(event_port), "button_release_event", G_CALLBACK(gtk2_send_mouse_event), NULL);
    g_signal_connect(G_OBJECT(event_port), "scroll_event", G_CALLBACK(gtk2_send_mouse_event), NULL);
    g_signal_connect(G_OBJECT(window), "key_press_event", G_CALLBACK(gtk2_key_press), ds);
    g_signal_connect(G_OBJECT(window), "key_release_event", G_CALLBACK(gtk2_key_press), ds);

    ds->dpy_update = gtk2_update;
    ds->dpy_resize = gtk2_resize;
    ds->dpy_refresh = gtk2_refresh;

    gchar nullpixdata[1] = { 0 };
    GdkColor nullcolor = { 0, 0, 0, 0 };
    GdkPixmap *invis = gdk_bitmap_create_from_data(window->window, nullpixdata, 1, 1);
    invisible_cursor = gdk_cursor_new_from_pixmap(invis, invis, &nullcolor, &nullcolor, 0, 0);

    gtk2_resize(ds, 720, 400);
    gtk2_update_caption();
    gui_grab = 0;

    gtk_widget_show(event_port);
    gtk_widget_show(swindow);
    gtk_widget_show(window);
    if (full_screen) {
	gui_fullscreen = 1;
	gui_fullscreen_initial_grab = 1;
	gtk2_grab_start();
    }
}

Re: [Qemu-devel] scrollable window

[Ashish Naik]

HI,

I am a user of Qemu trying to run Windows 2000 on my G4 Powerbook. I am not
very comfortable with the small qemu window and want to make it bigger. But
this fails if I try to resize the window by dragging it. The qemu crashes if
I do so. 

Having fullscreen mode either is not of help as I cant return to OS X using
Command-tab. Is there a way out?

I suspect that if I increase the quest resolution, fonts will become too
small to read with 12" screen. I have not been able to test this as   my
Windows installable has failed so far. I am trying right now and will try to
increase the guest resolution.

I think the qemu window should open with 80% of available screen size. Is
that difficult to achieve?

Thanks and Regards,
Ashish Naik


> From: "Jim C. Brown" <jma5@umd.edu>
> Reply-To: <qemu-devel@nongnu.org>
> Date: Sun, 10 Jul 2005 01:58:35 -0400
> To: <qemu-devel@nongnu.org>
> Subject: [Qemu-devel] scrollable window
> 
> I personally feel that a scrollable window is not very useful unless your host
> resolution is smaller than your guest resolution. Hard to see what the point
> is
> really... especially if you want to use full screens and mouse pointer
> grabbing. Besides, it just looks ugly. I feel the conventional qemu window
> simply looks more natural.
> 
> Anyways, this is a version of gtk2.c which gives the wanted scrolling feature.
> I just started on this so expect ease-of-use bugs. :D Should work on windows
> as well, but I have not been able to test this myself yet.
> 
> Should work with the latest gtk patches and files, just substitute that
> gtk2.c (the scrolless one) with this version.
> 
> Current issues:
> 
> No fullscreen support. (Having a scrolled window in fullscreen mode may not
> make a lot of sense anyways, but resizing the window and getting rid of the
> scrollbars should be done.) Ctrl-Alt-F is recognized and its usage is untested
> and likely to cause breakage. :D
> 
> When resolution of guest is smaller than the window, the window should
> arguably be resized. Right now one just sees extra grey areas in the right and
> bottom sides of the window.
> 
> The window can't be made smaller than 720x400.
> 
> Arguably, the scrollbars should disappear if the guest resolution completely
> fits into the window - but this may be a matter of preferance.
> 
> When moving the mouse, the "viewport" should probably move as the mouse moves
> around. Right now it just moves into the edge and disappears, requiring that
> the grab be ended and the scrollbars manually adjusted in order to see the
> mouse pointer
> again. This is very difficult to do without some sort of guest OS support
> though.
> This would be vastly easier if mouse grabbing was not done. But then
> one would have problems with the host and guest pointers getting out
> of sync, which has been a well discussed topic.
> 
> --
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] scrollable window

[Ashish Naik]

I got the magic to work  finally :)

Windows 2000 Pr is running fine and increased resolution that increased the
window size and I am comfortable with it.

I am using Q to run Qemu which has good feature like saving the state so
that I don't have to reboot again which takes time.


Thanks and Regards,
Ashish Naik


> From: Ashish Naik <ashishn@mahindrabt.com>
> Reply-To: <qemu-devel@nongnu.org>
> Date: Sun, 10 Jul 2005 12:20:56 +0530
> To: <qemu-devel@nongnu.org>
> Subject: Re: [Qemu-devel] scrollable window
> 
> HI,
> 
> I am a user of Qemu trying to run Windows 2000 on my G4 Powerbook. I am not
> very comfortable with the small qemu window and want to make it bigger. But
> this fails if I try to resize the window by dragging it. The qemu crashes if
> I do so.
> 
> Having fullscreen mode either is not of help as I cant return to OS X using
> Command-tab. Is there a way out?
> 
> I suspect that if I increase the quest resolution, fonts will become too
> small to read with 12" screen. I have not been able to test this as   my
> Windows installable has failed so far. I am trying right now and will try to
> increase the guest resolution.
> 
> I think the qemu window should open with 80% of available screen size. Is
> that difficult to achieve?
> 
> Thanks and Regards,
> Ashish Naik
> 
> 
>> From: "Jim C. Brown" <jma5@umd.edu>
>> Reply-To: <qemu-devel@nongnu.org>
>> Date: Sun, 10 Jul 2005 01:58:35 -0400
>> To: <qemu-devel@nongnu.org>
>> Subject: [Qemu-devel] scrollable window
>> 
>> I personally feel that a scrollable window is not very useful unless your
>> host
>> resolution is smaller than your guest resolution. Hard to see what the point
>> is
>> really... especially if you want to use full screens and mouse pointer
>> grabbing. Besides, it just looks ugly. I feel the conventional qemu window
>> simply looks more natural.
>> 
>> Anyways, this is a version of gtk2.c which gives the wanted scrolling
>> feature.
>> I just started on this so expect ease-of-use bugs. :D Should work on windows
>> as well, but I have not been able to test this myself yet.
>> 
>> Should work with the latest gtk patches and files, just substitute that
>> gtk2.c (the scrolless one) with this version.
>> 
>> Current issues:
>> 
>> No fullscreen support. (Having a scrolled window in fullscreen mode may not
>> make a lot of sense anyways, but resizing the window and getting rid of the
>> scrollbars should be done.) Ctrl-Alt-F is recognized and its usage is
>> untested
>> and likely to cause breakage. :D
>> 
>> When resolution of guest is smaller than the window, the window should
>> arguably be resized. Right now one just sees extra grey areas in the right
>> and
>> bottom sides of the window.
>> 
>> The window can't be made smaller than 720x400.
>> 
>> Arguably, the scrollbars should disappear if the guest resolution completely
>> fits into the window - but this may be a matter of preferance.
>> 
>> When moving the mouse, the "viewport" should probably move as the mouse moves
>> around. Right now it just moves into the edge and disappears, requiring that
>> the grab be ended and the scrollbars manually adjusted in order to see the
>> mouse pointer
>> again. This is very difficult to do without some sort of guest OS support
>> though.
>> This would be vastly easier if mouse grabbing was not done. But then
>> one would have problems with the host and guest pointers getting out
>> of sync, which has been a well discussed topic.
>> 
>> --
>> Infinite complexity begets infinite beauty.
>> Infinite precision begets infinite perfection.
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] scrollable window

[Jim C. Brown]

On Sun, Jul 10, 2005 at 04:37:45PM +0530, Ashish Naik wrote:
> I am using Q to run Qemu which has good feature like saving the state so
> that I don't have to reboot again which takes time.
> 

plain qemu has that.

Anyways, I just like to point out that I have never tested GTK with OS X, nor
have I met a tester who is willing to do so for me.

Incidently, doesn't Q require that qemu use Cocoa? My patch requires that qemu
use the GTK interface and doesn't work with Cocoa.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] scrollable window

[user user]

Why not make a Win32 GUI version?

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Qemu-devel] scrollable window

[Jim C. Brown]

On Sun, Jul 10, 2005 at 08:27:14AM -0700, user user wrote:
> Why not make a Win32 GUI version?
> 

Keep in mind that I'm primarily a Linux/GNU/Xlib coder.

>From what Fabrice Bellard has told me, a native Win32 GUI is the eventual plan,
and he considers GTK version for Linux/X11 only.

He also said that a dumb minimally usable GUI was ok as a starting point, as
once the basic parts were implemented, it would be very easy to add the real
functionality to the GUI later on. I'm working on a really simpleton version
right now. (The scrollable window is in fact the first version that I've
released which even uses any real GTK widgets besides the window itself.
This is one major advantage that GTK has over Xlib - writting a scrollable
window using Xlib would have been considerably more difficult.)

If you are asking why I don't release a Win32 version with the scrollable window,
it's mainly because I don't know what the Win32 equivalent of GtkScrollWindow
is.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] scrollable window

[jeebs]

"Jim C. Brown"


>I personally feel that a scrollable window is not very useful unless your 
>host
> resolution is smaller than your guest resolution. Hard to see what the 
> point is

Or the same size.  Don't forget, Windows XP will cover up part of the window 
even when the GTK version switches to 'full screen'.

And a lot of times, guest resolution will be higher.  Some things just seem 
to expect 1024x768 or 1280x1024 (or whatever) resolution.

A scrollable window is just a nice fall back if nothing else is convenient.

Sometimes, full screen is just too darn inconvenient.  Personally, I can't 
stand full screen even with VMWare.  I like being able to easily access my 
desktop when I want to, be able to read some data and type it into the 
guest, and so on.  (Without having to switch screens back and forth)

Not everybody in the world uses a 128x1024 screen.  Or even 1024x768.

Some, such as myself, still use 800x600.  I do it out of necessity.  I have 
poor eyesight and don't have the spare cash (or desk space!) for a 21 inch 
monitor.  And LCD monitors tend to have too high a native resolution.  With 
my current 17" monitor, I simply can't handle anything beyond 800x600.

So, a scrollable window makes using qemu (or vmware) more convenient.

Sure, scaling the window so the guest thinks it's 1024x768 (or whatever) 
when it's really much smaller, is probably a better choice.  As would be the 
video card providing custom sizes (700x400, or whatever) so XP will think 
that's what the display really is, and the actual qemu/vmware window 
wouldn't have to be scrolled, scaled or even full screened.

But scroll windows are a good 'if nothing else works' kind of situation for 
most people, and useful for some of us.



> Anyways, this is a version of gtk2.c which gives the wanted scrolling 
> feature.
> I just started on this so expect ease-of-use bugs. :D Should work on 
> windows
> as well, but I have not been able to test this myself yet.

Unfortunately, I can't test it for you on a Windows host.

A bit of a long story, but at the moment, I'm stuck with a single hard drive 
and cd burner.  I can't access my second hard drive, which is where qemu and 
my test OS images are stored.

Sorry.

Re: [Qemu-devel] scrollable window

[Herbert Poetzl]

On Sun, Jul 10, 2005 at 11:37:07AM -0500, jeebs@yango.us wrote:
> "Jim C. Brown"
> 
> 
> >I personally feel that a scrollable window is not very useful unless your 
> >host
> > resolution is smaller than your guest resolution. Hard to see what the 
> > point is
> 
> Or the same size.  Don't forget, Windows XP will cover up part of the window 
> even when the GTK version switches to 'full screen'.
> 
> And a lot of times, guest resolution will be higher.  Some things just seem 
> to expect 1024x768 or 1280x1024 (or whatever) resolution.
> 
> A scrollable window is just a nice fall back if nothing else is convenient.
> 
> Sometimes, full screen is just too darn inconvenient.  Personally, I can't 
> stand full screen even with VMWare.  I like being able to easily access my 
> desktop when I want to, be able to read some data and type it into the 
> guest, and so on.  (Without having to switch screens back and forth)
> 
> Not everybody in the world uses a 128x1024 screen.  Or even 1024x768.
> 
> Some, such as myself, still use 800x600.  I do it out of necessity.  I have 
> poor eyesight and don't have the spare cash (or desk space!) for a 21 inch 
> monitor.  And LCD monitors tend to have too high a native resolution.  With 
> my current 17" monitor, I simply can't handle anything beyond 800x600.

why not use a virtual desktop of larger size and 
pan the mouse to the current 'view' which can be 800x600
or even less if your bad eyesight requires that ...
(on X you can change that with CTRL-ALT-+/- and the
mouse will be handled properly, including pan ranges)

best,
Herbert

> So, a scrollable window makes using qemu (or vmware) more convenient.
> 
> Sure, scaling the window so the guest thinks it's 1024x768 (or whatever) 
> when it's really much smaller, is probably a better choice.  As would be the 
> video card providing custom sizes (700x400, or whatever) so XP will think 
> that's what the display really is, and the actual qemu/vmware window 
> wouldn't have to be scrolled, scaled or even full screened.
> 
> But scroll windows are a good 'if nothing else works' kind of situation for 
> most people, and useful for some of us.
> 
> 
> 
> > Anyways, this is a version of gtk2.c which gives the wanted scrolling 
> > feature.
> > I just started on this so expect ease-of-use bugs. :D Should work on 
> > windows
> > as well, but I have not been able to test this myself yet.
> 
> Unfortunately, I can't test it for you on a Windows host.
> 
> A bit of a long story, but at the moment, I'm stuck with a single hard drive 
> and cd burner.  I can't access my second hard drive, which is where qemu and 
> my test OS images are stored.
> 
> Sorry.
> 
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] scrollable window

[Jim C. Brown]

On Sun, Jul 10, 2005 at 11:37:07AM -0500, jeebs@yango.us wrote:
> "Jim C. Brown"
> 
> 
> >I personally feel that a scrollable window is not very useful unless your 
> >host
> > resolution is smaller than your guest resolution. Hard to see what the 
> > point is
> 
> Or the same size.  Don't forget, Windows XP will cover up part of the window 
> even when the GTK version switches to 'full screen'.
> 

This is easily worked around by activiating the auto-hide feature of the taskbar.
Since qemu gtk grabs the mouse and won't let it move outside the center box
(set to about half the area of the host resolution) the real mouse pointer
never moves over the taskbar, so it will never come out of hiding.

A way to force the taskbar on when in fullscreen mode (and reset it back to
its original mode when leaving) would make that problem go away entirely.

> And a lot of times, guest resolution will be higher.  Some things just seem 
> to expect 1024x768 or 1280x1024 (or whatever) resolution.
> 
> A scrollable window is just a nice fall back if nothing else is convenient.
> 
> Some, such as myself, still use 800x600.  I do it out of necessity.  I have 
> poor eyesight and don't have the spare cash (or desk space!) for a 21 inch 
> monitor.  And LCD monitors tend to have too high a native resolution.  With 
> my current 17" monitor, I simply can't handle anything beyond 800x600.
> 
> So, a scrollable window makes using qemu (or vmware) more convenient.
> 

I never though of it that way. You're right, having the ability to use
scrolled windows does add more utility to qemu.

> Sure, scaling the window so the guest thinks it's 1024x768 (or whatever) 
> when it's really much smaller, is probably a better choice.  As would be the 
> video card providing custom sizes (700x400, or whatever) so XP will think 
> that's what the display really is, and the actual qemu/vmware window 
> wouldn't have to be scrolled, scaled or even full screened.
> 

Well, scaling is actually not so convient as it can make the graphics, especially
characters in small font, too small to see clearly. Scaling to make the window
larger than the guest resolution might be useful though.

Custom sizes wouldn't work too well, it seems a lot of graphics programs like
to insist on standard modes (640x480, 800x600, etc).

> Unfortunately, I can't test it for you on a Windows host.
> 
> A bit of a long story, but at the moment, I'm stuck with a single hard drive 
> and cd burner.  I can't access my second hard drive, which is where qemu and 
> my test OS images are stored.
> 
> Sorry.
> 

Ouch. Good luck.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] scrollable window

[Jim C. Brown]

On Sun, Jul 10, 2005 at 07:32:01PM +0200, Herbert Poetzl wrote:
> > Some, such as myself, still use 800x600.  I do it out of necessity.  I have 
> > poor eyesight and don't have the spare cash (or desk space!) for a 21 inch 
> > monitor.  And LCD monitors tend to have too high a native resolution.  With 
> > my current 17" monitor, I simply can't handle anything beyond 800x600.
> 
> why not use a virtual desktop of larger size and 
> pan the mouse to the current 'view' which can be 800x600
> or even less if your bad eyesight requires that ...
> (on X you can change that with CTRL-ALT-+/- and the
> mouse will be handled properly, including pan ranges)
> 
> best,
> Herbert

That works too. So Herbert, tell us how does one set up a virtual screen
a la X Server style when one is using Windows? Presumably there is some
"powertoy" out there which does this, but I don't know of any myself.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] scrollable window

[jeebs]

"Herbert Poetzl"

>> Some, such as myself, still use 800x600.  I do it out of necessity.  I
>> have
>> poor eyesight and don't have the spare cash (or desk space!) for a 21
>> inch
>> monitor.  And LCD monitors tend to have too high a native resolution.
>> With
>> my current 17" monitor, I simply can't handle anything beyond 800x600.
>
> why not use a virtual desktop of larger size and

I've tried virtual desktops a couple times, but I never really liked them.

And not every programm really worked right.  Some still want the full
virtual desktop size instead of visible size.

Shifting the desktop window around the whole virtual desktop was just never
convenient.  It's just a heck of a kludge.  It works, but it's not really
usable.

It's a lot easier to just leave it at 800x600 which I can see.  And, after
all, it was the size that Windows XP was actually designed and optimized
for.

> pan the mouse to the current 'view' which can be 800x600
> or even less if your bad eyesight requires that ...

I can manage 800x600 on a 17" monitor okay.  For short times, I can manage
1024x768 or 1280x1024 if I have to.  But not easily.  800x600 is okay
though.  I do have quite a few 'floaters' in my eyes, but that doesn't
really effect the resolution I need.

And no, new glasses don't really help all that much...

Eventually, I will need to get a large LCD monitor and just use it at a 
reduced resolution.

At the moment, that's too expensive.  However, with manufacturers playing 
around with printable flat screens, organic lcd's, etc, things will 
hopefully change in a year or two, and large LCD's will be cheap enough to 
buy a large 19" or 21" LCD monitor.


I still think that for qemu (or any vitual computer), scroll windows, scaled
displays and even custom sized guest screens are simply a good idea.

That way you can have the qemu window at whatever size is convenient.

My situation is not common, but it's still just as useful if you are using a
1024x768 desktop and need that size or larger in qemu.

Or are using an LCD monitor with a fixed 1024x768 display (or whatever) and
need to use a guest screen larger than that.  A crt can easily go to 1280 or
whatever, but LCD's can't.  So an emulator needs to come up with a solution
to that, anyway.

And sometimes, you just don't want an emulator taking up most of the screen.
A reduced window with a scaled or scrolled guest screen is simply handy.

Re: [Qemu-devel] scrollable window

[jeebs]

"Jim C. Brown"


>> Or the same size.  Don't forget, Windows XP will cover up part of the
>> window
>> even when the GTK version switches to 'full screen'.
>
> This is easily worked around by activiating the auto-hide feature of the
> taskbar.

Kludge.

You should *never* have to modify your host for a emulator and guest OS to
work right.


> Well, scaling is actually not so convient as it can make the graphics,
> especially
> characters in small font, too small to see clearly. Scaling to make the
> window
> larger than the guest resolution might be useful though.

True.

Depends on how much you scale, though.  Dropping a 1024 guest down to 800 or
so would still be mostly usable.

I was also thinking about doing it as a way to have a 'small' qemu window
showing what the guest is doing while you are doing something else.

Kind of a live action thumbnail view.  Except not that small.  Custom sizes 
would be nice, but they'd probably require too much scaling effort.  Simply 
being able to drop things down to 1/2, 1/4, 1/8th resolutions would probably 
be enough, and not too time consuming.  (Kind of like the old days when word 
processors used to "greek" the text so you could see what the overall page 
layout would look like.  It wasn't always easily readable, but you got the 
general idea of what it looked like.)

It'd also be useful for people who have fixed size monitors (ie: LCD 
monitors) and simply can't do larger sizes that an application might need. 
(Although for them, a more general purpose scaling amount might be more 
useful.)

Sure, it'd hurt performance!!  But it might be useful.  And certainly more
convenient than having to use scroll bars.

I have no idea how much work that'd need, though.


> Custom sizes wouldn't work too well, it seems a lot of graphics programs
> like to insist on standard modes (640x480, 800x600, etc).

A lot of windows laptops have odd size screens.  Some are a lot wider than
normal, etc.

Programs work okay with them.

But yes, I know what you mean.  A lot of programs, both free and commercial,
tend to expect certain screen sizes.  Often 1024 or larger.

I mentioned it because VMWare has the ability to do that.

Re: [Qemu-devel] scrollable window

[Herbert Poetzl]

On Sun, Jul 10, 2005 at 01:57:57PM -0400, Jim C. Brown wrote:
> On Sun, Jul 10, 2005 at 07:32:01PM +0200, Herbert Poetzl wrote:
> > > Some, such as myself, still use 800x600.  I do it out of necessity.  I have 
> > > poor eyesight and don't have the spare cash (or desk space!) for a 21 inch 
> > > monitor.  And LCD monitors tend to have too high a native resolution.  With 
> > > my current 17" monitor, I simply can't handle anything beyond 800x600.
> > 
> > why not use a virtual desktop of larger size and 
> > pan the mouse to the current 'view' which can be 800x600
> > or even less if your bad eyesight requires that ...
> > (on X you can change that with CTRL-ALT-+/- and the
> > mouse will be handled properly, including pan ranges)
> > 
> > best,
> > Herbert
> 
> That works too. So Herbert, tell us how does one set up a virtual screen
> a la X Server style when one is using Windows? Presumably there is some
> "powertoy" out there which does this, but I don't know of any myself.

well, cygwin supports X, which probably gives you
all that and more ...  

actually, never bothered with windows ...

there are a bunch of good solutions for MacOS X too
(like Virtue or DesktopManager)

> -- 
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] scrollable window

[Jim C. Brown]

On Sun, Jul 10, 2005 at 08:37:18PM +0200, Herbert Poetzl wrote:
> > That works too. So Herbert, tell us how does one set up a virtual screen
> > a la X Server style when one is using Windows? Presumably there is some
> > "powertoy" out there which does this, but I don't know of any myself.
> 
> well, cygwin supports X, which probably gives you
> all that and more ...  
> 

I was not aware that cygwin supported a virtual screen. It certainly doesn't
do that in multiwindow mode (the most popular cygwin/x mode).

> actually, never bothered with windows ...
> 

I believe he was asking with regards to Windows, as well as in general. So,
not greatly helpful.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] scrollable window

[Jernej Simonèiè]

On Sunday, July 10, 2005, 19:57:57, Jim C. Brown wrote:

> That works too. So Herbert, tell us how does one set up a virtual screen
> a la X Server style when one is using Windows? Presumably there is some
> "powertoy" out there which does this, but I don't know of any myself.

Windows 9x (and presumably ME) allowed you to do this with certain drivers,
but AFAIK this isn't supported on 2000 and newer (I'm not certain about
NT4). You'd get 2 scrollbars in the Display properties Control Panel
applet, one for physical resolution and another for virtual.

-- 
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

Toothache tends to start on Saturday night.
       -- Laird's Law

Re: [Qemu-devel] scrollable window

[Jim C. Brown]

On Sun, Jul 10, 2005 at 01:21:23PM -0500, jeebs@yango.us wrote:
> "Jim C. Brown"
> 
> 
> >> Or the same size.  Don't forget, Windows XP will cover up part of the
> >> window
> >> even when the GTK version switches to 'full screen'.
> >
> > This is easily worked around by activiating the auto-hide feature of the
> > taskbar.
> 
> Kludge.
> 

Is not. At least, is not if someone can figure out how to get qemu to turn
autohide on by itself, and restore the state when it quites. If the user has
to do this manually each time, it could get annoying.

> You should *never* have to modify your host for a emulator and guest OS to
> work right.
> 

The user or the program? If you mean the user, I agree ... but if you mean
qemu, then I don't. qemu itself has to modify the host environment in order
to create the illusion. For example, qemu changes video modes when running in
X11.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] scrollable window

[Herbert Poetzl]

On Sun, Jul 10, 2005 at 02:53:23PM -0400, Jim C. Brown wrote:
> On Sun, Jul 10, 2005 at 08:37:18PM +0200, Herbert Poetzl wrote:
> > > That works too. So Herbert, tell us how does one set up a virtual screen
> > > a la X Server style when one is using Windows? Presumably there is some
> > > "powertoy" out there which does this, but I don't know of any myself.
> > 
> > well, cygwin supports X, which probably gives you
> > all that and more ...  
> > 
> 
> I was not aware that cygwin supported a virtual screen. It certainly doesn't
> do that in multiwindow mode (the most popular cygwin/x mode).
> 
> > actually, never bothered with windows ...
> 
> I believe he was asking with regards to Windows, as well as in general. So,
> not greatly helpful.

well, I just _assumed_ that the 'almighty' windows
supports something similar (as it really isn't a new
feature) and I don't think that reinventing the panning
inside a qemu gui would be the way to go ...

OTOH, open office did reinvent the workspace too, and
I guess that was inspired by the MS pendant ... so
maybe that's the 'windows' way to handle this after
all ...

best,
Herbert

> -- 
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.

Re: [Qemu-devel] scrollable window

[John R. Hogerhuis]

VmWare seems to let you do it any way you want. Full screen, scroll it
manually or auto scroll, etc. So clearly it can be done. Maybe the code
in something like VNC client would give some ideas.

Scaling an image *down* to fit in window of a given size seems totally
pointless other than to give a thumbnails of multiple vm's for
navigation between VMs. For that matter I can't imagine trying to work
with a machine w/in a machine at 800x600 for the host. Better to go to a
higher resolution and then you could consider scaling a vm display *up*
to some given size. Just increase your font size on the host. There's no
such thing as too high a resolution, just fonts that are too small
and/or broken applications or windowing systems that don't let you
adjust the font size.

As far as multiple desktops for Windows XP, these are bolted on third
party stuff... it won't work right till MS releases it... maybe they are
adding it to Longhorn?

-- John.

Re: [Qemu-devel] scrollable window

[Jim C. Brown]

On Sun, Jul 10, 2005 at 02:06:53PM -0700, John R. Hogerhuis wrote:
> VmWare seems to let you do it any way you want. Full screen, scroll it
> manually or auto scroll, etc. So clearly it can be done. Maybe the code
> in something like VNC client would give some ideas.
> 

Scrolling manually works, just a few kinks to iron out.

Fullscreen support is currently broken, but it is fixable. Just haven't gotten
around to it yet.

Autoscrolling is harder. VMware uses guest drivers, and using a custom guest
mosue driver would certainly help. This is doable if the guest OS does not do
mouse acceleration (because then the host and guest pointers dont get out of
sync - if the host pointer is at the edge of the window, the guest must be as
well). This option is a bit of work though...

> Scaling an image *down* to fit in window of a given size seems totally
> pointless other than to give a thumbnails of multiple vm's for
> navigation between VMs. For that matter I can't imagine trying to work
> with a machine w/in a machine at 800x600 for the host. Better to go to a
> higher resolution and then you could consider scaling a vm display *up*
> to some given size. Just increase your font size on the host. There's no
> such thing as too high a resolution, just fonts that are too small
> and/or broken applications or windowing systems that don't let you
> adjust the font size.
> 

Scaling an image up on the other hand, may be quite useful. I am not sure how
to do either (up or down) but if scaling up is possible, it seems only natural
to add the ability to scale down (even if its not recommended due to hard to
see fonts and etc).

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.