[patch] GtkFileChooser and gvim's odd use of gtk_main()

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[patch] GtkFileChooser and gvim's odd use of gtk_main()

Tim Starling-2
GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
1 every time an event is received, causing GTK to write to the disk
excessively.

gtk_main() has always stored the clipboard on the same trigger, so it's
fair to say that exiting gtk_main() constantly is not the way the GTK
developers expected an application to work. People who know stuff about
GTK agree:

http://mail.gnome.org/archives/gtk-list/2008-July/msg00131.html

My interest in this started when I discovered that GtkFileChooser had
been disabled. I missed it:

https://bugs.launchpad.net/ubuntu/+source/vim/+bug/365860

It's been 7 months now since that plaintive cry, so I gave up waiting
and wrote a patch. This is my first GTK project but it looks pretty
straightforward. I read the source code for gtk_main() and some other
things.

Emmanuele Bassi's advice was to create a separate GMainLoop:

http://mail.gnome.org/archives/gtk-list/2008-July/msg00146.html

That turns out to be unnecessary, since all GMainLoop does is calls
g_main_context_iteration() repeatedly, until it's time to exit. The
actual task of registering event sources and calling select() is done by
GMainContext, which exists whether or not a GMainLoop has been created.
Thus by calling g_main_context_iteration() at the relevant places, vim
can leave main_loop() unmodified.

My patch does this, and removes all calls to gtk_main_quit() except the
ones in modal dialogs. Modal dialogs are now implemented by calling
gtk_main() once only, and allowing the button handlers to call
gtk_main_quit(), just like in a regular GTK application.

We don't seem to be missing anything substantial by never calling
gtk_main(). You can register callbacks to be called when gtk_main()
exits, but luckily vim isn't doing that or else they'd be called on the
first keypress and then never again. Of course we miss out on that final
sync of recently-used.xbel, but it seems that it's already synced every
time it's changed, via the "changed" signal (see
gtk_recent_manager_changed() and its callers in gtk/gtkrecentmanager.c).

I haven't done cross-version tests on this patch, but
g_main_context_iteration() exists back to at least GLib 1.3.9 (September
2001).

Attached and online at:
http://tstarling.com/stuff/fix-gtk-main.patch

-- Tim Starling

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---


Index: src/gui_gtk.c
===================================================================
--- src/gui_gtk.c (revision 1658)
+++ src/gui_gtk.c (working copy)
@@ -596,10 +596,6 @@
     if (!gui.in_focus)
  gui_focus_change(TRUE);
 # endif
-
-    /* make sure the menu action is taken immediately */
-    if (gtk_main_level() > 0)
- gtk_main_quit();
 }
 
 # if defined(FEAT_TOOLBAR) && !defined(HAVE_GTK2)
@@ -1145,9 +1141,6 @@
     }
 
     gui_drag_scrollbar(sb, value, dragging);
-
-    if (gtk_main_level() > 0)
- gtk_main_quit();
 }
 
 /* SBAR_VERT or SBAR_HORIZ */
@@ -1194,10 +1187,7 @@
  * Implementation of the file selector related stuff
  */
 #if defined(HAVE_GTK2) && GTK_CHECK_VERSION(2,4,0)
-/* This has been disabled, because the GTK library rewrites
- * ~/.recently-used.xbel every time the main loop is quit.  For Vim that means
- * on just about any event. */
-/* # define USE_FILE_CHOOSER */
+# define USE_FILE_CHOOSER
 #endif
 
 #ifndef USE_FILE_CHOOSER
@@ -1212,8 +1202,6 @@
     vw->browse_fname = (char_u *)g_strdup(gtk_file_selection_get_filename(
  GTK_FILE_SELECTION(vw->filedlg)));
     gtk_widget_hide(vw->filedlg);
-    if (gtk_main_level() > 0)
- gtk_main_quit();
 }
 
     static void
@@ -1227,8 +1215,6 @@
  vw->browse_fname = NULL;
     }
     gtk_widget_hide(vw->filedlg);
-    if (gtk_main_level() > 0)
- gtk_main_quit();
 }
 
     static gboolean
@@ -1240,10 +1226,7 @@
  gui.browse_fname = NULL;
     }
     gui.filedlg = NULL;
-
-    if (gtk_main_level() > 0)
- gtk_main_quit();
-
+    gtk_main_quit();
     return FALSE;
 }
 #endif
@@ -1349,8 +1332,7 @@
 # endif
 
     gtk_widget_show(gui.filedlg);
-    while (gui.filedlg && GTK_WIDGET_DRAWABLE(gui.filedlg))
- gtk_main_iteration_do(TRUE);
+    gtk_main();
 #endif
 
 # ifdef HAVE_GTK2
@@ -1642,8 +1624,7 @@
 dlg_destroy_cb(int *p)
 {
     *p = TRUE; /* set dialog_destroyed to break out of the loop */
-    if (gtk_main_level() > 0)
- gtk_main_quit();
+    gtk_main_quit();
 }
 
     int
@@ -1942,12 +1923,8 @@
     GTK_WIDGET(dialog), VW_POS_MOUSE);
 
     gtk_widget_show(dialog);
+    gtk_main();
 
-    /* loop here until the dialog goes away */
-    while (dialog_status == -1 && !dialog_destroyed
-       && GTK_WIDGET_DRAWABLE(dialog))
- gtk_main_iteration_do(TRUE);
-
     if (dialog_status < 0)
  dialog_status = 0;
     if (dialog_status != 1 && textfield != NULL)
@@ -2990,9 +2967,6 @@
     CONVERT_FROM_UTF8_FREE(repl_text);
     CONVERT_FROM_UTF8_FREE(find_text);
 #endif
-
-    if (rc && gtk_main_level() > 0)
- gtk_main_quit(); /* make sure cmd will be handled immediately */
 }
 
 /* our usual callback function */
Index: src/gui_gtk_x11.c
===================================================================
--- src/gui_gtk_x11.c (revision 1658)
+++ src/gui_gtk_x11.c (working copy)
@@ -698,9 +698,6 @@
  xev.xproperty.window = commWindow;
  xev.xproperty.state = PropertyNewValue;
  serverEventProc(GDK_WINDOW_XDISPLAY(widget->window), &xev);
