From blacklight86 at gmail.com Sun May 2 23:43:53 2010 From: blacklight86 at gmail.com (BlackLight) Date: Mon, 3 May 2010 01:43:53 +0200 Subject: [Vimprobable-users] Patch for toggling proxy usage Message-ID: A nice feature I had in Firefox was the TorButton, Proxy Switcher or any kind of stuff for toggling the status of the proxy. Actually I don't use a HTTP proxy for every daily WWW operation, so I want to keep it off and just turn it on for some purposes. But Vimprobable, reading the value of http_proxy environment variable at the beginning and never again, will leave the proxy on even if you've just to do a Google search, and this is quite annoying. For any of you who want to toggle the proxy settings while the browser is running, you can apply this tiny patch to your Vimprobable installation (tested on Vimprobable2 0.8.1.4): # # Enables Vimprobable to toggle the proxy status. Successfully tested on # Vimprobable 0.8.1.4. You should set your proxy URI in the http_proxy # environment variable. # # by BlackLight, , http://0x00.ath.cx # # ---> BEFORE APPLYING THE PATCH <--- # # You can never be safe enough in computing life. Before applying the patch, # make a copy of your main.c file, e.g. cp main.c main.orig.c, to be restored in # case something goes wrong. # # Add the following line at the beginning of your config.h file: # static gboolean use_proxy = FALSE; /* TRUE if you're going to use a proxy (whose address is specified in http_proxy environment variable), false otherwise */ # # Then the following line in the "keys" table: # { GDK_CONTROL_MASK, 0, GDK_p, toggle_proxy, {0} }, # # By default, doing so, you can toggle the status of your proxy by pressing C-p # Then, apply this patch by typing # patch -p1 < toggle_proxy.patch # # Good luck # --- main.orig.c 2010-05-02 13:01:57.000000000 +0200 +++ main.c 2010-05-02 13:56:10.000000000 +0200 @@ -57,6 +57,7 @@ static gboolean view_source(const Arg * arg); static gboolean zoom(const Arg *arg); static gboolean quickmark(const Arg *arg); +static gboolean toggle_proxy(const Arg *arg); static void update_url(const char *uri); static void setup_modkeys(void); @@ -1204,6 +1205,44 @@ } gboolean +toggle_proxy (const Arg *arg) { + SoupURI *proxy_uri; + Arg a; + char *filename, *new; + int len; + + if (use_proxy == TRUE) { + use_proxy = FALSE; + g_object_set(session, "proxy-uri", NULL); + a.i = Info; + a.s = "Proxy deactivated"; + echo(&a); + } else { + filename = (char *) g_getenv("http_proxy"); + + if (filename != NULL && 0 < (len = strlen(filename))) { + if (strstr(filename, "://") == NULL) { + /* prepend http:// */ + new = g_malloc(sizeof("http://") + len); + strcpy(new, "http://"); + memcpy(&new[sizeof("http://") - 1], filename, len + 1); + proxy_uri = soup_uri_new(new); + } else { + proxy_uri = soup_uri_new(filename); + } + + g_object_set(session, "proxy-uri", proxy_uri, NULL); + use_proxy = TRUE; + a.i = Info; + a.s = "Proxy activated"; + echo(&a); + } + } + + return use_proxy; +} + +gboolean script(const Arg *arg) { gchar *value = NULL, *message = NULL; Arg a; @@ -1923,18 +1962,25 @@ soup_session_add_feature(session, (SoupSessionFeature*)cookiejar); #endif /* proxy */ - filename = (char *)g_getenv("http_proxy"); - if (filename != NULL && 0 < (len = strlen(filename))) { - if (strstr(filename, "://") == NULL) { - /* prepend http:// */ - new = g_malloc(sizeof("http://") + len); - strcpy(new, "http://"); - memcpy(&new[sizeof("http://") - 1], filename, len + 1); - proxy_uri = soup_uri_new(new); - } else { - proxy_uri = soup_uri_new(filename); - } - g_object_set(session, "proxy-uri", proxy_uri, NULL); + + if (use_proxy == TRUE) { + filename = (char *)g_getenv("http_proxy"); + + if (filename != NULL && 0 < (len = strlen(filename))) { + if (strstr(filename, "://") == NULL) { + /* prepend http:// */ + new = g_malloc(sizeof("http://") + len); + strcpy(new, "http://"); + memcpy(&new[sizeof("http://") - 1], filename, len + 1); + proxy_uri = soup_uri_new(new); + } else { + proxy_uri = soup_uri_new(filename); + } + g_object_set(session, "proxy-uri", proxy_uri, NULL); + use_proxy = TRUE; + } else { + use_proxy = FALSE; + } } } -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: From blacklight86 at gmail.com Sun May 2 23:51:20 2010 From: blacklight86 at gmail.com (BlackLight) Date: Mon, 3 May 2010 01:51:20 +0200 Subject: [Vimprobable-users] GMail and Google stuff support Message-ID: I use mutt for everyday mail operations, but unfortunately now I'll be inside a universitary network still for some months, and here no connection to external SMTP servers is allowed. So, I have to use the ugly, bloated GMail web page in order to send emails. And here comes the problem. Vimprobable is a great browser, but there's no support at all for Google stuff. I know you hate Google, and you've got tons of good reasons for doing so, but unfortunately millions people out there use their products or, like in my case, are forced to, and they would like to use them from their favourite web browser (Vimprobable). So far this is not possible. Simply, you can't even fill GMail forms from Vimprobable2 0.8.1.4, you can't even log in your box, same if you try to log in to your iGoogle account. And when you access your GMail page by copy-pasting your account information inside the form, you find the "basical HTML interface" on, as you were using Lynx or W3M instead of a nice WebKit-based browser. Same issue if you try to browse maps.google.com. Will the support for Google pages ever be enabled? -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes at yllr.net Mon May 3 06:39:37 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 3 May 2010 08:39:37 +0200 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: References: Message-ID: <20100503063936.GA3756@laptop2> Hi! > Will the support for Google pages ever be enabled? Vimprobable supports any Google page there is. It's just that Google doesn't support Vimprobable. To elaborate: Many Google pages check the user agent string sent by the browser and based on that (and only that) decide whether a browser will "work" with their sites or not. This method of client identification checking was very common in the mid- to late 1990s. Since Vimprobable most likely falls in the group of "unknown", it is treated like the antiques. Workaround: set your user agent string to something Google recognises, like Firefox or Chrome. You can do this in config.h (in both Vimprobable versions) or with ":set useragent blah blah" (in Vimprobable2; without the colon if you want to set in permanently through the config file). Hannes From hannes at yllr.net Mon May 3 06:44:10 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Mon, 3 May 2010 08:44:10 +0200 Subject: [Vimprobable-users] Patch for toggling proxy usage In-Reply-To: References: Message-ID: <20100503064410.GB3756@laptop2> Hi! On Mon, May 03, 2010 at 01:43:53AM +0200, BlackLight wrote: > For any of you who want to toggle the proxy settings while the > browser is running, you can apply this tiny patch to your Vimprobable > installation (tested on Vimprobable2 0.8.1.4): I think this is a good feature which should be merged into the main branch. Two small issues: - Why use a hotkey and a dedicated function? Wouldn't it make more sense to run this through the :set command? Like :set proxy on / :set proxy off? - Could you make a patch with the changes of all files? Hannes From blacklight86 at gmail.com Mon May 3 09:22:27 2010 From: blacklight86 at gmail.com (BlackLight) Date: Mon, 3 May 2010 11:22:27 +0200 Subject: [Vimprobable-users] Patch for toggling proxy usage In-Reply-To: <20100503064410.GB3756@laptop2> References: <20100503064410.GB3756@laptop2> Message-ID: Hi - Why use a hotkey and a dedicated function? Wouldn't it make more sense > to run this through the :set command? Like :set proxy on / :set proxy > off? > In truth I tried to understand how the mechanism of :set command works, but without any success. I have not clear how I can trigger my function when a certain variable is :set-ed. > - Could you make a patch with the changes of all files? > Sure, I have not made a patch for config.h file but I just left the instructions because usually the config.h file is heavily modified by the user so the patch won't probably work. Anyway, here is the patch: # # Enables Vimprobable to toggle the proxy status. Successfully tested on # Vimprobable 0.8.1.4. You should set your proxy URI in the http_proxy # environment variable. # # by BlackLight, , http://0x00.ath.cx # # ---> BEFORE APPLYING THE PATCH <--- # # You can never be safe enough in computing life. Before applying the patch, # make a copy of your main.c file, e.g. cp main.c main.orig.c, to be restored in # case something goes wrong. # # Good luck # --- a/config.h 2010-05-03 11:15:13.000000000 +0200 +++ b/config.h 2010-05-03 11:15:39.000000000 +0200 @@ -9,6 +9,8 @@ char startpage[241] = "http://www.vimprobable.org/"; char useragent[120] = "Vimprobable2 0.8.1.4"; static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */ +static gboolean use_proxy = FALSE;/* TRUE if you're going to use a proxy (whose address + is specified in http_proxy environment variable), false otherwise */ /* appearance */ char statusbgcolor[] = "#000000"; /* background color for status bar */ @@ -169,6 +171,7 @@ { 0, GDK_g, GDK_i, focus_input,{} }, { 0, 0, GDK_d, quit, {0} }, + { GDK_CONTROL_MASK, 0, GDK_p, toggle_proxy, {0} }, }; /* command mapping */ --- a/main.c 2010-05-03 11:15:17.000000000 +0200 +++ b/main.c 2010-05-03 11:13:45.000000000 +0200 @@ -57,6 +57,8 @@ static gboolean view_source(const Arg * arg); static gboolean zoom(const Arg *arg); static gboolean quickmark(const Arg *arg); +static gboolean tab(const Arg *arg); +static gboolean toggle_proxy(const Arg *arg); static void update_url(const char *uri); static void setup_modkeys(void); @@ -1203,6 +1205,62 @@ else { return false; } } +gboolean +tab(const Arg *a) { + Arg aa; + + if(embed) + { + char buf[100]; + snprintf(buf, sizeof(buf), a->s, winid ); + + if(system(buf) == 0) + return true; + else + return false; + } + + return true; +} + +gboolean +toggle_proxy (const Arg *arg) { + SoupURI *proxy_uri; + Arg a; + char *filename, *new; + int len; + + if (use_proxy == TRUE) { + use_proxy = FALSE; + g_object_set(session, "proxy-uri", NULL); + a.i = Info; + a.s = "Proxy deactivated"; + echo(&a); + } else { + filename = (char *) g_getenv("http_proxy"); + + if (filename != NULL && 0 < (len = strlen(filename))) { + if (strstr(filename, "://") == NULL) { + /* prepend http:// */ + new = g_malloc(sizeof("http://") + len); + strcpy(new, "http://"); + memcpy(&new[sizeof("http://") - 1], filename, len + 1); + proxy_uri = soup_uri_new(new); + } else { + proxy_uri = soup_uri_new(filename); + } + + g_object_set(session, "proxy-uri", proxy_uri, NULL); + use_proxy = TRUE; + a.i = Info; + a.s = "Proxy activated"; + echo(&a); + } + } + + return use_proxy; +} + gboolean script(const Arg *arg) { gchar *value = NULL, *message = NULL; @@ -1923,18 +1981,25 @@ soup_session_add_feature(session, (SoupSessionFeature*)cookiejar); #endif /* proxy */ - filename = (char *)g_getenv("http_proxy"); - if (filename != NULL && 0 < (len = strlen(filename))) { - if (strstr(filename, "://") == NULL) { - /* prepend http:// */ - new = g_malloc(sizeof("http://") + len); - strcpy(new, "http://"); - memcpy(&new[sizeof("http://") - 1], filename, len + 1); - proxy_uri = soup_uri_new(new); - } else { - proxy_uri = soup_uri_new(filename); - } - g_object_set(session, "proxy-uri", proxy_uri, NULL); + + if (use_proxy == TRUE) { + filename = (char *)g_getenv("http_proxy"); + + if (filename != NULL && 0 < (len = strlen(filename))) { + if (strstr(filename, "://") == NULL) { + /* prepend http:// */ + new = g_malloc(sizeof("http://") + len); + strcpy(new, "http://"); + memcpy(&new[sizeof("http://") - 1], filename, len + 1); + proxy_uri = soup_uri_new(new); + } else { + proxy_uri = soup_uri_new(filename); + } + g_object_set(session, "proxy-uri", proxy_uri, NULL); + use_proxy = TRUE; + } else { + use_proxy = FALSE; + } } } -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: From blacklight86 at gmail.com Mon May 3 10:19:24 2010 From: blacklight86 at gmail.com (BlackLight) Date: Mon, 3 May 2010 12:19:24 +0200 Subject: [Vimprobable-users] Patch for toggling proxy usage In-Reply-To: References: <20100503064410.GB3756@laptop2> Message-ID: I'm sorry, I just posted the wrong patch, with my fully modified main.c file with other modifies applied...this should be the correct version: # # Enables Vimprobable to toggle the proxy status. Successfully tested on # Vimprobable 0.8.1.4. You should set your proxy URI in the http_proxy # environment variable. # # by BlackLight, , http://0x00.ath.cx # # ---> BEFORE APPLYING THE PATCH <--- # # You can never be safe enough in computing life. Before applying the patch, # make a copy of your main.c file, e.g. cp main.c main.orig.c, to be restored in # case something goes wrong. # # Good luck # --- a/config.h 2010-05-03 11:15:13.000000000 +0200 +++ b/config.h 2010-05-03 11:15:39.000000000 +0200 @@ -9,6 +9,8 @@ char startpage[241] = "http://www.vimprobable.org/"; char useragent[120] = "Vimprobable2 0.8.1.4"; static const gboolean enablePlugins = TRUE; /* TRUE keeps plugins enabled */ +static gboolean use_proxy = FALSE;/* TRUE if you're going to use a proxy (whose address + is specified in http_proxy environment variable), false otherwise */ /* appearance */ char statusbgcolor[] = "#000000"; /* background color for status bar */ @@ -169,6 +171,7 @@ { 0, GDK_g, GDK_i, focus_input,{} }, { 0, 0, GDK_d, quit, {0} }, + { GDK_CONTROL_MASK, 0, GDK_p, toggle_proxy, {0} }, }; /* command mapping */ --- a/main.c 2010-05-03 12:12:13.000000000 +0200 +++ b/main.c 2010-05-03 12:13:34.000000000 +0200 @@ -57,6 +57,7 @@ static gboolean view_source(const Arg * arg); static gboolean zoom(const Arg *arg); static gboolean quickmark(const Arg *arg); +static gboolean toggle_proxy(const Arg *arg); static void update_url(const char *uri); static void setup_modkeys(void); @@ -1204,6 +1205,44 @@ } gboolean +toggle_proxy (const Arg *arg) { + SoupURI *proxy_uri; + Arg a; + char *filename, *new; + int len; + + if (use_proxy == TRUE) { + use_proxy = FALSE; + g_object_set(session, "proxy-uri", NULL); + a.i = Info; + a.s = "Proxy deactivated"; + echo(&a); + } else { + filename = (char *) g_getenv("HTTP_PROXY"); + + if (filename != NULL && 0 < (len = strlen(filename))) { + if (strstr(filename, "://") == NULL) { + /* prepend http:// */ + new = g_malloc(sizeof("http://") + len); + strcpy(new, "http://"); + memcpy(&new[sizeof("http://") - 1], filename, len + 1); + proxy_uri = soup_uri_new(new); + } else { + proxy_uri = soup_uri_new(filename); + } + + g_object_set(session, "proxy-uri", proxy_uri, NULL); + use_proxy = TRUE; + a.i = Info; + a.s = "Proxy activated"; + echo(&a); + } + } + + return use_proxy; +} + +gboolean script(const Arg *arg) { gchar *value = NULL, *message = NULL; Arg a; @@ -1923,18 +1962,25 @@ soup_session_add_feature(session, (SoupSessionFeature*)cookiejar); #endif /* proxy */ - filename = (char *)g_getenv("http_proxy"); - if (filename != NULL && 0 < (len = strlen(filename))) { - if (strstr(filename, "://") == NULL) { - /* prepend http:// */ - new = g_malloc(sizeof("http://") + len); - strcpy(new, "http://"); - memcpy(&new[sizeof("http://") - 1], filename, len + 1); - proxy_uri = soup_uri_new(new); - } else { - proxy_uri = soup_uri_new(filename); - } - g_object_set(session, "proxy-uri", proxy_uri, NULL); + + if (use_proxy == TRUE) { + filename = (char *)g_getenv("HTTP_PROXY"); + + if (filename != NULL && 0 < (len = strlen(filename))) { + if (strstr(filename, "://") == NULL) { + /* prepend http:// */ + new = g_malloc(sizeof("http://") + len); + strcpy(new, "http://"); + memcpy(&new[sizeof("http://") - 1], filename, len + 1); + proxy_uri = soup_uri_new(new); + } else { + proxy_uri = soup_uri_new(filename); + } + g_object_set(session, "proxy-uri", proxy_uri, NULL); + use_proxy = TRUE; + } else { + use_proxy = FALSE; + } } } -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: toggle_proxy.patch Type: application/octet-stream Size: 4100 bytes Desc: not available URL: From blacklight86 at gmail.com Mon May 3 17:53:58 2010 From: blacklight86 at gmail.com (BlackLight) Date: Mon, 3 May 2010 19:53:58 +0200 Subject: [Vimprobable-users] Automatic external action for certain mimetypes Message-ID: Hi, I'm currently working on a patch for Vimprobable that allows to execute a certain external process when a certain mimetype is encountered. For example, acroread or apvlv are executed for opening an "application/pdf" content, or mplayer for "application/mpeg" or similar. Anyway, I have a doubt regarding the way Vimprobable manages the unknown mimetypes. I think the mimetype detection is managed in webview_mimetype_cb() function in the line if ( webkit_web_view_can_show_mime_type(webview, mime_type) == FALSE ) but doing like this nearly any mimetype is recognized as viewable, even application/pdf, application/mpeg, or whatever. I did this trick: if ( (webkit_web_view_can_show_mime_type(webview, mime_type) == FALSE) || (strstr(mime_type, "application/")) ) and actually I can correctly view text/* and image/* types inside the browser, while all application/* mimetypes are opened through an external application. Is this approach correct? Isn't there any cleaner way for managing through WebKit the actual mimetypes a browser can natively view? -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: From blacklight86 at gmail.com Mon May 3 22:50:33 2010 From: blacklight86 at gmail.com (BlackLight) Date: Tue, 4 May 2010 00:50:33 +0200 Subject: [Vimprobable-users] Automatic external action for certain mimetypes In-Reply-To: References: Message-ID: Released a patch that allows the management of not natively-supported mimetypes (application/pdf, application/msword, video/*, audio/*...) by specifying an external application to be executed when these files are met. Anyway I followed a "dirty approach", as I don't know how to actually manage natively supported mimetypes using just WebKit, so I roughly decided that any text/* or image/* content is natively viewable by the browser, while other mimetypes require an external application. # # This patch allows Vimprobable to execute external programs when it meets some # mimetypes it cannot natively manage (for example PDF files, video, audio, # office documents, and so on). You can configure the action you want to execute # for a certain mime type (for example associating application/pdf to acroread, # or video/* and audio/* to mplayer, and so on) editing your config.h. # # by BlackLight , http://0x00.ath.cx # --- a/vimprobable.h 2010-05-03 22:10:43.000000000 +0200 +++ b/vimprobable.h 2010-05-03 22:04:21.000000000 +0200 @@ -135,6 +135,11 @@ char *uri; } Searchengine; +typedef struct { + char *mime_type; + char *cmd; +} MimeTypeAction; + struct map_pair { char *line; char what[20]; --- a/config.h 2010-05-03 22:10:44.000000000 +0200 +++ b/config.h 2010-05-03 22:04:15.000000000 +0200 @@ -252,3 +252,12 @@ { "sslbgcolor", sslbgcolor, "", FALSE, FALSE, TRUE, TRUE }, { "sslcolor", sslcolor, "", FALSE, FALSE, TRUE, TRUE }, }; + +static MimeTypeAction actions[] = { + /* mime type, action (%u identifies the URI), example: */ + /* { "application/pdf", "acroread %u" }, */ + /* { "video/*" "gmplayer %u" */ + { "application/pdf", "acroread %u" }, + { "video/*", "gmplayer %u" }, + { "audio/*", "gmplayer %u" }, +}; --- a/main.c 2010-05-03 22:10:41.000000000 +0200 +++ b/main.c 2010-05-03 22:04:08.000000000 +0200 @@ -196,11 +196,67 @@ return TRUE; } +char* +get_mimetype_command (char *mime_type, WebKitNetworkRequest *request) { + int i, j, pos, cmdlen; + char *uri, *cmd = NULL; + gboolean matched_mimetype = FALSE; + + for (i=0; i < LENGTH(actions) && matched_mimetype == FALSE; i++) { + if (!strcmp(mime_type, actions[i].mime_type)) { + matched_mimetype = TRUE; + } else { + if (strstr(actions[i].mime_type, "/*")) { + pos = (int) strstr(actions[i].mime_type, "/*") - (int) actions[i].mime_type; + cmd = g_strdup(actions[i].mime_type); + cmd[pos+1] = 0; + + if (strstr(mime_type, cmd)) + matched_mimetype = TRUE; + + 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; + uri = (char*) webkit_network_request_get_uri(request); + + cmdlen = strlen(actions[i].cmd) + strlen(uri) + 3; + cmd = g_malloc(cmdlen); + memset (cmd, 0, cmdlen); + + strncpy (cmd, actions[i].cmd, pos); + strncpy (cmd+pos, uri, strlen(uri)); + strcat (cmd, actions[i].cmd + pos + 2); + } else { + cmd = g_strdup(actions[i].cmd); + } + } + } + + return cmd; +} + gboolean webview_mimetype_cb(WebKitWebView *webview, WebKitWebFrame *frame, WebKitNetworkRequest *request, char *mime_type, WebKitWebPolicyDecision *decision, gpointer user_data) { - if (webkit_web_view_can_show_mime_type(webview, mime_type) == FALSE) { - webkit_web_policy_decision_download(decision); + char *cmd = NULL; + + if ( (webkit_web_view_can_show_mime_type(webview, mime_type) == FALSE) || ( !strstr(mime_type, "text/") && !strstr(mime_type, "image/")) ) { + if ((cmd = get_mimetype_command(mime_type, request))) { + Arg a; + a.i = Info; + a.s = cmd; + echo(&a); + system (cmd); + g_free(cmd); + } else { + webkit_web_policy_decision_download(decision); + } + return TRUE; } else { return FALSE; -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes at yllr.net Tue May 4 07:12:29 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 4 May 2010 09:12:29 +0200 Subject: [Vimprobable-users] Automatic external action for certain mimetypes In-Reply-To: References: Message-ID: <20100504091229.5a084e6a@workstation> BlackLight wrote: > Released a patch that allows the management of not natively-supported > mimetypes (application/pdf, application/msword, video/*, audio/*...) > by specifying an external application to be executed when these files > are met. Anyway I followed a "dirty approach", as I don't know how to > actually manage natively supported mimetypes using just WebKit, so I > roughly decided that any text/* or image/* content is natively > viewable by the browser, while other mimetypes require an external > application. From the top of my head: what about application/xhtml+xml? That's the prefered way to server XHTML pages according to the W3C. I think it might be safer to first check if a custom action for a mime type is found (i.e. do a whitelist check without wildcards) and then decide. Hannes From blacklight86 at gmail.com Tue May 4 08:43:31 2010 From: blacklight86 at gmail.com (BlackLight) Date: Tue, 4 May 2010 10:43:31 +0200 Subject: [Vimprobable-users] Automatic external action for certain mimetypes In-Reply-To: <20100504091229.5a084e6a@workstation> References: <20100504091229.5a084e6a@workstation> Message-ID: You're right. I knew my approach was a bit rough but I was evaluating no alternative way, while the whitelist-like approach is the cleanest one in this case. I modified my patch. Now when it finds a certain mimetype first checks if a policy was associated to that type. If so it executes the external command, otherwise it leaves the default action. Check it out. # # This patch allows Vimprobable to execute external programs when it meets some # mimetypes it cannot natively manage (for example PDF files, video, audio, # office documents, and so on). You can configure the action you want to execute # for a certain mime type (for example associating application/pdf to acroread, # or video/* and audio/* to mplayer, and so on) editing your config.h. # # by BlackLight , http://0x00.ath.cx # --- a/vimprobable.h 2010-05-03 21:22:01.000000000 +0200 +++ b/vimprobable.h 2010-05-03 22:04:21.000000000 +0200 @@ -135,6 +135,11 @@ char *uri; } Searchengine; +typedef struct { + char *mime_type; + char *cmd; +} MimeTypeAction; + struct map_pair { char *line; char what[20]; --- a/config.h 2010-05-03 21:22:07.000000000 +0200 +++ b/config.h 2010-05-04 10:33:47.000000000 +0200 @@ -252,3 +252,9 @@ { "sslbgcolor", sslbgcolor, "", FALSE, FALSE, TRUE, TRUE }, { "sslcolor", sslcolor, "", FALSE, FALSE, TRUE, TRUE }, }; + +static MimeTypeAction actions[] = { + /* mime type, action (%u identifies the URI), example: */ + /* { "application/pdf", "acroread %u" }, */ + /* { "video/*" "gmplayer %u" */ +}; --- a/main.c 2010-05-03 21:21:52.000000000 +0200 +++ b/main.c 2010-05-04 10:33:20.000000000 +0200 @@ -196,9 +196,61 @@ return TRUE; } +char* +get_mimetype_command (char *mime_type, WebKitNetworkRequest *request) { + int i, j, pos, cmdlen; + char *uri, *cmd = NULL; + gboolean matched_mimetype = FALSE; + + for (i=0; i < LENGTH(actions) && matched_mimetype == FALSE; i++) { + if (!strcmp(mime_type, actions[i].mime_type)) { + matched_mimetype = TRUE; + } else { + if (strstr(actions[i].mime_type, "/*")) { + pos = (int) strstr(actions[i].mime_type, "/*") - (int) actions[i].mime_type; + cmd = g_strdup(actions[i].mime_type); + cmd[pos+1] = 0; + + if (strstr(mime_type, cmd)) + matched_mimetype = TRUE; + + 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; + uri = (char*) webkit_network_request_get_uri(request); + + cmdlen = strlen(actions[i].cmd) + strlen(uri) + 3; + cmd = g_malloc(cmdlen); + memset (cmd, 0, cmdlen); + + strncpy (cmd, actions[i].cmd, pos); + strncpy (cmd+pos, uri, strlen(uri)); + strcat (cmd, actions[i].cmd + pos + 2); + } else { + cmd = g_strdup(actions[i].cmd); + } + } + } + + return cmd; +} + gboolean webview_mimetype_cb(WebKitWebView *webview, WebKitWebFrame *frame, WebKitNetworkRequest *request, char *mime_type, WebKitWebPolicyDecision *decision, gpointer user_data) { + char *cmd = NULL; + + if ((cmd = get_mimetype_command(mime_type, request))) { + system (cmd); + g_free(cmd); + return FALSE; + } + if (webkit_web_view_can_show_mime_type(webview, mime_type) == FALSE) { webkit_web_policy_decision_download(decision); return TRUE; -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mime_exec.patch Type: application/octet-stream Size: 3205 bytes Desc: not available URL: From blacklight86 at gmail.com Tue May 4 14:32:49 2010 From: blacklight86 at gmail.com (BlackLight) Date: Tue, 4 May 2010 16:32:49 +0200 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: <20100503063936.GA3756@laptop2> References: <20100503063936.GA3756@laptop2> Message-ID: I knew about the user agent workaround. But the problem mainly happens with form fields. You can just try to fill a form for sending an email on mail.google.com, and you'll notice the form is not correctly recognized, the INSERT mode is not entered and any character you type is recognized as a command. The same happens (first thing that comes to my mind) if you try to fill the login form on www.poste.it, and I also noticed the same issue on other websites as well. I think it's probably related to JavaScript-ous forms not correctly recognized. And I don't think it's a WebKit issue, because I was able to fill those forms using other minimalistic WebKit-based browsers (surf and uzbl in primis). p.s. Oh yes, the same issue also happens if you try to share an external content on your Facebook profile and you want to fill the description field. Yesterday I was forced to write the text via cat <<'EOF' and paste it to that form for filling it. I think this issue usually happens with fully-bloated JavaScript-powered forms. Another similar issue happens when you try to enter follow hints mode on a page, I think, with lots of JavaScript-oriented links. For example, if you try to enter follow-hints mode on your Facebook page (but it's just an example, I experienced the same issue on at least 10 more pages) and you choose an hint to follow, you'll get a "TypeError: Result of expression 'a[e]' [null] is not an object", even if the link is valid. I remember I never got these errors with Vimperator and the same pages anyway. p.p.s. Oh, of course I experienced these bugs on Vimprobable2 0.8.1.4 -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes at yllr.net Tue May 4 14:41:24 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Tue, 4 May 2010 16:41:24 +0200 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: References: <20100503063936.GA3756@laptop2> Message-ID: <20100504164124.39417484@workstation> BlackLight wrote: > I knew about the user agent workaround. But the problem mainly > happens with form fields. You can just try to fill a form for sending > an email on mail.google.com, and you'll notice the form is not > correctly recognized, the INSERT mode is not entered and any > character you type is recognized as a command. Well, you should have said so in the first place instead of just asking "will it be supported"... I don't have accounts on any of the sites you mentioned specifically, but you mentioned "at least 10 more" where this occurs. I've never seen any of these issues. Maybe you can point me towards a site which produces them and which is accessible without registration? As a temporary workaround for the forms problem, you can simply activate PASS THROUGH mode (Ctrl+Z). Hannes From blacklight86 at gmail.com Wed May 5 17:25:15 2010 From: blacklight86 at gmail.com (BlackLight) Date: Wed, 5 May 2010 19:25:15 +0200 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: <20100504164124.39417484@workstation> References: <20100503063936.GA3756@laptop2> <20100504164124.39417484@workstation> Message-ID: Tried with PASS THROUGH mode and it doesn't work as well, it just looks like it cannot recognize the INSERT mode inside a form. Anyway I found many websites while browsing suffering this issue, but I did not keep track of them. Anyway, for sure most of Google forms have this problem (GMail forms, and I just discovered Google Docs forms have this problem as well), Facebook forms (the one for sharing contents and even just the form used for updating your status). I know Google and Facebook are the evil, but I must use them for job, and it's annoying to open Firefox just for writing an email through GMail, updating the shared Google doc for the development report or updating your own Facebook status. Ignoring for a moment any philosophical points of view on these portals, they're the two most used services on the web currently, luckily or unluckily, and they're poorly usable with Vimprobable. I noticed you can experience the same issue (INSERT mode not recognized on a form field) on the login form from www.poste.it, the website from which I access my bank account. Even if you don't have an account on this website, you can experience the issue just going there and trying to write something in the login form (btw, Vimperator, surf and conkeror work on that without any issue). And, just discovered, I have the same problem on RoundCube CMS forms. RoundCube is a very common, dynamic and AJAX-oriented CMS for managing webmail services, and it's getting more and more used. It's used, for example, for managing mail on autistici.org and in my university, webmail.itu.dk . If you try to compose a new message, you just can't fill the form, as the INSERT mode is not recognized. I hope these issues will be fixed in the next release (I think the not recognized INSERT mode is a bit more serious than the broken hint mode on same pages), because once fixed I would have no reason left to use Vimperator, even just for small things. -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes at yllr.net Wed May 5 17:56:20 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 5 May 2010 19:56:20 +0200 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: References: <20100503063936.GA3756@laptop2> <20100504164124.39417484@workstation> Message-ID: <20100505195620.79de90b6@workstation> Hi! BlackLight wrote: > Anyway I found many websites while browsing suffering this issue, but > I did not keep track of them. Anyway, for sure most of Google forms > have this problem (GMail forms, and I just discovered Google Docs > forms have this problem as well), Facebook forms (the one for sharing > contents and even just the form used for updating your status). I > know Google and Facebook are the evil, but I must use them for job, > and it's annoying to open Firefox just for writing an email through > GMail, updating the shared Google doc for the development report or > updating your own Facebook status. Ignoring for a moment any > philosophical points of view on these portals, they're the two most > used services on the web currently, luckily or unluckily, and they're > poorly usable with Vimprobable. You misunderstand; I'm not saying I'm not interested in getting those issues fixed. I'm saying I can't debug/fix them myself without examples. I'm perfectly willing to give anything I can access a try, but please understand that registering at /any/ site just to debug a browser (all the more: concerning an issue which doesn't even affect my own usage) whose code is open for anyone to study and improve is simply out of question. What do you expect? > I noticed you can experience the same issue (INSERT mode not > recognized on a form field) on the login form from www.poste.it, the > website from which I access my bank account. Even if you don't have > an account on this website, you can experience the issue just going > there and trying to write something in the login form > > Tried with PASS THROUGH mode and it doesn't work as well, it just > looks like it cannot recognize the INSERT mode inside a form. I tried PASS THROUGH on poste.it and it works fine for me. The problem with automatic INSERT mode as well as hinting to the login form is that it's located in an iframe. You can activate the frame via hinting (number 18 on that site for me) and hit tab once to get into the username field (then activate PASS THROUGH and type away). The browser doesn't evaluate the contents of embedded documents yet - only individual document trees. That part seems to work great on that site, too. I'm not claiming this is ideal. It seems to work as expected, though. > (btw, Vimperator, surf and conkeror work on that without > any issue). Vimperator does this "great" thing with its hinting where it overlays one hint with another. Jumping to the username field via hint is only possible by guessing the correct number (I found out it's 68). Surf and Conkeror aren't modal browsers, so I don't really see the relation. Uzbl has exactly the same issue as Vimprobable: Entering the username field will not instantly let me enter anything into it (the keystrokes are sent to the browser instead). It only works after manually activating INSERT mode there, too. So it doesn't really look as if anyone has actually solved the problem yet. > And, just discovered, I have the same problem on RoundCube CMS forms. > RoundCube is a very common, dynamic and AJAX-oriented CMS for managing > webmail services, and it's getting more and more used. It's used, for > example, for managing mail on autistici.org and in my university, > webmail.itu.dk . If you try to compose a new message, you just can't > fill the form, as the INSERT mode is not recognized. Again, same problem: I don't have an account with your university. Can you please check whether any of the things I mentioned above (frames, iframes etc.) are at work there? > I hope these issues will be fixed in the next release (I think the not > recognized INSERT mode is a bit more serious than the broken hint > mode on same pages), because once fixed I would have no reason left > to use Vimperator, even just for small things. I understand your frustration, but quite frankly, as I've never really stumbled on any of these issues myself, they're not too high on my personal list of priorities. Since you sent in an unrelated patch yourself, it's quite unlikely that the next commit will be about hinting within frames ;) Hannes From akosmin at reliantsec.net Wed May 5 18:17:57 2010 From: akosmin at reliantsec.net (Adam Kosmin) Date: Wed, 5 May 2010 14:17:57 -0400 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: References: <20100503063936.GA3756@laptop2> <20100504164124.39417484@workstation> Message-ID: <20100505181757.GE4799@windowsrefund.info> Words by BlackLight [Wed, May 05, 2010 at 07:25:15PM +0200]: >Tried with PASS THROUGH mode and it doesn't work as well, it just looks like >it cannot recognize the INSERT mode inside a form. Just chiming in to say that I've seen this behavior at times. One site in particular is: http://quotes.nasdaq.com/aspx/masterdataentry.aspx From hannes at yllr.net Wed May 5 18:28:34 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 5 May 2010 20:28:34 +0200 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: <20100505181757.GE4799@windowsrefund.info> References: <20100503063936.GA3756@laptop2> <20100504164124.39417484@workstation> <20100505181757.GE4799@windowsrefund.info> Message-ID: <20100505202834.5672b8bf@workstation> Adam Kosmin wrote: > Words by BlackLight [Wed, May 05, 2010 at 07:25:15PM +0200]: > >Tried with PASS THROUGH mode and it doesn't work as well, it just > >looks like it cannot recognize the INSERT mode inside a form. > > Just chiming in to say that I've seen this behavior at times. One site > in particular is: > > http://quotes.nasdaq.com/aspx/masterdataentry.aspx Thanks, Adam. Can't find any issues on that site, though. I see three input fiels there: the one on the top right (next to NASDAQ), one in the centre of the page ("Enter up to...") and the one in the orange area on the right. All three can be accessed via hinting, all have INSERT mode automatically activated through all regular methods of entering the input fields (hinting, clicking, gi). Maybe I'm still misunderstanding the issue you guys are talking about? Hannes From akosmin at reliantsec.net Wed May 5 18:36:07 2010 From: akosmin at reliantsec.net (Adam Kosmin) Date: Wed, 5 May 2010 14:36:07 -0400 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: <20100505202834.5672b8bf@workstation> References: <20100503063936.GA3756@laptop2> <20100504164124.39417484@workstation> <20100505181757.GE4799@windowsrefund.info> <20100505202834.5672b8bf@workstation> Message-ID: <20100505183607.GF4799@windowsrefund.info> >> http://quotes.nasdaq.com/aspx/masterdataentry.aspx > >Thanks, Adam. Can't find any issues on that site, though. I see three >input fiels there: the one on the top right (next to NASDAQ), one in >the centre of the page ("Enter up to...") and the one in the orange >area on the right. All three can be accessed via hinting, all have >INSERT mode automatically activated through all regular methods of >entering the input fields (hinting, clicking, gi). Maybe I'm still >misunderstanding the issue you guys are talking about? Thanks for taking a look. On occasion, I recall visiting the site and attempting to enter dvax into the largest field which usually has focus once the page has loaded. To my surprise, entering 'd' (in order to enter dvax), resulted in vimprobable closing :( So from memory, it seems that javascript worked (because the field had focus) and that for whatever reason, the browser was not in insert mode. Best, Adam > >Hannes >_______________________________________________ >Vimprobable-users mailing list >Vimprobable-users at vimprobable.org >http://vimprobable.org/mailman/listinfo/vimprobable-users -- "If the American people ever allow private banks to control the issue of their money, first by inflation and then by deflation, the banks and corporations that will grow up around them will deprive the people of their property until their children will wake up homeless on the continent their fathers conquered." --Thomas Jefferson Adam Kosmin GPG: http://windowsrefund.info/gpg From blacklight86 at gmail.com Wed May 5 18:37:56 2010 From: blacklight86 at gmail.com (BlackLight) Date: Wed, 5 May 2010 20:37:56 +0200 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: <20100505195620.79de90b6@workstation> References: <20100503063936.GA3756@laptop2> <20100504164124.39417484@workstation> <20100505195620.79de90b6@workstation> Message-ID: The PASS THROUGH mode entered that way (hint + tab + C-z) actually works fine on poste.it, even being a bit complex to do. I noticed it also works with RoundMail CMS and Facebook, and surprisingly even with Google Docs. Actually taking a quick look at the source code of these pages I noticed the issue was quite the same: an inner iframe for managing the form. Anyway many, many websites manage forms or other contents through iframes, so I don't really agree on the fact that this is a low-priority issue. This makes those websites poorly usable, as the PASS THROUGH keys combination to get it working is not so intuitive. Building recursively the hinting tree, including embedded objects and iframes, would be a nice solution (even if I haven't checked out that part of the code, and I don't know how hard it would be). It still doesn't work on GMail anyway. The issue here looks different. I have a message stating "use a fully supported browser to enjoy GMail at its best", even if I manually set a Chrome user agent (this is quite weird and stupid), and this forces me to use the basic plain HTML interface for the webmail. Once I want to send an email and fill the form, I see the browser actually enters INSERT mode (and I cannot switch to PASS THROUGH once in INSERT mode), but I cannot just type anything in those fields. And the source code of GMail web pages is quite a pain to debug and understand anyway, to catch the bug. p.s. A quite unrelated question just coming to my mind, about right click overriding. Just as example, I developed some time ago a tiny CMS for forums managements, you can see at http://0x00.ath.cx/forum/index.php . This CMS overrides the right click even to pop up a menu for navigating the page. It works on Firefox, Chrome, Opera and other browsers, even if on some installations you have to manually allow in your browser the right click overriding. It does not work with Vimprobable. I know by default disabling the right click override would be a wise choice, but probably it would be even wiser to allow the user to change this setting, as not only my CMS, but also some very AJAX-oriented pages around there use this feature. But I don't really know if this is an issue more related to Vimprobable or WebKit. -- -ONLY- email me using my PGP key # http://blacklight.altervista.org/key.txt Admin of # http://blacklight.gotdns.org | http://0x00.ath.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes at yllr.net Wed May 5 19:05:02 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 5 May 2010 21:05:02 +0200 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: References: <20100503063936.GA3756@laptop2> <20100504164124.39417484@workstation> <20100505195620.79de90b6@workstation> Message-ID: <20100505210502.69407b25@workstation> BlackLight wrote: > The PASS THROUGH mode entered that way (hint + tab + C-z) actually > works fine on poste.it, Good! > even being a bit complex to do. Agreed. > I noticed it > also works with RoundMail CMS and Facebook, and surprisingly even > with Google Docs. Actually taking a quick look at the source code of > these pages I noticed the issue was quite the same: an inner iframe > for managing the form. Ok, so we're finally getting closer to tracking the source of the problem down. > Anyway many, many websites manage forms or > other contents through iframes, so I don't really agree on the fact > that this is a low-priority issue. I said on my personal list. Everyone else is welcome to disagree. > Building recursively the hinting tree, including > embedded objects and iframes, would be a nice solution (even if I > haven't checked out that part of the code, and I don't know how hard > it would be). Problem is that due to Webkit limitations, this whole part has to be written in Javascript. Javascript is a horrible language (well, in my opinion anyway). What would need to be done is roughly this: - resolve the "inlined" documents (frames, iframes) - parse their DOM tree the same way it is done for the original document - add event listeners to the form elements which will activate INSERT mode (same as as for the original document) - display their hints if hinting is activated - let the hint firing function distinguish between the different DOM trees to decide which tree the selected hint belongs to and follow it (this could be done by remembering the first hint number used for each tree) If no big obstacles come up, this should be doable in a day of work or so. Though as we all know, things never go as smoothly as ideally imagined. > It still doesn't work on GMail anyway. The issue here looks > different. I have a message stating "use a fully supported browser to > enjoy GMail at its best", even if I manually set a Chrome user agent > (this is quite weird and stupid), and this forces me to use the basic > plain HTML interface for the webmail. Once I want to send an email > and fill the form, I see the browser actually enters INSERT mode (and > I cannot switch to PASS THROUGH once in INSERT mode), but I cannot > just type anything in those fields. And the source code of GMail web > pages is quite a pain to debug and understand anyway, to catch the > bug. No idea. Any other users who have this problem or know of a workaround (or maybe even the reason for this behaviour)? Eiwe, wasn't this the problem you had, too? > p.s. A quite unrelated question just coming to my mind, about right > click overriding. Just as example, I developed some time ago a tiny > CMS for forums managements, you can see at > http://0x00.ath.cx/forum/index.php . This CMS overrides the right > click even to pop up a menu for navigating the page. Eh? Working great here. If Javascript is enabled, right-clicking anywhere on the page opens what seems to be the main navigation. Hannes From hannes at yllr.net Wed May 5 19:09:50 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 5 May 2010 21:09:50 +0200 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: <20100505183607.GF4799@windowsrefund.info> References: <20100503063936.GA3756@laptop2> <20100504164124.39417484@workstation> <20100505181757.GE4799@windowsrefund.info> <20100505202834.5672b8bf@workstation> <20100505183607.GF4799@windowsrefund.info> Message-ID: <20100505210950.3e2c9c69@workstation> Adam Kosmin wrote: > >> http://quotes.nasdaq.com/aspx/masterdataentry.aspx > > > >Thanks, Adam. Can't find any issues on that site, though. I see three > >input fiels there: the one on the top right (next to NASDAQ), one in > >the centre of the page ("Enter up to...") and the one in the orange > >area on the right. All three can be accessed via hinting, all have > >INSERT mode automatically activated through all regular methods of > >entering the input fields (hinting, clicking, gi). Maybe I'm still > >misunderstanding the issue you guys are talking about? > > Thanks for taking a look. On occasion, I recall visiting the site and > attempting to enter dvax into the largest field which usually has > focus once the page has loaded. To my surprise, entering 'd' (in > order to enter dvax), resulted in vimprobable closing :( > > So from memory, it seems that javascript worked (because the field had > focus) and that for whatever reason, the browser was not in insert > mode. One problem which /could/ cause something like this to happen is that you're too fast. As I said in that other post, all this stuff is embedded Javascript, i.e. it can only be run after loading the complete page first. If you're pressing 'd' before the page has finished loading, the window will close, because INSERT hasn't been activated by the Javascript function yet. This is the same Webkit limitation I mentioned earlier; still no way to access the DOM tree without Javascript. Hannes From hannes at yllr.net Wed May 5 19:15:47 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 5 May 2010 21:15:47 +0200 Subject: [Vimprobable-users] gt/gT patch for better tabbed integration In-Reply-To: <20100421222503.GA8664@tuxpad.hsr.ch> References: <20100421222503.GA8664@tuxpad.hsr.ch> Message-ID: <20100505211547.06b28ab4@workstation> > Attached you will find a "quick&dirty" solution for a better > integration of vimprobable in tabbed. > > My target was to change between tabs with 'gt' and 'gT'. To achieve > this I call the "xdotool" which sends the needed keystrokes to tabbed. Ok, apparantely, there are no obviously superior solutions anyone can think of, so I'll merge this with the next update and add a note to the man page about this dependency. Thanks, Raphael! Hannes From akosmin at reliantsec.net Wed May 5 19:15:41 2010 From: akosmin at reliantsec.net (Adam Kosmin) Date: Wed, 5 May 2010 15:15:41 -0400 Subject: [Vimprobable-users] GMail and Google stuff support In-Reply-To: <20100505210950.3e2c9c69@workstation> References: <20100503063936.GA3756@laptop2> <20100504164124.39417484@workstation> <20100505181757.GE4799@windowsrefund.info> <20100505202834.5672b8bf@workstation> <20100505183607.GF4799@windowsrefund.info> <20100505210950.3e2c9c69@workstation> Message-ID: <20100505191541.GG4799@windowsrefund.info> Words by Hannes Sch?ller [Wed, May 05, 2010 at 09:09:50PM +0200]: > >One problem which /could/ cause something like this to happen is that >you're too fast. As I said in that other post, all this stuff is >embedded Javascript, i.e. it can only be run after loading the complete >page first. If you're pressing 'd' before the page has finished >loading, the window will close, because INSERT hasn't been activated >by the Javascript function yet. This is the same Webkit limitation I >mentioned earlier; still no way to access the DOM tree without >Javascript. I figured something along those lines. Thanks for the confirmation :) > >Hannes >_______________________________________________ >Vimprobable-users mailing list >Vimprobable-users at vimprobable.org >http://vimprobable.org/mailman/listinfo/vimprobable-users -- "If the American people ever allow private banks to control the issue of their money, first by inflation and then by deflation, the banks and corporations that will grow up around them will deprive the people of their property until their children will wake up homeless on the continent their fathers conquered." --Thomas Jefferson Adam Kosmin GPG: http://windowsrefund.info/gpg From thomas at xteddy.org Thu May 6 07:17:23 2010 From: thomas at xteddy.org (Thomas Adam) Date: Thu, 6 May 2010 08:17:23 +0100 Subject: [Vimprobable-users] gt/gT patch for better tabbed integration In-Reply-To: <20100505211547.06b28ab4@workstation> References: <20100421222503.GA8664@tuxpad.hsr.ch> <20100505211547.06b28ab4@workstation> Message-ID: 2010/5/5 Hannes Sch?ller : >> Attached you will find a "quick&dirty" solution for a better >> integration of vimprobable in tabbed. >> >> My target was to change between tabs with 'gt' and 'gT'. To achieve >> this I call the "xdotool" which sends the needed keystrokes to tabbed. > > Ok, apparantely, there are no obviously superior solutions anyone can > think of, so I'll merge this with the next update and add a note to the > man page about this dependency. Thanks, Raphael! There are better solutions, yes. It would be better to simply write a wrapper around XSendEvent() to send a synthetic KeyPress event through to a given application. That way, there's no silly dependency, and can all be done via config.h for example. -- Thomas Adam From hannes at yllr.net Thu May 6 07:48:02 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Thu, 6 May 2010 09:48:02 +0200 Subject: [Vimprobable-users] gt/gT patch for better tabbed integration In-Reply-To: References: <20100421222503.GA8664@tuxpad.hsr.ch> <20100505211547.06b28ab4@workstation> Message-ID: <20100506094802.173d8664@workstation> Thomas Adam wrote: > 2010/5/5 Hannes Sch?ller : > >> Attached you will find a "quick&dirty" solution for a better > >> integration of vimprobable in tabbed. > >> > >> My target was to change between tabs with 'gt' and 'gT'. To achieve > >> this I call the "xdotool" which sends the needed keystrokes to > >> tabbed. > > > > Ok, apparantely, there are no obviously superior solutions anyone > > can think of, so I'll merge this with the next update and add a > > note to the man page about this dependency. Thanks, Raphael! > > There are better solutions, yes. It would be better to simply write a > wrapper around XSendEvent() to send a synthetic KeyPress event through > to a given application. That way, there's no silly dependency, and > can all be done via config.h for example. Sounds good! Raphael, you want to give modifying your own patch a try? Hannes From thomas at xteddy.org Thu May 6 07:54:52 2010 From: thomas at xteddy.org (Thomas Adam) Date: Thu, 6 May 2010 08:54:52 +0100 Subject: [Vimprobable-users] gt/gT patch for better tabbed integration In-Reply-To: <20100506094802.173d8664@workstation> References: <20100421222503.GA8664@tuxpad.hsr.ch> <20100505211547.06b28ab4@workstation> <20100506094802.173d8664@workstation> Message-ID: 2010/5/6 Hannes Sch?ller : > Thomas Adam wrote: >> 2010/5/5 Hannes Sch?ller : >> >> Attached you will find a "quick&dirty" solution for a better >> >> integration of vimprobable in tabbed. >> >> >> >> My target was to change between tabs with 'gt' and 'gT'. To achieve >> >> this I call the "xdotool" which sends the needed keystrokes to >> >> tabbed. >> > >> > Ok, apparantely, there are no obviously superior solutions anyone >> > can think of, so I'll merge this with the next update and add a >> > note to the man page about this dependency. Thanks, Raphael! >> >> There are better solutions, yes. ?It would be better to simply write a >> wrapper around XSendEvent() to send a synthetic KeyPress event through >> to a given application. ?That way, there's no silly dependency, and >> can all be done via config.h for example. > > Sounds good! Raphael, you want to give modifying your own patch a try? If not, I can do it -- but I don't have the patch to hand. -- Thomas Adam From hannes at yllr.net Thu May 6 07:56:34 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Thu, 6 May 2010 09:56:34 +0200 Subject: [Vimprobable-users] gt/gT patch for better tabbed integration In-Reply-To: References: <20100421222503.GA8664@tuxpad.hsr.ch> <20100505211547.06b28ab4@workstation> <20100506094802.173d8664@workstation> Message-ID: <20100506095634.17a3a404@workstation> Thomas Adam wrote: > 2010/5/6 Hannes Sch?ller : > > Thomas Adam wrote: > >> 2010/5/5 Hannes Sch?ller : > >> >> Attached you will find a "quick&dirty" solution for a better > >> >> integration of vimprobable in tabbed. > >> >> > >> >> My target was to change between tabs with 'gt' and 'gT'. To > >> >> achieve this I call the "xdotool" which sends the needed > >> >> keystrokes to tabbed. > >> > > >> > Ok, apparantely, there are no obviously superior solutions anyone > >> > can think of, so I'll merge this with the next update and add a > >> > note to the man page about this dependency. Thanks, Raphael! > >> > >> There are better solutions, yes. ?It would be better to simply > >> write a wrapper around XSendEvent() to send a synthetic KeyPress > >> event through to a given application. ?That way, there's no silly > >> dependency, and can all be done via config.h for example. > > > > Sounds good! Raphael, you want to give modifying your own patch a > > try? > > If not, I can do it -- but I don't have the patch to hand. It's been posted in the first mail of this thread: http://vimprobable.org/pipermail/vimprobable-users/2010-April/000006.html Hannes From rnestler at hsr.ch Fri May 7 12:37:23 2010 From: rnestler at hsr.ch (Raphael Nestler) Date: Fri, 7 May 2010 14:37:23 +0200 Subject: [Vimprobable-users] gt/gT patch for better tabbed integration In-Reply-To: <20100506094802.173d8664@workstation> References: <20100421222503.GA8664@tuxpad.hsr.ch> <20100505211547.06b28ab4@workstation> <20100506094802.173d8664@workstation> Message-ID: <20100507123723.GA5406@tuxpad.hsr.ch> On Thu, May 06, 2010 at 09:48:02AM +0200, Hannes Sch?ller wrote: > Thomas Adam wrote: > > 2010/5/5 Hannes Sch?ller : > > >> Attached you will find a "quick&dirty" solution for a better > > >> integration of vimprobable in tabbed. > > >> > > >> My target was to change between tabs with 'gt' and 'gT'. To achieve > > >> this I call the "xdotool" which sends the needed keystrokes to > > >> tabbed. > > > > > > Ok, apparantely, there are no obviously superior solutions anyone > > > can think of, so I'll merge this with the next update and add a > > > note to the man page about this dependency. Thanks, Raphael! > > > > There are better solutions, yes. It would be better to simply write a > > wrapper around XSendEvent() to send a synthetic KeyPress event through > > to a given application. That way, there's no silly dependency, and > > can all be done via config.h for example. > > Sounds good! Raphael, you want to give modifying your own patch a try? > I'll give it a try, doesn't seem to be too difficult. Raphael From hannes at yllr.net Sat May 15 18:46:25 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 15 May 2010 20:46:25 +0200 Subject: [Vimprobable-users] Tarballs In-Reply-To: <20100415195020.77e24f12@workstation> References: <20100414171342.GD767@windowsrefund.info> <20100415083404.GC21598@laptop2> <20100415154829.GA4808@windowsrefund.info> <20100415195020.77e24f12@workstation> Message-ID: <20100515184625.GA3517@laptop2> > > Would it be possible to publish tarballs? I often find myself on > > machines where the git binary does not support -b > > Hmm... Eiwe, do you think you could set up a cron job on the webserver > which exports each branch into some static tarball each night or so? Automated snapshots (updated daily) are now linked from the website. Hannes From thomas at xteddy.org Sat May 15 19:38:15 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 15 May 2010 20:38:15 +0100 Subject: [Vimprobable-users] gt/gT patch for better tabbed integration In-Reply-To: <20100507123723.GA5406@tuxpad.hsr.ch> References: <20100421222503.GA8664@tuxpad.hsr.ch> <20100505211547.06b28ab4@workstation> <20100506094802.173d8664@workstation> <20100507123723.GA5406@tuxpad.hsr.ch> Message-ID: <20100515193813.GA3012@shuttle.home> On Fri, May 07, 2010 at 02:37:23PM +0200, Raphael Nestler wrote: > On Thu, May 06, 2010 at 09:48:02AM +0200, Hannes Sch?ller wrote: > > Thomas Adam wrote: > > > 2010/5/5 Hannes Sch?ller : > > > >> Attached you will find a "quick&dirty" solution for a better > > > >> integration of vimprobable in tabbed. > > > >> > > > >> My target was to change between tabs with 'gt' and 'gT'. To achieve > > > >> this I call the "xdotool" which sends the needed keystrokes to > > > >> tabbed. > > > > > > > > Ok, apparantely, there are no obviously superior solutions anyone > > > > can think of, so I'll merge this with the next update and add a > > > > note to the man page about this dependency. Thanks, Raphael! > > > > > > There are better solutions, yes. It would be better to simply write a > > > wrapper around XSendEvent() to send a synthetic KeyPress event through > > > to a given application. That way, there's no silly dependency, and > > > can all be done via config.h for example. > > > > Sounds good! Raphael, you want to give modifying your own patch a try? > > > I'll give it a try, doesn't seem to be too difficult. How you getting on with this? Do you need any help? -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.