vimprobable-users — Mailing list for Vimprobable users

[Vimprobable-users] [Ticket #9] Edit text areas using $EDITOR

[Hannes S. <ha...@yl...>]

Hi,

here is another patch which needs testing. The purpose is to edit text areas  
(or input type=text fields) using an external editor. The editor is read  
from $EDITOR. The function is called using Ctrl-t by default. If you plan to  
rebind it, make sure you use something involving Ctrl, because something  
else will not work in INSERT mode (which you should usually be in when a  
text area is active).

Hannes

Re: [Vimprobable-users] [Ticket #6] Handling new window links generated by Javascript

[Hannes S. <ha...@yl...>]

Hans-Peter Deifel writes:
> I haven't read the documentation for this, but doesn't "new_view" have
> to be destroyed somewhere? Otherwise you'll be leaking memory.

Here is a revised version of the patch (also with decent comments).

Hannes

Re: [Vimprobable-users] [Ticket #6] Handling new window links generated by Javascript

[Jason R. <jas...@gm...>]

On 28/06/12 at 10:32am, Hannes Schüller wrote:
> Jason Ryan <jas...@gm...> wrote:
> > On 28/06/12 at 02:35am, Hans-Peter Deifel wrote:
> > > On Mi, Jun 27 2012, Hannes Sch__ller wrote:
> > > > the attached patch should finally make the browser handle
> > > > window.open events correctly. Testing of different websites would
> > > > be greatly appreciated.
> > > 
> > > I haven't tested this much, but so far it seems to work. I have
> > > published a git branch with the patch for easier testing:
> > > 
> > > http://git.cs.fau.de/?p=lu03pevi/vimprobable;a=shortlog;h=refs/heads/fixes/javascript_windows
> > > 
> > Thanks this works great. 
> > 
> > There is slightly aberrant behaviour when opening a link from within
> > Google Reader (I know, no-one cares, but I wanted to mention it in
> > case it pops up anywhere else): hitting 'v' opens the linked article
> > in a new window and also opens duckduckgo (default search engine)
> > with an 'about:blank' search.
> 
> Who says no-one cares? Please show me an example (which I don't have to
> sign up for). If I can reproduce it, I will try to fix this. Though, of
> course, I'd rather have two windows opened than none ;)
> 
I meant that as it was a Google-related site, I would not expect much interest
from the Vimprobable community (and rightly so…)

I've only seen it on that site and it does require a sign on; and yes, you are
right, it works twice as well as it used to!

/J
-- 

http://jasonwryan.com/  [GnuPG Key: B1BD4E40]

Re: [Vimprobable-users] [Ticket #6] Handling new window links generated by Javascript

[Hannes S. <ha...@yl...>]

Jason Ryan <jas...@gm...> wrote:
> On 28/06/12 at 02:35am, Hans-Peter Deifel wrote:
> > On Mi, Jun 27 2012, Hannes Sch__ller wrote:
> > > the attached patch should finally make the browser handle
> > > window.open events correctly. Testing of different websites would
> > > be greatly appreciated.
> > 
> > I haven't tested this much, but so far it seems to work. I have
> > published a git branch with the patch for easier testing:
> > 
> > http://git.cs.fau.de/?p=lu03pevi/vimprobable;a=shortlog;h=refs/heads/fixes/javascript_windows
> > 
> Thanks this works great. 
> 
> There is slightly aberrant behaviour when opening a link from within
> Google Reader (I know, no-one cares, but I wanted to mention it in
> case it pops up anywhere else): hitting 'v' opens the linked article
> in a new window and also opens duckduckgo (default search engine)
> with an 'about:blank' search.

Who says no-one cares? Please show me an example (which I don't have to
sign up for). If I can reproduce it, I will try to fix this. Though, of
course, I'd rather have two windows opened than none ;)

Hannes

Re: [Vimprobable-users] [Ticket #6] Handling new window links generated by Javascript

[Jason R. <jas...@gm...>]

On 28/06/12 at 02:35am, Hans-Peter Deifel wrote:
> On Mi, Jun 27 2012, Hannes Schüller wrote:
> > Hi,
> >
> > the attached patch should finally make the browser handle window.open
> > events correctly. Testing of different websites would be greatly
> > appreciated.
> 
> I haven't tested this much, but so far it seems to work. I have
> published a git branch with the patch for easier testing:
> 
> http://git.cs.fau.de/?p=lu03pevi/vimprobable;a=shortlog;h=refs/heads/fixes/javascript_windows
> 
Thanks this works great. 

There is slightly aberrant behaviour when opening a link from within Google
Reader (I know, no-one cares, but I wanted to mention it in case it pops up
anywhere else): hitting 'v' opens the linked article in a new window and also
opens duckduckgo (default search engine) with an 'about:blank' search.


/J

-- 

http://jasonwryan.com/  [GnuPG Key: B1BD4E40]

Re: [Vimprobable-users] [Ticket #6] Handling new window links generated by Javascript

[Hans-Peter D. <hpd...@gm...>]

On Mi, Jun 27 2012, Hannes Schüller wrote:
> Hi,
>
> the attached patch should finally make the browser handle window.open
> events correctly. Testing of different websites would be greatly
> appreciated.

I haven't tested this much, but so far it seems to work. I have
published a git branch with the patch for easier testing:

http://git.cs.fau.de/?p=lu03pevi/vimprobable;a=shortlog;h=refs/heads/fixes/javascript_windows

> -static gboolean
> -webview_open_in_new_window_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) {
> -    Arg a = { .i = TargetNew, .s = (char*)webkit_web_view_get_uri(webview) };
> -    if (strlen(rememberedURI) > 0) {
> -        a.s = rememberedURI;
> -    }
> +void
> +webview_open_js_window_cb(WebKitWebView* web_view, GParamSpec param_spec) {
> +    Arg a = { .i = TargetNew, .s = (char*)webkit_web_view_get_uri(web_view) };
>      open_arg(&a);
> -    return FALSE;
> +}
> +
> +static WebKitWebView *
> +webview_open_in_new_window_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) {
> +    WebKitWebView *new_view = WEBKIT_WEB_VIEW(webkit_web_view_new());

I haven't read the documentation for this, but doesn't "new_view" have
to be destroyed somewhere? Otherwise you'll be leaking memory.

> +    g_object_connect(new_view, "signal::notify::uri", G_CALLBACK(webview_open_js_window_cb), NULL, NULL);
> +    return new_view;
>  }


HP

[Vimprobable-users] [Ticket #6] Handling new window links generated by Javascript

[Hannes S. <ha...@yl...>]

Hi,

the attached patch should finally make the browser handle window.open events  
correctly. Testing of different websites would be greatly appreciated.

Hannes

[Vimprobable-users] Vimprobable2 1.0.3 released!

[Hannes S. <ha...@yl...>]

A new bugfix version has been released today. This corrects one issue which  
could occur due to non-initialised memory in the key mapping routine as  
reported on IRC.

As this routine does not exist in Vimprobable1, it is obviously not affected  
by the bug.

Hannes

Re: [Vimprobable-users] [PATCH 0/2] Vimprobable1 autohide inputbar when empty.

[Hannes S. <ha...@yl...>]

gre...@gm... wrote:
> On Sun May 27 2012 04:40:14 AM CDT, Hannes Sch__ller <ha...@yl...>
> wrote:
> > Greg Lutostanski <gre...@gm...> wrote:
> > > On Sun, May 06, 2012 at 04:01:22PM +0200, Hannes Sch??ller wrote:
> > > > I find it strange that in your patch, you never actually check
> > > > whether the inputbar is empty. Unless I'm misinterpreting
> > > > something, you simply force it to always be empty by setting
> > > > echo_active = false and then hide it.
> > > 
> > > Your right, I don't explicitly check as to whether the inputbar is
> > > empty. Instead I am using the boolean echo_active to check if
> > > something is in the inputbar that should be seen. Basically
> > > whenever echo(* Arg) is used, it is set to show the inputbar and
> > > prevent automatic clearing.
> > 
> > What if some function calls echo()? This has nothing to do with the
> > state of echo_active, but nevertheless, it will populate the bar.
> 
> Well echo_active wasn't ever used in the codebase for vimprobable1
> --except for one if statement, so I changed it so that echo_active
> switches on/off whenever echo() or clear_echo() is used. Patch 1/2
> has all these changes, the second patch builds on top to do the
> hiding of the bar.

Yes, that was exactly my initial point: You're not just hiding the bar
when it is not used, but *you're also changing the way feedback works*
at the same time. I.e. the "forcing the bar to be empty". My feeling is
that these are distinct changes, not one. With your patch, there is no
way to hide the bar automatically, but still get feedback messages from
the browser.

Maybe it is only really useful in this combination, but personally, I'm
not convinced. Since there is grave silence otherwise, it is hard for
me to gauge whether I'm off in my judgement.

Hannes

Re: [Vimprobable-users] [PATCH 0/2] Vimprobable1 autohide inputbar when empty.

[<gre...@gm...>]

On Sun May 27 2012 04:40:14 AM CDT, Hannes Schüller <ha...@yl...> wrote:

> Hi,
> 
> sorry about the late reply.
> 
> Greg Lutostanski <gre...@gm...> wrote:
> > On Sun, May 06, 2012 at 04:01:22PM +0200, Hannes Sch??ller wrote:
> > > I find it strange that in your patch, you never actually check
> > > whether the inputbar is empty. Unless I'm misinterpreting
> > > something, you simply force it to always be empty by setting
> > > echo_active = false and then hide it.
> > 
> > Your right, I don't explicitly check as to whether the inputbar is
> > empty. Instead I am using the boolean echo_active to check if
> > something is in the inputbar that should be seen. Basically whenever
> > echo(* Arg) is used, it is set to show the inputbar and prevent
> > automatic clearing.
> 
> What if some function calls echo()? This has nothing to do with the
> state of echo_active, but nevertheless, it will populate the bar.

Well echo_active wasn't ever used in the codebase for vimprobable1 --except for one if statement, so I changed it so that echo_active switches on/off whenever echo() or clear_echo() is used. Patch 1/2 has all these changes, the second patch builds on top to do the hiding of the bar.

-- Greg

[Vimprobable-users] Vimprobable1 1.0.2 & Vimprobable2 1.0.2 released!

[Hannes S. <ha...@yl...>]

Hi,

new bugfix releases of both branches have just been uploaded to the
website and pushed to the code repository. Sorry for the delays of
merging these changes.

- Fixing wrong entries in command history (Daniel Carl)
- Fixing crash when completing too many URLs (Vimprobable1; Hans-Peter
  Deifel)
- Don't modify the input bar if it's focused (Hans-Peter Deifel)

There are some patches for new features still in the pipeline, but none
seem to be fully mature right now. They can all be found on the mailing
list. Some feedback, discussion or testing might help to speed things
up.

Hannes

Re: [Vimprobable-users] [PATCH] Don't modify the input bar if it's focused

[Hannes S. <ha...@yl...>]

Merged as well.

Re: [Vimprobable-users] [Vimprobable1 PATCH] Fix crash when completing too many URLs

[Hannes S. <ha...@yl...>]

Merged, thank you!

Hannes

Re: [Vimprobable-users] [PATCH] Fixed wrong entries in command history

[Hannes S. <ha...@yl...>]

This, and the additional patch, has now been merged. Thanks again!

Hannes

Re: [Vimprobable-users] [PATCH 0/2] Vimprobable1 autohide inputbar when empty.

[Hannes S. <ha...@yl...>]

Hi,

sorry about the late reply.

Greg Lutostanski <gre...@gm...> wrote:
> On Sun, May 06, 2012 at 04:01:22PM +0200, Hannes Sch??ller wrote:
> > I find it strange that in your patch, you never actually check
> > whether the inputbar is empty. Unless I'm misinterpreting
> > something, you simply force it to always be empty by setting
> > echo_active = false and then hide it.
>
> Your right, I don't explicitly check as to whether the inputbar is
> empty. Instead I am using the boolean echo_active to check if
> something is in the inputbar that should be seen. Basically whenever
> echo(* Arg) is used, it is set to show the inputbar and prevent
> automatic clearing.

What if some function calls echo()? This has nothing to do with the
state of echo_active, but nevertheless, it will populate the bar.

Hannes

Re: [Vimprobable-users] [PATCH 0/2] Vimprobable1 autohide inputbar when empty.

[Greg L. <gre...@gm...>]

On Sun, May 06, 2012 at 04:01:22PM +0200, Hannes Sch??ller wrote:
> Hello Greg,
> 

Hi Hannes,

Thanks for taking a look at this. And as this is my first time
posting anything in this mailing list, let me say thanks for the work
you and everyone else here have done making a great program.

> I find it strange that in your patch, you never actually check whether
> the inputbar is empty. Unless I'm misinterpreting something, you simply
> force it to always be empty by setting echo_active = false and then
> hide it.
Your right, I don't explicitly check as to whether the inputbar is
empty. Instead I am using the boolean echo_active to check if something is
in the inputbar that should be seen. Basically whenever echo(* Arg) is
used, it is set to show the inputbar and prevent automatic clearing.

On the other hand when the inputbar has user input in it -- it pops up
and stays visbile as long as it is in line-edit mode. (When it is
activated [Enter] it goes away immediately.

> 
> Last year, I made a similar patch which you can still find in the
> archives here:
> http://sourceforge.net/mailarchive/forum.php?thread_name=20111209082411.GA15480%40ubuntu.dotsource.local&forum_name=vimprobable-users
> (for some reason the frontend claims the initial message, which
> includes the patch, is in HTML format; which it isn't). It had some
> issues, though (as pointed out by Daniel in the thread). Maybe this can
> give you some inspiration?
> 
> Hannes

I think I have made it so that whenever there is some text in the
inputbar -- no matter what it is, it is visible. The issues you refer to
are not apparent in this patchset.

Unfourtunately this is my first time submitting patches using git so the
way it split into two different patches makes the changes less apparent.

I have tested it pretty extensively and there are only two hiccups as
far as I can tell.
    1. When using the GTK_PROGRESS_BAR the inputbar goes away then pops
    back up to show the progress -- it hides/unhides fast.
    2. The inputbar starts shown -- which is in my opinion incorrect
    behavior.

Please note that the above hiccups are easily fixable with two small
changes -- I just notice them until after I sent this patchset in.

Thanks,
    Greg

Re: [Vimprobable-users] [PATCH 0/2] Vimprobable1 autohide inputbar when empty.

[Hannes S. <ha...@yl...>]

Hello Greg,

I find it strange that in your patch, you never actually check whether
the inputbar is empty. Unless I'm misinterpreting something, you simply
force it to always be empty by setting echo_active = false and then
hide it.

Last year, I made a similar patch which you can still find in the
archives here:
http://sourceforge.net/mailarchive/forum.php?thread_name=20111209082411.GA15480%40ubuntu.dotsource.local&forum_name=vimprobable-users
(for some reason the frontend claims the initial message, which
includes the patch, is in HTML format; which it isn't). It had some
issues, though (as pointed out by Daniel in the thread). Maybe this can
give you some inspiration?

Hannes

[Vimprobable-users] [PATCH 1/2] Refactor echo and clearing of inputbar to make it easier to follow.

[Greg L. <gre...@gm...>]

---
 main.c |   86 +++++++++++++++++++++++++++++++++++----------------------------
 1 files changed, 48 insertions(+), 38 deletions(-)

diff --git a/main.c b/main.c
index 6d6739a..1b3d133 100644
--- a/main.c
+++ b/main.c
@@ -64,6 +64,7 @@ static gboolean bookmark(const Arg *arg);
 static gboolean complete(const Arg *arg);
 static gboolean descend(const Arg *arg);
 static gboolean echo(const Arg *arg);
+static gboolean clear_echo(void);
 static gboolean focus_input(const Arg *arg);
 static gboolean input(const Arg *arg);
 static gboolean navigate(const Arg *arg);
@@ -134,7 +135,7 @@ static char *modkeys;
 static char current_modkey;
 static char *search_handle;
 static gboolean search_direction;
-static gboolean echo_active = TRUE;
+static gboolean echo_active = False;
 
 static GdkNativeWindow embed = 0;
 static char *winid = NULL;
@@ -339,9 +340,7 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) {
     case ModeNormal:
         if ((CLEAN(event->state) & ~irrelevant) == 0) {
             if (IS_ESCAPE(event)) {
-                a.i = Info;
-                a.s = g_strdup("");
-                echo(&a);
+                clear_echo();
             } else if (current_modkey == 0 && ((event->keyval >= GDK_1 && event->keyval <= GDK_9)
                     || (event->keyval == GDK_0 && count))) {
                 count = (count ? count * 10 : 0) + (event->keyval - GDK_0);
@@ -378,13 +377,13 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) {
         }
     case ModePassThrough:
         if (IS_ESCAPE(event)) {
-            echo(&a);
+            clear_echo();
             set(&a);
             return TRUE;
         }
         break;
     case ModeSendKey:
-        echo(&a);
+        clear_echo();
         set(&a);
         break;
     }
@@ -505,6 +504,9 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) {
         search_direction = forward;
         search_handle = g_strdup(&text[1]);
 #endif
+        a.i = Info;
+        a.s = g_strdup(text);
+        echo(&a);
     } else if (text[0] == '.' || text[0] == ',' || text[0] == ';') {
         a.i = Silent;
         a.s = g_strdup_printf("hints.fire();");
@@ -514,7 +516,7 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) {
     } else
         return;
     if (!echo_active)
-        gtk_entry_set_text(entry, "");
+        clear_echo();
     gtk_widget_grab_focus(GTK_WIDGET(webview));
 }
 
@@ -777,6 +779,7 @@ complete(const Arg *arg) {
     static char **suggestions;
     static GtkWidget **widgets;
     static int n = 0, m, current = -1;
+    Arg a;
 
     str = (char*)gtk_entry_get_text(GTK_ENTRY(inputbox));
     len = strlen(str);
@@ -943,10 +946,16 @@ complete(const Arg *arg) {
         gdk_color_parse(completionbgcolor[2], &color);
         gtk_widget_modify_bg(GTK_WIDGET(widgets[current]), GTK_STATE_NORMAL, &color);
         s = g_strconcat(":", suggestions[current], NULL);
-        gtk_entry_set_text(GTK_ENTRY(inputbox), s);
+        a.i = Info;
+        a.s = g_strdup(s);
+        echo(&a);
         g_free(s);
-    } else
-        gtk_entry_set_text(GTK_ENTRY(inputbox), prefix);
+    } else{
+        a.i = Info;
+        a.s = g_strdup(prefix);
+        echo(&a);
+    }
+
     gtk_editable_set_position(GTK_EDITABLE(inputbox), -1);
     return TRUE;
 }
@@ -994,6 +1003,11 @@ echo(const Arg *arg) {
 
     if (index < Info || index > Error)
         return TRUE;
+    if(!arg->s){
+        clear_echo();
+        return TRUE;
+    }
+    echo_active = True;
     font = pango_font_description_from_string(urlboxfont[index]);
     gtk_widget_modify_font(inputbox, font);
     pango_font_description_free(font);
@@ -1003,7 +1017,7 @@ echo(const Arg *arg) {
     if (urlboxbgcolor[index])
         gdk_color_parse(urlboxbgcolor[index], &color);
     gtk_widget_modify_base(inputbox, GTK_STATE_NORMAL, urlboxbgcolor[index] ? &color : NULL);
-    gtk_entry_set_text(GTK_ENTRY(inputbox), !arg->s ? "" : arg->s);
+    gtk_entry_set_text(GTK_ENTRY(inputbox), arg->s);
 	/* TA:  Always free arg->s here, rather than relying on the caller to do
 	 * this.
 	 */
@@ -1013,6 +1027,27 @@ echo(const Arg *arg) {
 }
 
 gboolean
+clear_echo() {
+    PangoFontDescription *font;
+    GdkColor color;
+    int index = 0;
+    echo_active = False;
+    
+    font = pango_font_description_from_string(urlboxfont[index]);
+    gtk_widget_modify_font(inputbox, font);
+    pango_font_description_free(font);
+    if (urlboxcolor[index])
+        gdk_color_parse(urlboxcolor[index], &color);
+    gtk_widget_modify_text(inputbox, GTK_STATE_NORMAL, urlboxcolor[index] ? &color : NULL);
+    if (urlboxbgcolor[index])
+        gdk_color_parse(urlboxbgcolor[index], &color);
+    gtk_widget_modify_base(inputbox, GTK_STATE_NORMAL, urlboxbgcolor[index] ? &color : NULL);
+    gtk_entry_set_text(GTK_ENTRY(inputbox), "");
+    
+    return TRUE;
+}
+
+gboolean
 input(const Arg *arg) {
     int pos = 0;
     count = 0;
@@ -1021,33 +1056,8 @@ input(const Arg *arg) {
 
     update_state();
 
-    /* Set the colour and font back to the default, so that we don't still
-     * maintain a red colour from a warning from an end of search indicator,
-     * etc.
-     *
-     * XXX - unify this with echo() at some point.
-     */
-    {
-        GdkColor ibox_fg_color;
-        GdkColor ibox_bg_color;
-        PangoFontDescription *font;
-        int index = Info;
-
-        font = pango_font_description_from_string(urlboxfont[index]);
-        gtk_widget_modify_font(inputbox, font);
-        pango_font_description_free(font);
-
-        if (urlboxcolor[index])
-            gdk_color_parse(urlboxcolor[index], &ibox_fg_color);
-        if (urlboxbgcolor[index])
-            gdk_color_parse(urlboxbgcolor[index], &ibox_bg_color);
-
-        gtk_widget_modify_text(inputbox, GTK_STATE_NORMAL, urlboxcolor[index] ? &ibox_fg_color : NULL);
-        gtk_widget_modify_base(inputbox, GTK_STATE_NORMAL, urlboxbgcolor[index] ? &ibox_bg_color : NULL);
-    }
-
     /* to avoid things like :open URL :open URL2  or :open :open URL */
-    gtk_entry_set_text(GTK_ENTRY(inputbox), "");
+    clear_echo();
     gtk_editable_insert_text(GTK_EDITABLE(inputbox), arg->s, -1, &pos);
     if (arg->i & InsertCurrentURL && (url = webkit_web_view_get_uri(webview)))
         gtk_editable_insert_text(GTK_EDITABLE(inputbox), url, -1, &pos);
@@ -1416,7 +1426,7 @@ set(const Arg *arg) {
             search_handle = NULL;
             webkit_web_view_unmark_text_matches(webview);
         }
-        gtk_entry_set_text(GTK_ENTRY(inputbox), "");
+        clear_echo();
         gtk_widget_grab_focus(GTK_WIDGET(webview));
         break;
     case ModePassThrough:
-- 
1.7.5.4

[Vimprobable-users] [PATCH 2/2] Allow autohiding of inputbar when empty.

[Greg L. <gre...@gm...>]

---
 config.h |    1 +
 main.c   |   39 ++++++++++++++++++++++++++++++++++-----
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/config.h b/config.h
index 6e712ed..e5b629b 100644
--- a/config.h
+++ b/config.h
@@ -42,6 +42,7 @@ static const char statusfont[]          = "monospace bold 8";   /* font for stat
 #define             ENABLE_INCREMENTAL_SEARCH
 #define             ENABLE_GTK_PROGRESS_BAR
 #define             ENABLE_WGET_PROGRESS_BAR
+#define             ENABLE_AUTOHIDE_INPUTBAR
 static const int progressbartick        = 20;
 static const char progressborderleft    = '[';
 static const char progressbartickchar   = '=';
diff --git a/main.c b/main.c
index 1b3d133..e57abbf 100644
--- a/main.c
+++ b/main.c
@@ -163,6 +163,11 @@ static void new_generic_request(SoupSession *soup_ses, SoupMessage *soup_msg, gp
 static void update_cookie_jar(SoupCookieJar *jar, SoupCookie *old, SoupCookie *new);
 static void handle_cookie_request(SoupMessage *soup_msg, gpointer unused);
 #endif
+#ifdef ENABLE_GTK_PROGRESS_BAR
+#ifdef ENABLE_AUTOHIDE_INPUTBAR
+static gboolean gtk_progress_visible = FALSE;
+#endif
+#endif
 /* callbacks */
 void
 window_destroyed_cb(GtkWidget *window, gpointer func_data) {
@@ -178,6 +183,16 @@ void
 webview_progress_changed_cb(WebKitWebView *webview, int progress, gpointer user_data) {
 #ifdef ENABLE_GTK_PROGRESS_BAR
     gtk_entry_set_progress_fraction(GTK_ENTRY(inputbox), progress == 100 ? 0 : (double)progress/100);
+#ifdef ENABLE_AUTOHIDE_INPUTBAR
+    if(progress == 100)
+        gtk_progress_visible = False;
+    else
+        gtk_progress_visible = True;
+    if(!gtk_progress_visible && !echo_active && !gtk_widget_has_focus(inputbox))
+        gtk_widget_hide(inputbox);
+    else
+        gtk_widget_show(inputbox);
+#endif
 #endif
     update_state();
 }
@@ -377,14 +392,14 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) {
         }
     case ModePassThrough:
         if (IS_ESCAPE(event)) {
-            clear_echo();
             set(&a);
+            clear_echo();
             return TRUE;
         }
         break;
     case ModeSendKey:
-        clear_echo();
         set(&a);
+        clear_echo();
         break;
     }
     return FALSE;
@@ -515,9 +530,9 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) {
         update_state();
     } else
         return;
+    gtk_widget_grab_focus(GTK_WIDGET(webview));
     if (!echo_active)
         clear_echo();
-    gtk_widget_grab_focus(GTK_WIDGET(webview));
 }
 
 gboolean
@@ -1021,6 +1036,9 @@ echo(const Arg *arg) {
 	/* TA:  Always free arg->s here, rather than relying on the caller to do
 	 * this.
 	 */
+#ifdef ENABLE_AUTOHIDE_INPUTBAR
+    gtk_widget_show(inputbox);
+#endif
     if (arg->s)
         g_free(arg->s);
     return TRUE;
@@ -1043,7 +1061,15 @@ clear_echo() {
         gdk_color_parse(urlboxbgcolor[index], &color);
     gtk_widget_modify_base(inputbox, GTK_STATE_NORMAL, urlboxbgcolor[index] ? &color : NULL);
     gtk_entry_set_text(GTK_ENTRY(inputbox), "");
-    
+
+#ifdef ENABLE_AUTOHIDE_INPUTBAR
+#ifdef ENABLE_GTK_PROGRESS_BAR
+    if(!gtk_progress_visible && !echo_active && !gtk_widget_has_focus(inputbox))
+        gtk_widget_hide(inputbox);
+#else
+    gtk_widget_hide(inputbox);
+#endif
+#endif 
     return TRUE;
 }
 
@@ -1058,6 +1084,9 @@ input(const Arg *arg) {
 
     /* to avoid things like :open URL :open URL2  or :open :open URL */
     clear_echo();
+#ifdef ENABLE_AUTOHIDE_INPUTBAR
+    gtk_widget_show(inputbox);
+#endif
     gtk_editable_insert_text(GTK_EDITABLE(inputbox), arg->s, -1, &pos);
     if (arg->i & InsertCurrentURL && (url = webkit_web_view_get_uri(webview)))
         gtk_editable_insert_text(GTK_EDITABLE(inputbox), url, -1, &pos);
@@ -1426,8 +1455,8 @@ set(const Arg *arg) {
             search_handle = NULL;
             webkit_web_view_unmark_text_matches(webview);
         }
-        clear_echo();
         gtk_widget_grab_focus(GTK_WIDGET(webview));
+        clear_echo();
         break;
     case ModePassThrough:
         a.s = g_strdup("-- PASS THROUGH --");
-- 
1.7.5.4

[Vimprobable-users] [PATCH 0/2] Vimprobable1 autohide inputbar when empty.

[Greg L. <gre...@gm...>]

Cleaned up some echo code and then made the inputbar hide automatically when empty. It is toggled on/off by a define in config.h.
Works correctly for both ENABLE_GTK_PROGRESS_BAR and not.

Greg Lutostanski (2):
  Refactor echo and clearing of inputbar to make it easier to follow.
  Allow autohiding of inputbar when empty.

 config.h |    1 +
 main.c   |  117 +++++++++++++++++++++++++++++++++++++++++--------------------
 2 files changed, 79 insertions(+), 39 deletions(-)

-- 
1.7.5.4

[Vimprobable-users] [PATCH] Don't modify the input bar if it's focused

[Hans-Peter D. <hpd...@gm...>]

Prevents echo() from setting the text of the input bar if it has the
focus (i.e. the user is currently typing something).
---
 main.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/main.c b/main.c
index 029ac7c..729ace4 100644
--- a/main.c
+++ b/main.c
@@ -1041,8 +1041,10 @@ echo(const Arg *arg) {
     if (index < Info || index > Error)
         return TRUE;
 
-    set_widget_font_and_color(inputbox, urlboxfont[index], urlboxbgcolor[index], urlboxcolor[index]);
-    gtk_entry_set_text(GTK_ENTRY(inputbox), !arg->s ? "" : arg->s);
+    if (!gtk_widget_is_focus(GTK_WIDGET(inputbox))) {
+        set_widget_font_and_color(inputbox, urlboxfont[index], urlboxbgcolor[index], urlboxcolor[index]);
+        gtk_entry_set_text(GTK_ENTRY(inputbox), !arg->s ? "" : arg->s);
+    }
 
     return TRUE;
 }
-- 
1.7.3.4

[Vimprobable-users] [Vimprobable1 PATCH] Fix crash when completing too many URLs

[Hans-Peter D. <hpd...@gm...>]

---
 main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/main.c b/main.c
index 6d6739a..e9aa497 100644
--- a/main.c
+++ b/main.c
@@ -893,7 +893,7 @@ complete(const Arg *arg) {
                 gtk_box_pack_start(_table, GTK_WIDGET(row_eventbox), FALSE, FALSE, 0);
                 widgets[n++] = row_eventbox;
                 elementpointer = elementpointer->next;
-                if (n >= MAX_LIST_SIZE)
+                if (n >= listlen)
                     break;
             }
             free_list(elementlist);
-- 
1.7.3.4

Re: [Vimprobable-users] [PATCH] Move apply_settings to webview_load_committed_cb.

[Hannes S. <ha...@yl...>]

Jason Ryan <jas...@gm...> wrote:
> On 17/04/12 at 08:56am, Hannes Sch__ller wrote:
> > This is quite a complex subject, so let me first describe thec
> > current behaviour of the patch.
> 
> > <snip />
> 
> > Opinions welcome!
> 
> FWIW: this level of complexity leaves me cold. It is not
> functionality that I would use and my only view is that I hope it
> does not impact negatively on the performance or ease of use of what
> is an excellent browser.

It's quite simple: If you don't define any site-specific overrides,
the overhead is one function call, one if and one return. This could be
further optimised to just one if. I don't think you will feel any
performance impact from this.

Hannes

Re: [Vimprobable-users] [PATCH] Move apply_settings to webview_load_committed_cb.

[Jason R. <jas...@gm...>]

On 17/04/12 at 08:56am, Hannes Schüller wrote:
> This is quite a complex subject, so let me first describe thec current
> behaviour of the patch.

> <snip />

> Opinions welcome!

FWIW: this level of complexity leaves me cold. It is not functionality that I
would use and my only view is that I hope it does not impact negatively on the
performance or ease of use of what is an excellent browser.

Cheers,

/J

-- 

http://jasonwryan.com/  [GnuPG Key: B1BD4E40]

Re: [Vimprobable-users] [PATCH] Move apply_settings to webview_load_committed_cb.

[Daniel C. <dan...@gm...>]

Hi!
Hannes Schüller <ha...@yl...> wrote:
> Shorthand definitions:
> - state S1: default settings (as defined at compile time plus rc file)
> - state S2: site-specific settings for site X as defined in rc file
> - setting T1: a custom setting manually set by the user at runtime
>   which is not covered by the difference between S1 and S2 (i.e. the
>   site specific settings don't change this)
> - setting T2: a custom setting manually set by the user at runtime
>   which is covered by the difference between S1 and S2 (i.e. the
>   site specific settings change this)
>
> Case A:
> - start with S1
> - go to X -> get S2
> - go to another site -> get S1 back
>
> Case B:
> - start with S1
> - set T1 -> S1+T1
> - go to X -> S2+T1
> - go to another site -> S1+T1
>
> Case C:
> - start with S1
> - set T2 -> S1+T2
> - go to X -> S2 (T2 overwritten)
> - go to another site -> S1+T2 (T2 restored)
>
> Case D:
> - start with S1
> - go to X -> S2
> - set T1 -> S2+T1
> - go to another site -> S1+T1 (T1 survives)
>
> Case E:
> - start with S1
> - go to X -> S2
> - set T2 -> S2+T2
> - go to another site -> S1 (T2 overridden with respective setting from
>   S1)
>
> So if we're talking about user expectations, the only case I believe we
> could have a problem is E. Do you agree so far?

Thank you for structuring the issue.

For now it's only the case E we have to deal with, but there is at least a
possible behaviour that requires also a rethinking about the other cases.

I see two way to deal with the per-site-settings:

Thoungh in paradigm of object orientation we have the possibility to use
runtime settings as an third object in hirarchie 1. or as changes on setting
objects 2.


   default settings                   default settings
          ^                                  ^
          |                                  |
          |                                  |
   per-site-settings                  per-site-settings
          ^
          |
          |
   runtime settings



1. Like in current state. That means (case E), runtime settings done by the
   user may be overwritten by respective settings from S1. But we should not
   apply the settings S2 multiple times when the user navigates only on pages
   of X. I think we should change the current behaviour case E1 into case E2.

   Case E1 (current behaviour):
   - start with S1
   - go to X -> S2
   - set T2 -> S2+T2
   - go to another page on X -> S2
   - go to another site -> S1

   Case E2:
   - start with S1
   - go to X -> S2
   - set T2 -> S2+T2
   - go to another page on X -> S2+T2
   - go to another site -> S1

2. The setting scopes are treated as something like browser sessions. That
   means we have default settings, and per-site-settings that inherits from
   the default settings (overwrites respective settings). All runtime settings
   would be arranged into the current used setting.

   Case B':
   - start with S1
   - set T1 -> S1+T1
   - go to X -> S2+T1
   - go to another site -> S1+T1
   
   Case C':
   - start with S1
   - set T2 -> S1+T2
   - go to X -> S2 (T2 overwritten)
   - go to another site -> S1
   
   Case D':
   - start with S1
   - go to X -> S2
   - set T1 -> S2+T1
   - go to another site -> S1+T1 (T1 survives)
   
   Case E':
   - start with S1
   - go to X -> S2
   - set T2 -> S2+T2
   - go to another site -> S1
   - go to X -> S2+T2 (T2 was changed for the current window for site X)

I can live with both ways, but 2. would be more intuitive for me to
understand.

Daniel