-
- if (gtk_main_level() > 0)
-    gtk_main_quit();
     }
     return FALSE;
 }
@@ -834,10 +831,6 @@
     if (widget != gui.drawarea)
  gtk_widget_grab_focus(gui.drawarea);
 
-    /* make sure the input buffer is read */
-    if (gtk_main_level() > 0)
- gtk_main_quit();
-
     return TRUE;
 }
 
@@ -851,10 +844,6 @@
     if (blink_state != BLINK_NONE)
  gui_mch_stop_blink();
 
-    /* make sure the input buffer is read */
-    if (gtk_main_level() > 0)
- gtk_main_quit();
-
     return TRUE;
 }
 
@@ -1235,9 +1224,6 @@
     if (p_mh)
  gui_mch_mousehide(TRUE);
 
-    if (gtk_main_level() > 0)
- gtk_main_quit();
-
     return TRUE;
 }
 
@@ -1271,9 +1257,6 @@
     else
  clip_lose_selection(&clip_star);
 
-    if (gtk_main_level() > 0)
- gtk_main_quit();
-
     return TRUE;
 }
 
@@ -1311,9 +1294,6 @@
  received_selection = RS_FAIL;
  /* clip_free_selection(cbd); ??? */
 
- if (gtk_main_level() > 0)
-    gtk_main_quit();
-
  return;
     }
 
@@ -1439,9 +1419,6 @@
 #ifdef HAVE_GTK2
     g_free(tmpbuf_utf8);
 #endif
-
-    if (gtk_main_level() > 0)
- gtk_main_quit();
 }
 
 /*
@@ -1722,9 +1699,6 @@
     /* inform the editor engine about the occurrence of this event */
     gui_send_mouse_event(button, x, y, FALSE, vim_modifiers);
 
-    if (gtk_main_level() > 0)
- gtk_main_quit();
-
     /*
      * Auto repeat timer handling.
      */
@@ -1913,8 +1887,6 @@
     vim_modifiers = modifiers_gdk2mouse(event->state);
 
     gui_send_mouse_event(button, x, y, repeated_click, vim_modifiers);
-    if (gtk_main_level() > 0)
- gtk_main_quit(); /* make sure the above will be handled immediately */
 
     return TRUE;
 }
@@ -1958,9 +1930,6 @@
     gui_send_mouse_event(button, (int)event->x, (int)event->y,
  FALSE, vim_modifiers);
 
-    if (gtk_main_level() > 0)
- gtk_main_quit(); /* make sure the above will be handled immediately */
-
     return TRUE;
 }
 #endif /* HAVE_GTK2 */
@@ -1989,8 +1958,6 @@
     vim_modifiers = modifiers_gdk2mouse(event->state);
 
     gui_send_mouse_event(MOUSE_RELEASE, x, y, FALSE, vim_modifiers);
-    if (gtk_main_level() > 0)
- gtk_main_quit(); /* make sure it will be handled immediately */
 
     return TRUE;
 }
@@ -2163,9 +2130,6 @@
  add_to_input_buf(dropkey, (int)sizeof(dropkey));
     else
  add_to_input_buf(dropkey + 3, (int)(sizeof(dropkey) - 3));
-
-    if (gtk_main_level() > 0)
- gtk_main_quit();
 }
 
 /*
@@ -3210,9 +3174,6 @@
 {
     /* Add the string cmd into input buffer */
     send_tabline_menu_event(clicked_page, (int)(long)user_data);
-
-    if (gtk_main_level() > 0)
- gtk_main_quit();
 }
 
     static void
@@ -3288,8 +3249,7 @@
     {
  /* Click after all tabs moves to next tab page.  When "x" is
  * small guess it's the left button. */
- if (send_tabline_event(x < 50 ? -1 : 0) && gtk_main_level() > 0)
-    gtk_main_quit();
+ send_tabline_event(x < 50 ? -1 : 0);
     }
 #ifndef HAVE_GTK2
     else
@@ -3315,8 +3275,7 @@
 {
     if (!ignore_tabline_evt)
     {
- if (send_tabline_event(idx + 1) && gtk_main_level() > 0)
-    gtk_main_quit();
+ send_tabline_event(idx + 1);
     }
 }
 
@@ -4301,9 +4260,6 @@
 {
     if (gui.mainwin != NULL)
  gtk_widget_destroy(gui.mainwin);
-
-    if (gtk_main_level() > 0)
- gtk_main_quit();
 }
 
 /*
@@ -4590,8 +4546,7 @@
 
     vw->fontname = (char_u *)gtk_font_selection_dialog_get_font_name(fs);
     gtk_widget_hide(vw->fontdlg);
-    if (gtk_main_level() > 0)
- gtk_main_quit();
+    gtk_main_quit();
 }
 
     static void
@@ -4600,8 +4555,7 @@
     gui_T *vw = (gui_T *)cbdata;
 
     gtk_widget_hide(vw->fontdlg);
-    if (gtk_main_level() > 0)
- gtk_main_quit();
+    gtk_main_quit();
 }
 
     static void
@@ -4610,8 +4564,7 @@
     gui_T *vw = (gui_T *)cbdata;
 
     vw->fontdlg = NULL;
-    if (gtk_main_level() > 0)
- gtk_main_quit();
+    gtk_main_quit();
 }
 #endif /* !HAVE_GTK2 */
 
@@ -4783,8 +4736,7 @@
     }
 
     /* Wait for the font dialog to be closed. */
-    while (gui.fontdlg && GTK_WIDGET_DRAWABLE(gui.fontdlg))
- gtk_main_iteration_do(TRUE);
+    gtk_main();
 
     if (gui.fontname != NULL)
     {
@@ -6485,8 +6437,8 @@
     void
 gui_mch_update(void)
 {
-    while (gtk_events_pending() && !vim_is_input_buf_full())
- gtk_main_iteration_do(FALSE);
+    while (g_main_context_pending(NULL) && !vim_is_input_buf_full())
+ g_main_context_iteration(NULL, TRUE);
 }
 
     static gint
@@ -6497,9 +6449,6 @@
     /* Just inform the caller about the occurrence of it */
     *timed_out = TRUE;
 
-    if (gtk_main_level() > 0)
- gtk_main_quit();
-
     return FALSE; /* don't happen again */
 }
 
