From hannes at yllr.net Tue Jun 1 08:12:33 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 1 Jun 2010 10:12:33 +0200 Subject: [Vimprobable-users] Automatic external action for certain mimetypes In-Reply-To: References: <20100504091229.5a084e6a@workstation> Message-ID: <20100601101233.115538f0@workstation> Hi! I finally found the time to dig through this patch: > + int i, j, pos, cmdlen; j is unused. > + for (i=0; i < LENGTH(actions) && matched_mimetype == FALSE; i++) { > + if (!strcmp(mime_type, actions[i].mime_type)) { This looks like a handy attack vector: send a prepared mime type and the code will look at it. Better use strncmp and restrict the comparison to the amount of bytes of actions[i].mime_type (and check whether the string lengths match). > + matched_mimetype = TRUE; > + } else { > + if (strstr(actions[i].mime_type, "/*")) { > + pos = (int) strstr(actions[i].mime_type, "/*") - (int) > actions[i].mime_type; This causes a compilation warning. Are you compiling with the recommended C flags listed on the website? If you want to check for the length of a substring until the first occurence of "/*", why not use strcspn to search for a slash and then check the next character manually? Then you don't need any casts at all. > + cmd = g_strdup(actions[i].mime_type); > + cmd[pos+1] = 0; Hmmm... I'd use strncpy, but this should work, too. > + if (strstr(mime_type, cmd)) > + matched_mimetype = TRUE; Again, why not strncmp? > + g_free(cmd); > + cmd = NULL; > + } > + } > + > + if (matched_mimetype == TRUE) { > + if (strstr(actions[i].cmd, "%u") != NULL) { > + pos = (int) strstr(actions[i].cmd, "%u") - (int) actions[i].cmd; Same compiler warning. Hannes From hannes at yllr.net Tue Jun 1 08:24:17 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 1 Jun 2010 10:24:17 +0200 Subject: [Vimprobable-users] Automatic external action for certain mimetypes In-Reply-To: References: Message-ID: <20100601102417.6d4e7965@workstation> Hello everyone, I've got another patch here which attempts to achieve the same effect. It's already a little older (my fault, I forgot - sorry to the author), so it will not apply completely cleanly (but only one reject which can be resolved in a trivial manner). What I like about this approach is the use of regular expressions. What's better in BlackLight's patch is the place it hooks itself into the handling. Problem: Both patches generate compiler warnings. Maybe you two can get together and combine your approaches to create the ultimate patch? ;) Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: urlhandler.patch Type: text/x-patch Size: 4413 bytes Desc: not available URL: From hannes at yllr.net Tue Jun 1 09:38:04 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 1 Jun 2010 11:38:04 +0200 Subject: [Vimprobable-users] Vimprobable 0.9.10.5 and Vimprobable2 0.8.4.1 released! Message-ID: <20100601113804.27da8435@workstation> Hello everyone, please excuse my long silence. Job changes have been eating my time. The new releases include: - Bugfix for Javascript driven links in hinting mode (bug reported by Albert Chang) The new Vimprobable2 version has in addition: - Quickmark saving (patch by Matto Fransen) - Toggling proxy usage at runtime (original patch by BlackLight, slightly reworked by me to use the :set command instead) The "external actions" and "gT" patches are still in the pipeline; I'm waiting for new versions of these. Hannes From hpdeifel at gmx.de Thu Jun 24 13:49:15 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Thu, 24 Jun 2010 15:49:15 +0200 Subject: [Vimprobable-users] Download does not work In-Reply-To: References: Message-ID: <20100624134915.GA9834@deepsilver> Hello, I use Vimprobable2 from git and webkit-gtk-1.2.1 from Gentoo. I recently noticed that downloading didn't work. Vimprobable just creates an empty file in my download directory, doesn't show any progress in the progressbar and prints the following: ** (vimprobable2:4249): CRITICAL **: \ void webkit_download_start(WebKitDownload*): assertion `priv->timer\ == NULL' failed I don't know anything about Webkit, but i found that when I delete the line: main.c:252: webkit_web_view_load_html_string(webview, html,\ webkit_download_get_uri(download)); The download works again, but still shows the failed assertation. However, this can be fixed by deleting the line: main.c:256: webkit_download_start(activeDownload); The Webkit function that emits the download_requested signal already calls webkit_download_start, when the signal was handled, i.e TRUE was returned by webview_download_cb. Regards, HP From akosmin at reliantsec.net Thu Jun 24 14:18:39 2010 From: akosmin at reliantsec.net (Adam Kosmin) Date: Thu, 24 Jun 2010 07:18:39 -0700 Subject: [Vimprobable-users] Download does not work References: <20100624134915.GA9834@deepsilver> Message-ID: Thanks for this. Works great. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes at yllr.net Thu Jun 24 16:26:22 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Thu, 24 Jun 2010 18:26:22 +0200 Subject: [Vimprobable-users] Download does not work In-Reply-To: <20100624134915.GA9834@deepsilver> References: <20100624134915.GA9834@deepsilver> Message-ID: <20100624162621.GC16048@laptop2.lan.localhost> Hi! On Thu, Jun 24, 2010 at 03:49:15PM +0200, Hans-Peter Deifel wrote: > I don't know anything about Webkit, but i found that when I delete the > line: > > main.c:252: webkit_web_view_load_html_string(webview, html,\ > webkit_download_get_uri(download)); > > The download works again, but still shows the failed assertation. > > However, this can be fixed by deleting the line: > > main.c:256: webkit_download_start(activeDownload); > > The Webkit function that emits the download_requested signal already > calls webkit_download_start, when the signal was handled, i.e TRUE was > returned by webview_download_cb. This fixes the oldest open bug - I'm sure you've got the gratitude of every single user out there! I'll work it in and push a new version to the repository tonight. Hannes From thomas at xteddy.org Sun Jun 27 12:07:44 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 27 Jun 2010 13:07:44 +0100 Subject: [Vimprobable-users] [PATCH 0/1] Middle-click context sensitivity. Message-ID: Hi, This is a really simple patch which makes middle-clicking in Vimprobable context-aware, in that if the middle button is clicked on a link, it's opened up in a new target, otherwise it assumes standard paste functionality. Hopefully this should stop people people needing to edit config.h all of the time. --- Thomas Adam (1): Make middle-click context aware config.h | 2 +- main.c | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletions(-) From thomas at xteddy.org Sun Jun 27 12:07:47 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 27 Jun 2010 13:07:47 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Make middle-click context aware Message-ID: When clicking on a link with the middle-mouse button, open that link in a new window, or for any other context, assume literal pasting with whatever is in the clipboard. --- config.h | 2 +- main.c | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/config.h b/config.h index 95444e9..af01812 100644 --- a/config.h +++ b/config.h @@ -217,7 +217,7 @@ static Command commands[] = { */ static Mouse mouse[] = { /* modmask, modkey, button, function, argument */ - { 0, 0, MOUSE_BUTTON_2, paste, {TargetCurrent | ClipboardPrimary | ClipboardGTK} }, + { 0, 0, MOUSE_BUTTON_2, paste, {TargetCurrent | ClipboardPrimary | ClipboardGTK, rememberedURI} }, { GDK_CONTROL_MASK, 0, MOUSE_BUTTON_2, paste, {TargetNew | ClipboardPrimary | ClipboardGTK} }, { GDK_CONTROL_MASK, 0, MOUSE_BUTTON_1, open, {TargetNew, rememberedURI} }, }; diff --git a/main.c b/main.c index 9eb1bac..b945656 100644 --- a/main.c +++ b/main.c @@ -1053,6 +1053,13 @@ gboolean paste(const Arg *arg) { Arg a = { .i = arg->i & TargetNew, .s = NULL }; + /* If we're over a link, open it in a new target. */ + if (strlen(rememberedURI) > 0) { + Arg new_target = { .i = TargetNew, .s = arg->s }; + open(&new_target); + return TRUE; + } + if (arg->i & ClipboardPrimary) a.s = gtk_clipboard_wait_for_text(clipboards[0]); if (!a.s && arg->i & ClipboardGTK) -- 1.6.6.196.g1f735 From hannes at yllr.net Mon Jun 28 20:33:01 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 28 Jun 2010 22:33:01 +0200 Subject: [Vimprobable-users] [PATCH 1/1] Make middle-click context aware In-Reply-To: References: Message-ID: <20100628203300.GA10719@laptop2.lan.localhost> Hello Thomas, thanks for this patch, applied and pushed! Another common feature request filled. One small wish for the future: Please make sure not to let your mail client wrap the lines in these mails so that the patches remain intact. Hannes From akosmin at reliantsec.net Mon Jun 28 20:34:46 2010 From: akosmin at reliantsec.net (Adam Kosmin) Date: Mon, 28 Jun 2010 13:34:46 -0700 Subject: [Vimprobable-users] [PATCH 1/1] Make middle-click context aware References: <20100628203300.GA10719@laptop2.lan.localhost> Message-ID: Why do people want to use the mouse at all with this browser? Sorry, had to ask... :) -----Original Message----- From: vimprobable-users-bounces at vimprobable.org on behalf of Hannes Sch?ller Sent: Mon 6/28/2010 4:33 PM To: vimprobable-users at vimprobable.org Subject: Re: [Vimprobable-users] [PATCH 1/1] Make middle-click context aware Hello Thomas, thanks for this patch, applied and pushed! Another common feature request filled. One small wish for the future: Please make sure not to let your mail client wrap the lines in these mails so that the patches remain intact. Hannes _______________________________________________ Vimprobable-users mailing list Vimprobable-users at vimprobable.org http://vimprobable.org/mailman/listinfo/vimprobable-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes at yllr.net Mon Jun 28 20:45:21 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 28 Jun 2010 22:45:21 +0200 Subject: [Vimprobable-users] [PATCH 1/1] Make middle-click context aware In-Reply-To: References: <20100628203300.GA10719@laptop2.lan.localhost> Message-ID: <20100628204520.GB10719@laptop2.lan.localhost> On Mon, Jun 28, 2010 at 01:34:46PM -0700, Adam Kosmin wrote: > Why do people want to use the mouse at all with this browser? Sorry, > had to ask... :) If we can accomodate these people with such a small patch, why not? :) Hannes From thomas at xteddy.org Mon Jun 28 20:50:15 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 28 Jun 2010 21:50:15 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Make middle-click context aware In-Reply-To: <20100628203300.GA10719@laptop2.lan.localhost> References: <20100628203300.GA10719@laptop2.lan.localhost> Message-ID: <20100628205013.GB2901@shuttle.home> On Mon, Jun 28, 2010 at 10:33:01PM +0200, Hannes Sch?ller wrote: > Hello Thomas, > > thanks for this patch, applied and pushed! Another common feature > request filled. One small wish for the future: Please make sure not to > let your mail client wrap the lines in these mails so that the patches > remain intact. That was probably due to text-flowed *again*. I thought I'd fixed it. Will check for next time. And for my next trick, I'll be submitting a few patches to allow for turning off scrollbars -- stand by. ;) -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From thomas at xteddy.org Mon Jun 28 23:32:55 2010 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 29 Jun 2010 00:32:55 +0100 Subject: [Vimprobable-users] [PATCH 0/1] Hide scrollbars (compile-time only) Message-ID: This patch simply fixes the compile-time directive of hiding scrollbars by setting some additional GTK properties on the scrolled window which weren't originally set. --- Thomas Adam (1): Correctly handle not drawing scrollbars main.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) From thomas at xteddy.org Mon Jun 28 23:33:16 2010 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 29 Jun 2010 00:33:16 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Correctly handle not drawing scrollbars Message-ID: If scrollbars have been disabled (DISABLE_SCROLLBAR) ensure that the size adjustments are set correctly on the scrolled window to allow for scrolling without scrollbars. --- main.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 92b4210..ade21e3 100644 --- a/main.c +++ b/main.c @@ -1911,7 +1911,6 @@ setup_gui() { gtk_window_set_default_size(GTK_WINDOW(window), 640, 480); box = GTK_BOX(gtk_vbox_new(FALSE, 0)); inputbox = gtk_entry_new(); - GtkWidget *viewport = gtk_scrolled_window_new(adjust_h, adjust_v); webview = (WebKitWebView*)webkit_web_view_new(); GtkBox *statusbar = GTK_BOX(gtk_hbox_new(FALSE, 0)); eventbox = gtk_event_box_new(); @@ -1929,11 +1928,23 @@ setup_gui() { gtk_widget_modify_bg(eventbox, GTK_STATE_NORMAL, &bg); gtk_widget_set_name(window, "Vimprobable2"); gtk_window_set_geometry_hints(GTK_WINDOW(window), NULL, &hints, GDK_HINT_MIN_SIZE); + #ifdef DISABLE_SCROLLBAR + GtkWidget *viewport = gtk_scrolled_window_new(NULL, NULL); gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(viewport), GTK_POLICY_NEVER, GTK_POLICY_NEVER); +#else + /* Ensure we still see scrollbars. */ + GtkWidget *viewport = gtk_scrolled_window_new(adjust_h, adjust_v); #endif + setup_signals(); gtk_container_add(GTK_CONTAINER(viewport), GTK_WIDGET(webview)); + + /* Ensure we set the scroll adjustments now, so that if we're not drawing + * titlebars, we can still scroll. + */ + gtk_widget_set_scroll_adjustments(GTK_WIDGET(webview), adjust_h, adjust_v); + font = pango_font_description_from_string(urlboxfont[0]); gtk_widget_modify_font(GTK_WIDGET(inputbox), font); pango_font_description_free(font); -- 1.6.6.196.g1f735 From thomas at xteddy.org Mon Jun 28 23:36:44 2010 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 29 Jun 2010 00:36:44 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Correctly handle not drawing scrollbars In-Reply-To: References: Message-ID: <20100628233643.GC2901@shuttle.home> On Tue, Jun 29, 2010 at 12:33:16AM +0100, Thomas Adam wrote: > If scrollbars have been disabled (DISABLE_SCROLLBAR) ensure that the size > adjustments are set correctly on the scrolled window to allow for scrolling > without scrollbars. Damn, this *still* appears to be wrapping. I'll send another version, when I work out why this is happening. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From thomas at xteddy.org Mon Jun 28 23:43:49 2010 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 29 Jun 2010 00:43:49 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Correctly handle not drawing scrollbars Message-ID: <20100628234348.GB29758@shuttle.home> If scrollbars have been disabled (DISABLE_SCROLLBAR) ensure that the size adjustments are set correctly on the scrolled window to allow for scrolling without scrollbars. --- main.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 92b4210..ade21e3 100644 --- a/main.c +++ b/main.c @@ -1911,7 +1911,6 @@ setup_gui() { gtk_window_set_default_size(GTK_WINDOW(window), 640, 480); box = GTK_BOX(gtk_vbox_new(FALSE, 0)); inputbox = gtk_entry_new(); - GtkWidget *viewport = gtk_scrolled_window_new(adjust_h, adjust_v); webview = (WebKitWebView*)webkit_web_view_new(); GtkBox *statusbar = GTK_BOX(gtk_hbox_new(FALSE, 0)); eventbox = gtk_event_box_new(); @@ -1929,11 +1928,23 @@ setup_gui() { gtk_widget_modify_bg(eventbox, GTK_STATE_NORMAL, &bg); gtk_widget_set_name(window, "Vimprobable2"); gtk_window_set_geometry_hints(GTK_WINDOW(window), NULL, &hints, GDK_HINT_MIN_SIZE); + #ifdef DISABLE_SCROLLBAR + GtkWidget *viewport = gtk_scrolled_window_new(NULL, NULL); gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(viewport), GTK_POLICY_NEVER, GTK_POLICY_NEVER); +#else + /* Ensure we still see scrollbars. */ + GtkWidget *viewport = gtk_scrolled_window_new(adjust_h, adjust_v); #endif + setup_signals(); gtk_container_add(GTK_CONTAINER(viewport), GTK_WIDGET(webview)); + + /* Ensure we set the scroll adjustments now, so that if we're not drawing + * titlebars, we can still scroll. + */ + gtk_widget_set_scroll_adjustments(GTK_WIDGET(webview), adjust_h, adjust_v); + font = pango_font_description_from_string(urlboxfont[0]); gtk_widget_modify_font(GTK_WIDGET(inputbox), font); pango_font_description_free(font); 1.6.6.196.g1f735 From thomas at xteddy.org Mon Jun 28 23:53:54 2010 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 29 Jun 2010 00:53:54 +0100 Subject: [Vimprobable-users] :set scrollbars - and cleanup of setup_gui() Message-ID: <20100628235343.GA29505@shuttle.home> Hi, I think it would be a nice feature (and a logical one, now that scrollbars can be hidden) if hiding scrollbars was a run-time option, and not a compile-time one. What do other people think? Adding this in isn't that difficult, but the code in setup_gui() does need looking at to make it not bolt-on to an already bloated function. Ideally, setup_gui() needs splitting up into two smaller functions, and the current mechanism of having global variables between all of those, should go away -- hence, I propose to create a GUI struct to hold these elements in. What do people think? I want to ask, so that I don't potentially waste my time for something that isn't wanted. :) -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From hannes at yllr.net Tue Jun 29 11:15:36 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 29 Jun 2010 13:15:36 +0200 Subject: [Vimprobable-users] [PATCH 1/1] Correctly handle not drawing scrollbars In-Reply-To: <20100628234348.GB29758@shuttle.home> References: <20100628234348.GB29758@shuttle.home> Message-ID: <20100629131536.1b9da4a2@workstation> Hi! Thomas Adam wrote: > If scrollbars have been disabled (DISABLE_SCROLLBAR) ensure that the > size adjustments are set correctly on the scrolled window to allow > for scrolling without scrollbars. Pushed, too. Thanks, another bug fixed! Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From hannes at yllr.net Tue Jun 29 11:24:35 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 29 Jun 2010 13:24:35 +0200 Subject: [Vimprobable-users] :set scrollbars - and cleanup of setup_gui() In-Reply-To: <20100628235343.GA29505@shuttle.home> References: <20100628235343.GA29505@shuttle.home> Message-ID: <20100629132435.0f3f753e@workstation> Hi! > I think it would be a nice feature (and a logical one, now that > scrollbars can be hidden) if hiding scrollbars was a run-time option, > and not a compile-time one. For Vimprobable2 (in the style :set scrollbars (true|false)), ok, for Vimprobable1, this would be overkill. > Ideally, setup_gui() needs splitting up into two smaller functions, > and the current mechanism of having global variables between all of > those, should go away -- hence, I propose to create a GUI struct to > hold these elements in. It could be cleaner, so I wouldn't opposed this in general. However, the basic structure of the code should remain the same in both branches so my request would be to make sure this new struct works in both versions. Of course, I'd welcome anyone else's input, too. Hannes From hpdeifel at gmx.de Tue Jun 29 13:38:53 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Tue, 29 Jun 2010 15:38:53 +0200 Subject: [Vimprobable-users] [PATCH] Fix focusing input text boxes via hints Message-ID: <1277818734-8069-1-git-send-email-hpdeifel@gmx.de> Hello, For some reason, the webview_keypress_cb doesn't return TRUE when the event was handled. This passes control on to WebKit, that tries to handle it. This is the reason why the last number of a hint is inserted in input fields, when selecting it via hints. Regards, HP From hpdeifel at gmx.de Tue Jun 29 13:38:54 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Tue, 29 Jun 2010 15:38:54 +0200 Subject: [Vimprobable-users] [PATCH] Fix focusing input text boxes via hints In-Reply-To: <1277818734-8069-1-git-send-email-hpdeifel@gmx.de> References: <1277818734-8069-1-git-send-email-hpdeifel@gmx.de> Message-ID: <1277818734-8069-2-git-send-email-hpdeifel@gmx.de> --- main.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index ade21e3..4e30893 100644 --- a/main.c +++ b/main.c @@ -393,6 +393,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { a.i = Silent; script(&a); update_state(); + return TRUE; } else if ((CLEAN(event->state) == 0 && (event->keyval >= GDK_a && event->keyval <= GDK_z)) || (CLEAN(event->state) == GDK_SHIFT_MASK && (event->keyval >= GDK_A && event->keyval <= GDK_Z))) { /* update hints by link text */ @@ -409,6 +410,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { script(&a); update_state(); } + return TRUE; } else if (CLEAN(event->state) == 0 && event->keyval == GDK_Return && count) { memset(inputBuffer, 0, 65); sprintf(inputBuffer, "%d", count); @@ -418,6 +420,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { memset(inputBuffer, 0, 65); count = 0; update_state(); + return TRUE; } else if (CLEAN(event->state) == 0 && event->keyval == GDK_BackSpace) { if (count > 0) { count = ((count >= 10) ? count/10 : 0); @@ -437,6 +440,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { script(&a); update_state(); } + return TRUE; } break; } -- 1.7.1 From matto at matto.nl Tue Jun 29 19:41:22 2010 From: matto at matto.nl (Matto Fransen) Date: Tue, 29 Jun 2010 21:41:22 +0200 Subject: [Vimprobable-users] :set scrollbars - and cleanup of setup_gui() In-Reply-To: <20100629132435.0f3f753e@workstation> References: <20100628235343.GA29505@shuttle.home> <20100629132435.0f3f753e@workstation> Message-ID: <20100629194120.GA3413@dantooine> Hello, On Tue, Jun 29, 2010 at 01:24:35PM +0200, Hannes Sch?ller wrote: > > I think it would be a nice feature (and a logical one, now that > > scrollbars can be hidden) if hiding scrollbars was a run-time option, > > and not a compile-time one. > > For Vimprobable2 (in the style :set scrollbars (true|false)), ok, for > Vimprobable1, this would be overkill. I think this would be nice indeed. > > Ideally, setup_gui() needs splitting up into two smaller functions, > > and the current mechanism of having global variables between all of > > those, should go away -- hence, I propose to create a GUI struct to > > hold these elements in. > > It could be cleaner, so I wouldn't opposed this in general. However, > the basic structure of the code should remain the same in both branches > so my request would be to make sure this new struct works in both > versions. > > Of course, I'd welcome anyone else's input, too. Imho splitting up setup_gui() is a good approach. I like to vote for that :) Sincerely, Matto -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From thomas at xteddy.org Tue Jun 29 21:44:56 2010 From: thomas at xteddy.org (Thomas Adam) Date: Tue, 29 Jun 2010 22:44:56 +0100 Subject: [Vimprobable-users] :set scrollbars - and cleanup of setup_gui() In-Reply-To: <20100629194120.GA3413@dantooine> References: <20100628235343.GA29505@shuttle.home> <20100629132435.0f3f753e@workstation> <20100629194120.GA3413@dantooine> Message-ID: <20100629214455.GA2860@shuttle.home> On Tue, Jun 29, 2010 at 09:41:22PM +0200, Matto Fransen wrote: > Hello, > > On Tue, Jun 29, 2010 at 01:24:35PM +0200, Hannes Sch?ller wrote: > > > > I think it would be a nice feature (and a logical one, now that > > > scrollbars can be hidden) if hiding scrollbars was a run-time option, > > > and not a compile-time one. > > > > For Vimprobable2 (in the style :set scrollbars (true|false)), ok, for > > Vimprobable1, this would be overkill. > > I think this would be nice indeed. Expect a patch in due course then. :) > > > Ideally, setup_gui() needs splitting up into two smaller functions, > > > and the current mechanism of having global variables between all of > > > those, should go away -- hence, I propose to create a GUI struct to > > > hold these elements in. > > > > It could be cleaner, so I wouldn't opposed this in general. However, > > the basic structure of the code should remain the same in both branches > > so my request would be to make sure this new struct works in both > > versions. > > > > Of course, I'd welcome anyone else's input, too. > > Imho splitting up setup_gui() is a good approach. I like to vote > for that :) Likewise. :) I'll mail something out hopefully before the weekend. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From thomas at xteddy.org Wed Jun 30 08:42:50 2010 From: thomas at xteddy.org (Thomas Adam) Date: Wed, 30 Jun 2010 09:42:50 +0100 Subject: [Vimprobable-users] #vimprobable IRC Channel (Freenode) Message-ID: <20100630084249.GC3985@abacus.soton.smoothwall.net> Hi all, Hopefully not too presumptuous of me, but I couldn't find on freenode, or oftc a #vimprobable IRC channel, so I went ahead, and created #vimprobable on irc.freenode.net Perhaps some of you will idle there with me? :) If, OTOH, there already is such an IRC channel, perhaps this can be added to the website? :) Kindly, -- Thomas Adam From hannes at yllr.net Wed Jun 30 14:03:05 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Wed, 30 Jun 2010 16:03:05 +0200 Subject: [Vimprobable-users] [PATCH] Fix focusing input text boxes via hints In-Reply-To: <1277818734-8069-1-git-send-email-hpdeifel@gmx.de> References: <1277818734-8069-1-git-send-email-hpdeifel@gmx.de> Message-ID: <20100630140304.GA2211@laptop2.lan.localhost> Hello Hans-Peter! > For some reason, the webview_keypress_cb doesn't return TRUE > when the event was handled. This passes control on to > WebKit, that tries to handle it. > > This is the reason why the last number of a hint is inserted > in input fields, when selecting it via hints. Excellent! Pushed, thanks. Hannes From hannes at yllr.net Wed Jun 30 15:38:33 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Wed, 30 Jun 2010 17:38:33 +0200 Subject: [Vimprobable-users] #vimprobable IRC Channel (Freenode) In-Reply-To: <20100630084249.GC3985@abacus.soton.smoothwall.net> References: <20100630084249.GC3985@abacus.soton.smoothwall.net> Message-ID: <20100630153832.GB2211@laptop2.lan.localhost> Hi! > Hopefully not too presumptuous of me, but I couldn't find on freenode, or > oftc a #vimprobable IRC channel, so I went ahead, and created #vimprobable > on irc.freenode.net > > Perhaps some of you will idle there with me? :) > > If, OTOH, there already is such an IRC channel, perhaps this can be added to > the website? :) There is no other channel I'm aware of and I'm fine with calling this one "official" (i.e. add it to the website). I'll try idling as much as possible myself ;) Hannes