Upstream bugs

Upstream bugs

This page documents upstream bugs.

Gtk3

cairo_surface_t

An offscreen buffer is allocated and zeroed for each repaint, resulting in a huge performance impact. dqh provided a patch, which sadly did not get accepted :(

see https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1441

GtkComboBox

Some combobox contents appear to have 'empty' entries and sometimes the colors of the items change (upstream Gtk3 bug) (2017-11-08)

GtkFileChooser

The GtkFileChooser-based dialogs (open/save file etc) sort the drives on Windows in reverse-order. There is no public API or any GSetting that allows controlling this. The Gtk3 devs say they won't implement changing the sort order, but agreed the order should follow what Windows does. See ticket https://gitlab.gnome.org/GNOME/gtk/issues/900. This also happens on Linux: mountable file systems (such as Windows partitions) are list in reverse order by /sda/* and then by volume name, in reverse order.

(This appears to be fixed in Gtk 3.24.x, but FrankenVICE (nightly build system) still uses Gtk 3.22.x, so we need to update FrankenVICE)

Another issue is case-insensitive sorting of dir/filenames (seems to be default on Windows), no support for this in Gtk3.

(Appears to be fixed in Gtk 3.24.x as well)

Gtk3 Fullscreen

When using full screen (Alt+D) on Windows and using the openGL renderer and enabling the main menu bar and the statusbar (Atl+B), menus aren't shown (this includes popup menus triggered via the statusbar), they appear to be hidden behind the openGL canvas (guessing where a menu item is and clicking on it seems to work). According to the Gtk3 devs, this is a known bug, see https://gitlab.gnome.org/GNOME/gtk/issues/1702, so not much we can do about it until a fix lands in upstream GDK.

Going fullscreen and activating the (VTE) monitor does not present the monitor window on top of the emulated machine window. Alt-Tabbing away and back to VICE makes it work on Windows. It works as expected on at least KDE Plasma (KWin) and Gnome 3 (Mutter), so this seems to be a Windows problem. Someone with some actual understanding of the Windows window manager should have a look. An someone should also try this on MacOS, see what happens there.

GDK keyboard handling

related bug: #1200

On Windows GDK doesn't return `KP_Home` when pressing the numpad Home/7 button, but returns a plain `Home` keysym, which results in keymaps for the PET and other machines using a numpad, or similar, not working properly on Windows. This happens for all 'navigation' keys on a keypad.

• 2020-03-17, Compyx: I've asked on IRC: got ignored, and posted on the Gnome discourse ([1]) about this: also no response yet.
• 2020-04-27, Compyx: Also posted a bug ([2]) on their tracker a few weeks ago: again, no response and the Gnome discourse thread auto-closed =)
• 2020-12-27, Compyx: It appears at least some work is being done to rewrite the Win32 keyboard handling: ([3])

tried to come up with a workaround by using other members of GdkEventKey - no dice. even "hardware_keycode" is the same for keypad home and regular home - which is plain wrong. Gpz (talk) 00:21, 12 May 2020 (CEST)

/*
 * 
 * compile command:
 * 
 * gcc keypress.c -o keypress  `pkg-config --libs --cflags gtk+-3.0`
 * 
 * on windows use -mconsole to see the output on console (using msys2)
 * 
 */

/*
keyval: ff7f keyname: Num_Lock
keyval: ffaf keyname: KP_Divide   
keyval: ffaa keyname: KP_Multiply 
keyval: ffad keyname: KP_Subtract 
keyval: ffab keyname: KP_Add      
keyval: ff8d keyname: KP_Enter    

the "white" keys on the numpad should produce different keycodes depending
on the "numlock" state: (also pressing shift together with one of the keys will
result in "the other" keycode)

numlock on:                             numlock off:

keyval: ffb0 keyname: KP_0              keyval: ff9e keyname: KP_Insert
keyval: ffb1 keyname: KP_1              keyval: ff9c keyname: KP_End
keyval: ffb2 keyname: KP_2              keyval: ff99 keyname: KP_Down
keyval: ffb3 keyname: KP_3              keyval: ff9b keyname: KP_Next
keyval: ffb4 keyname: KP_4              keyval: ff96 keyname: KP_Left
keyval: ffb5 keyname: KP_5              keyval: ff9d keyname: KP_Begin
keyval: ffb6 keyname: KP_6              keyval: ff98 keyname: KP_Right
keyval: ffb7 keyname: KP_7              keyval: ff95 keyname: KP_Home
keyval: ffb8 keyname: KP_8              keyval: ff97 keyname: KP_Up
keyval: ffb9 keyname: KP_9              keyval: ff9a keyname: KP_Page_Up
keyval: ffac keyname: KP_Separator      keyval: ff9f keyname: KP_Delete

on windows the keys with numlock off produce wrong keycodes, eg "Home" instead
of "KP_Home".

*/

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

gboolean on_key_press (GtkWidget *widget, GdkEventKey *event, gpointer user_data)
{
  printf("keyval: %04x keyname: %s\n", event->keyval, gdk_keyval_name(event->keyval));
  fflush(stdout);
  return FALSE; 
} 

int main (int argc, char *argv[])
{
  GtkWidget *window;

  gtk_init (&argc, &argv);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);

  g_signal_connect (G_OBJECT (window), "destroy", G_CALLBACK (gtk_main_quit), NULL);
  g_signal_connect (G_OBJECT (window), "key_press_event", G_CALLBACK (on_key_press), NULL);

  gtk_widget_show_all (window);

  gtk_main ();

  return 0;
}

SDL

SDL 1 has compatibility issues on various operating systems:

• Window resizing can be intermittent: the window will change its size, but the window-resize event will not be generated and the display will clip or be mislplaced.
• When OpenGL is disabled, most recent versions of macOS will simply display an empty window.

If you see strange misbehavior at the window-manager level in an SDL 1 build, test the SDL 2 build. SDL 2 is well supported on mainstream systems that are 10 or fewer years old, and it is the preferred SDL implementation of VICE under nearly all circumstances.