@@ -6516,9 +6465,6 @@
     static char_u bytes[3] = {CSI, (int)KS_EXTRA, (int)KE_SNIFF};
 
     add_to_input_buf(bytes, 3);
-
-    if (gtk_main_level() > 0)
- gtk_main_quit();
 }
 #endif
 
@@ -6593,7 +6539,7 @@
  * situations, sort of race condition).
  */
  if (!input_available())
-    gtk_main();
+    g_main_context_iteration(NULL, TRUE);
 
  /* Got char, return immediately */
  if (input_available())
@@ -6789,7 +6735,7 @@
  * during the FocusGained event. */
  start = time(NULL);
  while (received_selection == RS_NONE && time(NULL) < start + 3)
-    gtk_main(); /* wait for selection_received_cb */
+    g_main_context_iteration(NULL, TRUE); /* wait for selection_received_cb */
 
  if (received_selection != RS_FAIL)
     return;
Reply | Threaded
Open this post in threaded view
|

Re: [patch] GtkFileChooser and gvim's odd use of gtk_main()

Bram Moolenaar


Tim Starling wrote:

> GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
> 1 every time an event is received, causing GTK to write to the disk
> excessively.
>
> gtk_main() has always stored the clipboard on the same trigger, so it's
> fair to say that exiting gtk_main() constantly is not the way the GTK
> developers expected an application to work. People who know stuff about
> GTK agree:
>
> http://mail.gnome.org/archives/gtk-list/2008-July/msg00131.html
>
> My interest in this started when I discovered that GtkFileChooser had
> been disabled. I missed it:
>
> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/365860
>
> It's been 7 months now since that plaintive cry, so I gave up waiting
> and wrote a patch. This is my first GTK project but it looks pretty
> straightforward. I read the source code for gtk_main() and some other
> things.
>
> Emmanuele Bassi's advice was to create a separate GMainLoop:
>
> http://mail.gnome.org/archives/gtk-list/2008-July/msg00146.html
>
> That turns out to be unnecessary, since all GMainLoop does is calls
> g_main_context_iteration() repeatedly, until it's time to exit. The
> actual task of registering event sources and calling select() is done by
> GMainContext, which exists whether or not a GMainLoop has been created.
> Thus by calling g_main_context_iteration() at the relevant places, vim
> can leave main_loop() unmodified.
>
> My patch does this, and removes all calls to gtk_main_quit() except the
> ones in modal dialogs. Modal dialogs are now implemented by calling
> gtk_main() once only, and allowing the button handlers to call
> gtk_main_quit(), just like in a regular GTK application.
>
> We don't seem to be missing anything substantial by never calling
> gtk_main(). You can register callbacks to be called when gtk_main()
> exits, but luckily vim isn't doing that or else they'd be called on the
> first keypress and then never again. Of course we miss out on that final
> sync of recently-used.xbel, but it seems that it's already synced every
> time it's changed, via the "changed" signal (see
> gtk_recent_manager_changed() and its callers in gtk/gtkrecentmanager.c).
>
> I haven't done cross-version tests on this patch, but
> g_main_context_iteration() exists back to at least GLib 1.3.9 (September
> 2001).
>
> Attached and online at:
> http://tstarling.com/stuff/fix-gtk-main.patch

I'm very glad to see someone is picking up a GTK problem.  Hardly any
work was done on GTK for a long time.

I would appreciate it if a few people try this out and report any
problems they notice.

--
I used to wonder about the meaning of life.  But I looked it
up in the dictionary under "L" and there it was - the meaning
of life.  It was less than I expected.              - Dogbert

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: [patch] GtkFileChooser and gvim's odd use of gtk_main()

James Vega-3
On Fri, Nov 13, 2009 at 10:39:29PM +0100, Bram Moolenaar wrote:

>
>
> Tim Starling wrote:
>
> > GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
> > 1 every time an event is received, causing GTK to write to the disk
> > excessively.
> >
> > gtk_main() has always stored the clipboard on the same trigger, so it's
> > fair to say that exiting gtk_main() constantly is not the way the GTK
> > developers expected an application to work. People who know stuff about
> > GTK agree:
> >
> > http://mail.gnome.org/archives/gtk-list/2008-July/msg00131.html
> >
> > My interest in this started when I discovered that GtkFileChooser had
> > been disabled. I missed it:
> >
> > https://bugs.launchpad.net/ubuntu/+source/vim/+bug/365860
> >
> > It's been 7 months now since that plaintive cry, so I gave up waiting
> > and wrote a patch. This is my first GTK project but it looks pretty
> > straightforward. I read the source code for gtk_main() and some other
> > things.
> >
> > Emmanuele Bassi's advice was to create a separate GMainLoop:
> >
> > http://mail.gnome.org/archives/gtk-list/2008-July/msg00146.html
> >
> > That turns out to be unnecessary, since all GMainLoop does is calls
> > g_main_context_iteration() repeatedly, until it's time to exit. The
> > actual task of registering event sources and calling select() is done by
> > GMainContext, which exists whether or not a GMainLoop has been created.
> > Thus by calling g_main_context_iteration() at the relevant places, vim
> > can leave main_loop() unmodified.
> >
> > My patch does this, and removes all calls to gtk_main_quit() except the
> > ones in modal dialogs. Modal dialogs are now implemented by calling
> > gtk_main() once only, and allowing the button handlers to call
> > gtk_main_quit(), just like in a regular GTK application.
> >
> > We don't seem to be missing anything substantial by never calling
> > gtk_main(). You can register callbacks to be called when gtk_main()
> > exits, but luckily vim isn't doing that or else they'd be called on the
> > first keypress and then never again. Of course we miss out on that final
> > sync of recently-used.xbel, but it seems that it's already synced every
> > time it's changed, via the "changed" signal (see
> > gtk_recent_manager_changed() and its callers in gtk/gtkrecentmanager.c).
> >
> > I haven't done cross-version tests on this patch, but
> > g_main_context_iteration() exists back to at least GLib 1.3.9 (September
> > 2001).
> >
> > Attached and online at:
> > http://tstarling.com/stuff/fix-gtk-main.patch
>
> I'm very glad to see someone is picking up a GTK problem.  Hardly any
> work was done on GTK for a long time.
>
> I would appreciate it if a few people try this out and report any
> problems they notice.
The bug Tim fixed was something I had been planning on taking a look at, so
I'll definitely try out the patch soon and report back.

