Thank you for checking. I guess that was time consuming. Then, wouldn't a-right-clicking-gives-the-black-border be an expected behavior?
By that particular operation, you induced the selection mechanism of Vim. But there was nothing to select at that time and hence Vim didn't know what to do but only knew it had to update the window to show a (hypothetically) selected region. I think that's why the border was left undefined (thus painted black) and the rest of the area which was supposed to draw text with a selected region highlighted was drawn in white. So, I'm afraid it would break the selection mechanism if the window was cleared every such an invalid operation was done. Wouldn't it be better to leave it as it is? I'm wondering if it is a substantial problem which prevents the users from using Vim? Best, Kazunobu 2016-02-20 17:49 GMT+09:00 Marius Gedminas <[email protected]>: > On Fri, Feb 19, 2016 at 11:11:45PM +0900, Kazunobu Kuriyama wrote: > > 2016-02-19 22:37 GMT+09:00 Marius Gedminas <[email protected]>: > > > > > I use Adwaita, which is the default GNOME 3 theme (and I think also the > > > default GTK+ 3 theme). > > > > Hmm. Then the theme has nothing to do with the border draw. And Vim > > contains no code for drawing border or specifying the drawing area offset > > to the parent GtkForm. > > > Do you use other applications which use GtkDrawingArea and draw the > border? > > I've no idea. :-) > > I suspect this is something similar to > https://bugzilla.gnome.org/show_bug.cgi?id=733027: the widget doesn't > draw the background explicitly, so you end up with something undefined. > I'm afraid it's not the case applicable to the issue. > > > > The usual keys (Ctrl+Shift+I/Ctrl+Shift+D) do not open the GTK+ > > > inspector in gvim. > > > > > > Curiously: if I run 'GTK_DEBUG=interactive gvim' and then right-click, > > > the border does not turn black. > > > > Did you mean the GTK+ of your system was somehow unstable, or gvim didn't > > behave like other GTK+ apps? > > Are you familiar with the GTK+ inspector? There's a setting that > enables hot keys for it: https://wiki.gnome.org/Projects/GTK%2B/Inspector > I've that setting enabled. Usually this means Ctrl+Shift+I or > Ctrl+Shift+D in any GTK+ app will invoke the inspector, but individual > apps can override these key bindings. E.g. Nautilus uses Ctrl+Shift+I > to invert the selection, so only Ctrl+Shift+D works to toggle the > Inspector window. > I know :) I'm the one who wrote the code, and as I said, I cannot reproduce the issue with my system. Naturally, the inspector wouldn't help me more than examining the code. Anyway, you've done with the inspector this time, right? I thought from what you wrote that something bad happened and the inspector wasn't usable for you, and was worried about that. > > What I'm saying is that Vim takes over both shortcuts so the only way to > get to the GTK+ inspector is to use the GTK_DEBUG environment variable. > > This is not a problem, just an observation. > > About the "does not turn black on right-click" thing -- I found that if > I go to the Style tab in the Inspector and switch themes, the border > becomes black: http://imgur.com/M0MhBQl > > > > Anyway, I've now realized that the GTK+ inspector apparently doesn't > > > show the CSS rules that come from the theme, and I'm not quite sure > > > where to check what. > > > > OK, you mean you are using GTK+ with the default settings and haven't > done > > anything with files in $HOME/.config/gtk-3.0, right? > > Right: > > mg@platonas: ~ $ cat ~/.config/gtk-3.0/settings.ini > [Settings] > gtk-application-prefer-dark-theme=0 > > > To make sure, could you try the following program and check how it > responds > > against a right click on the drawing area window? > > > > /* > > * main.c - drawing area test program > > * > > * To compile: gcc `pkg-config --cflags --libs gtk+-3.0` main.c > > This fails with link errors due to Debian/Ubuntu default linker flags > (--as-needed): > https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed > > I can compile with > > gcc main.c `pkg-config --cflags --libs gtk+-3.0` > > > */ > > > > #include <gtk/gtk.h> > > > > int main(int argc, char *argv[]) > > { > > GtkWidget *window; > > GtkWidget *da; > > gtk_init(&argc, &argv); > > window = gtk_window_new(GTK_WINDOW_TOPLEVEL); > > g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL); > > da = gtk_drawing_area_new(); > > gtk_container_add(GTK_CONTAINER(window), da); > > gtk_widget_show_all(window); > > gtk_main(); > > return 0; > > } > > No strange color-changing borders appear with this example. > > I've played a bit more with the GTK+ inspector. The border that changes > the color comes from the GdkDrawingArea: http://imgur.com/a/zgDJY > > It's exactly 2 pixels wide: http://imgur.com/qWauoUd > > Marius Gedminas > -- > My mail reader can beat up your mail reader. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