Thanks for the patch, Tim!

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [patch] GtkFileChooser and gvim's odd use of gtk_main()

James Vega-3

On Fri, Nov 13, 2009 at 6:08 PM, James Vega <[hidden email]> wrote:

> On Fri, Nov 13, 2009 at 10:39:29PM +0100, Bram Moolenaar wrote:
>> Tim Starling wrote:
>> > Thus by calling g_main_context_iteration() at the relevant places, vim
>> > can leave main_loop() unmodified.
>> >
>> > My patch does this, and removes all calls to gtk_main_quit() except the
>> > ones in modal dialogs. Modal dialogs are now implemented by calling
>> > gtk_main() once only, and allowing the button handlers to call
>> > gtk_main_quit(), just like in a regular GTK application.
>> > [...]
>> > Of course we miss out on that final
>> > sync of recently-used.xbel, but it seems that it's already synced every
>> > time it's changed, via the "changed" signal (see
>> > gtk_recent_manager_changed() and its callers in gtk/gtkrecentmanager.c).
>>
>> I'm very glad to see someone is picking up a GTK problem.  Hardly any
>> work was done on GTK for a long time.
>>
>> I would appreciate it if a few people try this out and report any
>> problems they notice.
>
> The bug Tim fixed was something I had been planning on taking a look at, so
> I'll definitely try out the patch soon and report back.

I've given it a shot and it's working well for me.  One thing I did
notice is that the files Vim edits aren't added to Gtk's recently used
list.  Based on the patch, this doesn't look like it's a regression in
behavior from the last time Vim was using GtkFileChooser.

I think it'd be good to get the patch as is included so Vim is no longer
using a deprecated (and as of Gtk3 removed) widget.  Also,
GtkFileChooser is more intuitive to use than GtkFileSelection (where
it's non-obvious how to select hidden files).

It would be interesting to look into how (and whether) Vim should make
use of Gtk's recently used list, especially since not all of Vim's
buffers directly relate to an actual file.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: [patch] GtkFileChooser and gvim's odd use of gtk_main()

Tim Starling-2
James Vega wrote:

> I've given it a shot and it's working well for me.  One thing I did
> notice is that the files Vim edits aren't added to Gtk's recently used
> list.  Based on the patch, this doesn't look like it's a regression in
> behavior from the last time Vim was using GtkFileChooser.
>
> I think it'd be good to get the patch as is included so Vim is no longer
> using a deprecated (and as of Gtk3 removed) widget.  Also,
> GtkFileChooser is more intuitive to use than GtkFileSelection (where
> it's non-obvious how to select hidden files).
>
> It would be interesting to look into how (and whether) Vim should make
> use of Gtk's recently used list, especially since not all of Vim's
> buffers directly relate to an actual file.
>
>  
I imagine it would be done in a manner along the lines of the attached
patch file. It was briefly tested.

I'm not a big fan of #ifdef so I added a function called
gui_mch_file_opened() which allows any GUI module to perform tasks on
file open. I put it near similar #ifdef-based notifications for Sun
Workshop and Netbeans.

My knowledge of the vim source is rudimentary. Some more callers might
have to be added, such as when saving a new file.

-- Tim Starling

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---


diff -ru vim7-svn/src/ex_cmds.c vim7-svn.p2/src/ex_cmds.c
--- vim7-svn/src/ex_cmds.c 2009-11-12 16:54:22.000000000 +1100
+++ vim7-svn.p2/src/ex_cmds.c 2009-11-17 18:23:18.000000000 +1100
@@ -3813,9 +3813,11 @@
     /* Change directories when the 'acd' option is set. */
     DO_AUTOCHDIR
 
-#if defined(FEAT_SUN_WORKSHOP) || defined(FEAT_NETBEANS_INTG)
+    /* Notify the GUI */
+# ifdef FEAT_GUI
     if (gui.in_use && curbuf->b_ffname != NULL)
     {
+ gui_mch_file_opened(curbuf);
 # ifdef FEAT_SUN_WORKSHOP
  if (usingSunWorkShop)
     workshop_file_opened((char *)curbuf->b_ffname, curbuf->b_p_ro);
diff -ru vim7-svn/src/gui_gtk_x11.c vim7-svn.p2/src/gui_gtk_x11.c
--- vim7-svn/src/gui_gtk_x11.c 2009-11-13 08:55:55.000000000 +1100
+++ vim7-svn.p2/src/gui_gtk_x11.c 2009-11-17 18:40:04.000000000 +1100
@@ -83,6 +83,7 @@
 # endif
 
 # include <gtk/gtk.h>
+# include <gio/gio.h>
 # include "gui_gtk_f.h"
 #endif
 
@@ -7262,3 +7263,19 @@
 # endif /* !HAVE_GTK2 */
 
 #endif /* FEAT_SIGN_ICONS */
+
+    void
+gui_mch_file_opened(buf_T *buf)
+{
+    /* Register the newly-opened file in GtkRecentManager */
+    GtkRecentManager *manager = gtk_recent_manager_get_default();
+    char *uri;
+    GFile *file;
+
+    file = g_file_new_for_path((const char*)buf->b_ffname);
+    uri = g_file_get_uri(file);
+    gtk_recent_manager_add_item(manager, (const gchar *)uri);
+    g_free(uri);
+    g_object_unref(file);
+}
+
diff -ru vim7-svn/src/gui_mac.c vim7-svn.p2/src/gui_mac.c
--- vim7-svn/src/gui_mac.c 2009-04-26 10:01:45.000000000 +1000
+++ vim7-svn.p2/src/gui_mac.c 2009-11-17 18:23:58.000000000 +1100
@@ -6897,3 +6897,8 @@
 }
 
 #endif // FEAT_GUI_TABLINE
+
+    void
+gui_mch_file_opened(buf_T *buf)
+{
+}
diff -ru vim7-svn/src/gui_photon.c vim7-svn.p2/src/gui_photon.c
--- vim7-svn/src/gui_photon.c 2009-11-12 16:54:22.000000000 +1100
+++ vim7-svn.p2/src/gui_photon.c 2009-11-17 18:25:19.000000000 +1100
@@ -3096,3 +3096,8 @@
     vim_free( font );
 }
 
+    void
+gui_mch_file_opened(buf_T *buf)
+{
+}
+
diff -ru vim7-svn/src/gui_riscos.c vim7-svn.p2/src/gui_riscos.c
--- vim7-svn/src/gui_riscos.c 2009-04-26 10:01:45.000000000 +1000
+++ vim7-svn.p2/src/gui_riscos.c 2009-11-17 18:26:29.000000000 +1100
@@ -3556,3 +3556,8 @@
     }
     return NULL;
 }
+
+    void
+gui_mch_file_opened(buf_T *buf)
+{
+}
diff -ru vim7-svn/src/gui_w16.c vim7-svn.p2/src/gui_w16.c
--- vim7-svn/src/gui_w16.c 2009-04-26 10:01:45.000000000 +1000
+++ vim7-svn.p2/src/gui_w16.c 2009-11-17 18:27:12.000000000 +1100
@@ -1554,3 +1554,4 @@
     SetActiveWindow(s_hwnd);
 }
 #endif
+
diff -ru vim7-svn/src/gui_w48.c vim7-svn.p2/src/gui_w48.c
--- vim7-svn/src/gui_w48.c 2009-04-26 10:01:45.000000000 +1000
+++ vim7-svn.p2/src/gui_w48.c 2009-11-17 18:27:36.000000000 +1100
@@ -3907,3 +3907,9 @@
     *argvp = argv;
     return argc;
 }
+
+    void
+gui_mch_file_opened(buf_T *buf)
+{
+}
+
diff -ru vim7-svn/src/gui_x11.c vim7-svn.p2/src/gui_x11.c
--- vim7-svn/src/gui_x11.c 2009-11-12 16:54:22.000000000 +1100
+++ vim7-svn.p2/src/gui_x11.c 2009-11-17 18:28:26.000000000 +1100
@@ -3585,3 +3585,8 @@
     }
 }
 #endif
+
+    void
+gui_mch_file_opened(buf_T *buf)
+{
+}
diff -ru vim7-svn/src/proto/gui_gtk_x11.pro vim7-svn.p2/src/proto/gui_gtk_x11.pro
--- vim7-svn/src/proto/gui_gtk_x11.pro 2009-11-12 16:54:14.000000000 +1100
+++ vim7-svn.p2/src/proto/gui_gtk_x11.pro 2009-11-17 18:45:33.000000000 +1100
@@ -72,4 +72,5 @@
 void gui_mch_drawsign __ARGS((int row, int col, int typenr));
 void *gui_mch_register_sign __ARGS((char_u *signfile));
 void gui_mch_destroy_sign __ARGS((void *sign));
+void gui_mch_file_opened __ARGS((buf_T *buf));
 /* vim: set ft=c : */
diff -ru vim7-svn/src/proto/gui_mac.pro vim7-svn.p2/src/proto/gui_mac.pro
--- vim7-svn/src/proto/gui_mac.pro 2009-04-26 10:01:34.000000000 +1000
+++ vim7-svn.p2/src/proto/gui_mac.pro 2009-11-17 19:08:01.000000000 +1100
@@ -143,5 +143,6 @@
 int C2PascalString (char_u *CString, Str255 *PascalString);
 int GetFSSpecFromPath ( char_u *file, FSSpec *fileFSSpec);
 char_u *FullPathFromFSSpec_save (FSSpec file);
+void gui_mch_file_opened __ARGS((buf_T *buf));
 
 /* vim: set ft=c : */
diff -ru vim7-svn/src/proto/gui_photon.pro vim7-svn.p2/src/proto/gui_photon.pro
--- vim7-svn/src/proto/gui_photon.pro 2009-04-26 10:01:34.000000000 +1000
+++ vim7-svn.p2/src/proto/gui_photon.pro 2009-11-17 18:45:35.000000000 +1100
@@ -64,4 +64,5 @@
 char_u *gui_mch_get_fontname __ARGS((GuiFont font, char_u *name));
 void gui_mch_set_font __ARGS((GuiFont font));
 void gui_mch_free_font __ARGS((GuiFont font));
+void gui_mch_file_opened __ARGS((buf_T *buf));
 /* vim: set ft=c : */
diff -ru vim7-svn/src/proto/gui_riscos.pro vim7-svn.p2/src/proto/gui_riscos.pro
--- vim7-svn/src/proto/gui_riscos.pro 2009-04-26 10:01:34.000000000 +1000
+++ vim7-svn.p2/src/proto/gui_riscos.pro 2009-11-17 19:06:42.000000000 +1100
@@ -63,4 +63,5 @@
 
 void ro_redraw_title __ARGS((int window));
 int ro_ok_to_quit __ARGS((void));
+void gui_mch_file_opened __ARGS((buf_T *buf));
 /* vim: set ft=c : */
diff -ru vim7-svn/src/proto/gui_w16.pro vim7-svn.p2/src/proto/gui_w16.pro
--- vim7-svn/src/proto/gui_w16.pro 2009-04-26 10:01:34.000000000 +1000
+++ vim7-svn.p2/src/proto/gui_w16.pro 2009-11-17 18:45:34.000000000 +1100
@@ -57,6 +57,7 @@
 char_u *gui_mch_browsedir __ARGS((char_u *title, char_u *initdir));
 char_u *gui_mch_browse __ARGS((int saving, char_u *title, char_u *dflt, char_u *ext, char_u *initdir, char_u *filter));
 int get_cmd_args __ARGS((char *prog, char *cmdline, char ***argvp, char **tofree));
+void gui_mch_file_opened __ARGS((buf_T *buf));
 void gui_mch_prepare __ARGS((int *argc, char **argv));
 int gui_mch_init __ARGS((void));
 void gui_mch_set_shellsize __ARGS((int width, int height, int min_width, int min_height, int base_width, int base_height, int direction));
diff -ru vim7-svn/src/proto/gui_w32.pro vim7-svn.p2/src/proto/gui_w32.pro
--- vim7-svn/src/proto/gui_w32.pro 2009-04-26 10:01:34.000000000 +1000
+++ vim7-svn.p2/src/proto/gui_w32.pro 2009-11-17 18:45:34.000000000 +1100
@@ -57,6 +57,7 @@
 char_u *gui_mch_browsedir __ARGS((char_u *title, char_u *initdir));
 char_u *gui_mch_browse __ARGS((int saving, char_u *title, char_u *dflt, char_u *ext, char_u *initdir, char_u *filter));
 int get_cmd_args __ARGS((char *prog, char *cmdline, char ***argvp, char **tofree));
+void gui_mch_file_opened __ARGS((buf_T *buf));
 int gui_is_win32s __ARGS((void));
 void gui_mch_set_parent __ARGS((char *title));
 void gui_mch_prepare __ARGS((int *argc, char **argv));
diff -ru vim7-svn/src/proto/gui_x11.pro vim7-svn.p2/src/proto/gui_x11.pro
--- vim7-svn/src/proto/gui_x11.pro 2009-04-26 10:01:34.000000000 +1000
+++ vim7-svn.p2/src/proto/gui_x11.pro 2009-11-17 18:45:33.000000000 +1100
@@ -67,4 +67,5 @@
 void gui_mch_mousehide __ARGS((int hide));
 void mch_set_mouse_shape __ARGS((int shape));
 void gui_mch_menu_set_tip __ARGS((vimmenu_T *menu));
+void gui_mch_file_opened __ARGS((buf_T *buf));
 /* vim: set ft=c : */
Reply | Threaded
Open this post in threaded view
|

Re: [patch] GtkFileChooser and gvim's odd use of gtk_main()

Bram Moolenaar


Tim Starling wrote:

> James Vega wrote:
> > I've given it a shot and it's working well for me.  One thing I did
> > notice is that the files Vim edits aren't added to Gtk's recently used
> > list.  Based on the patch, this doesn't look like it's a regression in
> > behavior from the last time Vim was using GtkFileChooser.
> >
> > I think it'd be good to get the patch as is included so Vim is no longer
> > using a deprecated (and as of Gtk3 removed) widget.  Also,
> > GtkFileChooser is more intuitive to use than GtkFileSelection (where
> > it's non-obvious how to select hidden files).
> >
> > It would be interesting to look into how (and whether) Vim should make
> > use of Gtk's recently used list, especially since not all of Vim's
> > buffers directly relate to an actual file.
>
> I imagine it would be done in a manner along the lines of the attached
> patch file. It was briefly tested.
>
> I'm not a big fan of #ifdef so I added a function called
> gui_mch_file_opened() which allows any GUI module to perform tasks on
> file open. I put it near similar #ifdef-based notifications for Sun
> Workshop and Netbeans.
>
> My knowledge of the vim source is rudimentary. Some more callers might
> have to be added, such as when saving a new file.

It looks like this will also add files when using a command like
":grep" and Vim scripts looking through files.  It's probably better to
only do this when the user typed the edit command.

        # include <gio/gio.h>
Since when was this file available?  Might need a configure check.


--
BLACK KNIGHT: None shall pass.
ARTHUR:       I have no quarrel with you, brave Sir knight, but I must cross
              this bridge.
BLACK KNIGHT: Then you shall die.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: [patch] GtkFileChooser and gvim's odd use of gtk_main()

James Vega-3
In reply to this post by Bram Moolenaar
On Fri, Nov 13, 2009 at 5:39 PM, Bram Moolenaar <[hidden email]> wrote:

> Tim Starling wrote:
>> GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
>> 1 every time an event is received, causing GTK to write to the disk
>> excessively.
>>
>> [snip]
>>
>> That turns out to be unnecessary, since all GMainLoop does is calls
>> g_main_context_iteration() repeatedly, until it's time to exit. The
>> actual task of registering event sources and calling select() is done by
>> GMainContext, which exists whether or not a GMainLoop has been created.
>> Thus by calling g_main_context_iteration() at the relevant places, vim
>> can leave main_loop() unmodified.
>>
>> My patch does this, and removes all calls to gtk_main_quit() except the
>> ones in modal dialogs. Modal dialogs are now implemented by calling
>> gtk_main() once only, and allowing the button handlers to call
>> gtk_main_quit(), just like in a regular GTK application.
>> [snip]
>
> I'm very glad to see someone is picking up a GTK problem.  Hardly any
> work was done on GTK for a long time.
>
> I would appreciate it if a few people try this out and report any
> problems they notice.
Given the recent removal of GTK 1 support, attached is an updated patch.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

--
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

fix-gtk-main.patch (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [patch] GtkFileChooser and gvim's odd use of gtk_main()

SungHyun Nam-2
James Vega wrote:

> On Fri, Nov 13, 2009 at 5:39 PM, Bram Moolenaar<[hidden email]>  wrote:
>> Tim Starling wrote:
>>> GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
>>> 1 every time an event is received, causing GTK to write to the disk
>>> excessively.
>>>
>>> [snip]
>>>
>>> That turns out to be unnecessary, since all GMainLoop does is calls
>>> g_main_context_iteration() repeatedly, until it's time to exit. The
>>> actual task of registering event sources and calling select() is done by
>>> GMainContext, which exists whether or not a GMainLoop has been created.
>>> Thus by calling g_main_context_iteration() at the relevant places, vim
>>> can leave main_loop() unmodified.
>>>
>>> My patch does this, and removes all calls to gtk_main_quit() except the
>>> ones in modal dialogs. Modal dialogs are now implemented by calling
>>> gtk_main() once only, and allowing the button handlers to call
>>> gtk_main_quit(), just like in a regular GTK application.
>>> [snip]
>>
>> I'm very glad to see someone is picking up a GTK problem.  Hardly any
>> work was done on GTK for a long time.
>>
>> I would appreciate it if a few people try this out and report any
>> problems they notice.
>
> Given the recent removal of GTK 1 support, attached is an updated patch.

Though I never use the file open dialog, I just tried the patch.
On the Ubuntu 9.04, file chooser worked fine.

But, on the cygwin, a problem occurs.
Without the patch, there's no problem to open file open dialog.

     $ uname -a
     CYGWIN_NT-5.1 namsh 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

If I run 'vim -f -g' (foreground), file chooser worked fine.
If I run 'vim -g'  (background), VIM died with SIGSEGV.

I run vim as below to get backtrace:
     $ LANG= ./vim.exe -g -u NONE -U NONE --noplugin

$ gdb ./vim.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) attach 4036
Attaching to program `/s/vim-unix/src/vim.exe', process 4036
...
... [snip...]
...
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 4036.0xa50]
0x76ba1ef4 in ?? ()
(gdb) bt
#0  0x76ba1ef4 in ?? ()
#1  0x6ff41755 in g_module_symbol () from /usr/bin/cyggmodule-2.0-0.dll
#2  0x6ff41db3 in g_module_open () from /usr/bin/cyggmodule-2.0-0.dll
#3  0x681675a5 in g_io_modules_load_all_in_directory ()
    from /usr/bin/cyggio-2.0-0.dll
#4  0x6e5a3526 in g_type_module_use () from /usr/bin/cyggobject-2.0-0.dll
#5  0x68167348 in g_io_modules_load_all_in_directory ()
    from /usr/bin/cyggio-2.0-0.dll
#6  0x68167466 in g_io_modules_load_all_in_directory ()
    from /usr/bin/cyggio-2.0-0.dll
#7  0x6817dffb in g_vfs_is_active () from /usr/bin/cyggio-2.0-0.dll
#8  0x6aa8b50e in g_once_impl () from /usr/bin/cygglib-2.0-0.dll
#9  0x6817dc5c in g_vfs_get_default () from /usr/bin/cyggio-2.0-0.dll
#10 0x6814e773 in g_file_new_for_path () from /usr/bin/cyggio-2.0-0.dll
#11 0x6af6030f in gtk_recent_manager_get_for_screen ()
    from /usr/bin/cyggtk-x11-2.0-0.dll
#12 0x6e588f36 in g_object_freeze_notify () from
/usr/bin/cyggobject-2.0-0.dll
#13 0x6e58a4a6 in g_object_newv () from /usr/bin/cyggobject-2.0-0.dll
#14 0x6e58a9ed in g_object_new_valist () from /usr/bin/cyggobject-2.0-0.dll
#15 0x6e58ab46 in g_object_new () from /usr/bin/cyggobject-2.0-0.dll
#16 0x6af5fddb in gtk_recent_manager_new () from
/usr/bin/cyggtk-x11-2.0-0.dll
#17 0x6af5fdfc in gtk_recent_manager_get_default ()
    from /usr/bin/cyggtk-x11-2.0-0.dll
#18 0x6aebbef9 in gtk_file_chooser_button_new ()
    from /usr/bin/cyggtk-x11-2.0-0.dll
#19 0x6e5a256a in g_type_create_instance () from
/usr/bin/cyggobject-2.0-0.dll
#20 0x6e588e2a in g_object_freeze_notify () from
/usr/bin/cyggobject-2.0-0.dll
#21 0x6aebe945 in gtk_file_chooser_button_new ()
    from /usr/bin/cyggtk-x11-2.0-0.dll
#22 0x6e58a4a6 in g_object_newv () from /usr/bin/cyggobject-2.0-0.dll
#23 0x6e58a9ed in g_object_new_valist () from /usr/bin/cyggobject-2.0-0.dll
#24 0x6e58ab46 in g_object_new () from /usr/bin/cyggobject-2.0-0.dll
#25 0x6aeaf11b in gtk_file_chooser_button_new ()
    from /usr/bin/cyggtk-x11-2.0-0.dll
#26 0x6aec4513 in gtk_file_chooser_widget_new ()
    from /usr/bin/cyggtk-x11-2.0-0.dll
#27 0x6e58a4a6 in g_object_newv () from /usr/bin/cyggobject-2.0-0.dll
#28 0x6e58a9ed in g_object_new_valist () from /usr/bin/cyggobject-2.0-0.dll
---Type <return> to continue, or q <return> to quit---
#29 0x6e58ab46 in g_object_new () from /usr/bin/cyggobject-2.0-0.dll
#30 0x6aec01e5 in gtk_file_chooser_dialog_new ()
    from /usr/bin/cyggtk-x11-2.0-0.dll
#31 0x6e58a4a6 in g_object_newv () from /usr/bin/cyggobject-2.0-0.dll
#32 0x6e58aa18 in g_object_new_valist () from /usr/bin/cyggobject-2.0-0.dll
#33 0x6e58ab46 in g_object_new () from /usr/bin/cyggobject-2.0-0.dll
#34 0x6aebfde0 in gtk_file_chooser_dialog_get_type ()
    from /usr/bin/cyggtk-x11-2.0-0.dll
#35 0x6aebfe89 in gtk_file_chooser_dialog_new ()
    from /usr/bin/cyggtk-x11-2.0-0.dll
#36 0x0054f73e in gui_mch_browse (saving=0, title=0x5785a5 "Edit File",
     dflt=0xf05030 "", ext=0x0, initdir=0x0,
     filter=0x584f5c "All Files (*)\t*\nC source (*.c,
*.h)\t*.c;*.h\nC++ source (*.cpp, *.hpp)\t*.cpp;*.hpp\nVim files (*.vim,
_vimrc, _gvimrc)\t*.vim;_vimrc;_gvimrc\n") at gui_gtk.c:859
#37 0x0049cdce in do_browse (flags=0, title=0x5785a5 "Edit File",
     dflt=0xf05030 "", ext=0x0, initdir=0x0,
     filter=0x584f5c "All Files (*)\t*\nC source (*.c,
*.h)\t*.c;*.h\nC++ source (*.cpp, *.hpp)\t*.cpp;*.hpp\nVim files (*.vim,
_vimrc, _gvimrc)\t*.vim;_vimrc;_gvimrc\n", buf=0xc6b150) at message.c:3804
#38 0x0043c745 in do_ecmd (fnum=0, ffname=0xf05030 "", sfname=0x0,
     eap=0x22c9e0, newlnum=1, flags=0, oldwin=0xc6a1c8) at ex_cmds.c:3177
#39 0x00455571 in do_exedit (eap=0x22c9e0, old_curwin=0x0) at
ex_docmd.c:7626
#40 0x00455f09 in ex_edit (eap=0x22c9e0) at ex_docmd.c:7522
#41 0x004526d9 in do_cmdline (cmdline=0x0, getline=0x461c10 <getexline>,
     cookie=0x0, flags=0) at ex_docmd.c:2640
#42 0x004c0cff in nv_colon (cap=0x22cb38) at normal.c:5245
#43 0x004c2758 in normal_cmd (oap=0x22cb9c, toplevel=1) at normal.c:1188
#44 0x0048441f in main_loop (cmdwin=0, noexmode=0) at main.c:1216
#45 0x0048719a in main (argc=2090061788, argv=0x612288b4) at main.c:960

--
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
Reply | Threaded
Open this post in threaded view
|

Re: [patch] GtkFileChooser and gvim's odd use of gtk_main()

James Vega-3
On Tue, Jun 29, 2010 at 1:36 AM, SungHyun Nam <[hidden email]> wrote:

> James Vega wrote:
>>
>> On Fri, Nov 13, 2009 at 5:39 PM, Bram Moolenaar<[hidden email]>
>>  wrote:
>>>
>>> Tim Starling wrote:
>>>>
>>>> GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
>>>> 1 every time an event is received, causing GTK to write to the disk
>>>> excessively.
>>>>
>>>> [snip]
>>>>
>>>> That turns out to be unnecessary, since all GMainLoop does is calls
>>>> g_main_context_iteration() repeatedly, until it's time to exit. The
>>>> actual task of registering event sources and calling select() is done by
>>>> GMainContext, which exists whether or not a GMainLoop has been created.
>>>> Thus by calling g_main_context_iteration() at the relevant places, vim
>>>> can leave main_loop() unmodified.
>>>>
>>>> My patch does this, and removes all calls to gtk_main_quit() except the
>>>> ones in modal dialogs. Modal dialogs are now implemented by calling
>>>> gtk_main() once only, and allowing the button handlers to call
>>>> gtk_main_quit(), just like in a regular GTK application.
>>>> [snip]
>>>
>>> I'm very glad to see someone is picking up a GTK problem.  Hardly any
>>> work was done on GTK for a long time.
>>>
>>> I would appreciate it if a few people try this out and report any
>>> problems they notice.
>>
>> Given the recent removal of GTK 1 support, attached is an updated patch.
>
> Though I never use the file open dialog, I just tried the patch.
> On the Ubuntu 9.04, file chooser worked fine.
>
> But, on the cygwin, a problem occurs.
> Without the patch, there's no problem to open file open dialog.
>
>    $ uname -a
>    CYGWIN_NT-5.1 namsh 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
>
> If I run 'vim -f -g' (foreground), file chooser worked fine.
> If I run 'vim -g'  (background), VIM died with SIGSEGV.

Thanks for trying the patch out!  I'd like to see this get included, so
it's good to see people giving it a shot.

As for the crash, this happens without the patch as well, if the Gtk2
file chooser is enabled.  This even happens in Vim 7.2 if the Gtk2 file
chooser is enabled, so I'm wondering if there isn't something else going
on here.  This reminded me of a bug[0] I had seen in RedHat's tracker a
while back which silently died, but may be relevant.

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=488652
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

--
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
Reply | Threaded
Open this post in threaded view
|

Re: [patch] GtkFileChooser and gvim's odd use of gtk_main()

James Vega-3
On Tue, Jun 29, 2010 at 12:43 PM, James Vega <[hidden email]> wrote:

> On Tue, Jun 29, 2010 at 1:36 AM, SungHyun Nam <[hidden email]> wrote:
>> James Vega wrote:
>>>
>>> On Fri, Nov 13, 2009 at 5:39 PM, Bram Moolenaar<[hidden email]>
>>>  wrote:
>>>>
>>>> Tim Starling wrote:
>>>>>
>>>>> GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
>>>>> 1 every time an event is received, causing GTK to write to the disk
>>>>> excessively.
>>>>>
>>>>> [snip]
>>>>>
>>>>> That turns out to be unnecessary, since all GMainLoop does is calls
>>>>> g_main_context_iteration() repeatedly, until it's time to exit. The
>>>>> actual task of registering event sources and calling select() is done by
>>>>> GMainContext, which exists whether or not a GMainLoop has been created.
>>>>> Thus by calling g_main_context_iteration() at the relevant places, vim
>>>>> can leave main_loop() unmodified.
>>>>>
>>>>> My patch does this, and removes all calls to gtk_main_quit() except the
>>>>> ones in modal dialogs. Modal dialogs are now implemented by calling
>>>>> gtk_main() once only, and allowing the button handlers to call
>>>>> gtk_main_quit(), just like in a regular GTK application.
>>>>> [snip]
>>>>
>>>> I'm very glad to see someone is picking up a GTK problem.  Hardly any
>>>> work was done on GTK for a long time.
>>>>
>>>> I would appreciate it if a few people try this out and report any
>>>> problems they notice.
>>>
>>> Given the recent removal of GTK 1 support, attached is an updated patch.
>>
>> Though I never use the file open dialog, I just tried the patch.
>> On the Ubuntu 9.04, file chooser worked fine.
>>
>> But, on the cygwin, a problem occurs.
>> Without the patch, there's no problem to open file open dialog.
>>
>>    $ uname -a
>>    CYGWIN_NT-5.1 namsh 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
>>
>> If I run 'vim -f -g' (foreground), file chooser worked fine.
>> If I run 'vim -g'  (background), VIM died with SIGSEGV.
>
> Thanks for trying the patch out!  I'd like to see this get included, so
> it's good to see people giving it a shot.
>
> As for the crash, this happens without the patch as well, if the Gtk2
> file chooser is enabled.  This even happens in Vim 7.2 if the Gtk2 file
> chooser is enabled, so I'm wondering if there isn't something else going
> on here.

Even the original changeset that introduced the use of the file chooser
(a20218704019) crashes in cygwin.  I've been able to get other
applications (eog) to build and run in cygwin and use the file chooser
there.  So, it doesn't look like this is a problem specific to the
cygwin port of the Gtk libraries.

If need be, cygwin builds could use the old file chooser but that
doesn't help with the goal of removing old Gtk code.  Remember, the old
file chooser is likely being removed for Gtk3 along with all the other
deprecated widgets.

In the 2+ years the file chooser was active, before being disabled in
7.2b.026, there weren't any reported bugs that I can recall about gvim
crashing when using the file chooser.  I'm only subscribed to vim-dev,
though.  At any rate, it seems that either the bug didn't exist back
then and Gtk/Glib has changed in such a way that Vim's use of it is now
wrong or no one encountered (due to not using the file chooser) or was
bothered enough to report the bug.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

--
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