vimprobable-users Mailing List for Vimprobable (Page 29)
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
Menu
▾
▴
vimprobable-users — Mailing list for Vimprobable users
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(77) |
Sep
(44) |
Oct
(43) |
Nov
(38) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(40) |
Feb
(18) |
Mar
(12) |
Apr
(25) |
May
(12) |
Jun
(13) |
Jul
(17) |
Aug
(3) |
Sep
(20) |
Oct
(42) |
Nov
(9) |
Dec
(2) |
| 2013 |
Jan
(9) |
Feb
(29) |
Mar
(9) |
Apr
(7) |
May
(38) |
Jun
|
Jul
(7) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(11) |
Dec
(1) |
| 2014 |
Jan
(16) |
Feb
(18) |
Mar
(11) |
Apr
(5) |
May
(13) |
Jun
(5) |
Jul
(5) |
Aug
(7) |
Sep
(30) |
Oct
|
Nov
|
Dec
(26) |
| 2015 |
Jan
(5) |
Feb
(19) |
Mar
(8) |
Apr
(15) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
(10) |
| 2016 |
Jan
|
Feb
(1) |
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Daniel C. <dan...@gm...> - 2011-09-03 08:56:05
|
Hi! > Certain websites lag A LOT on Vimprobable. One example is > creativecommons.org. I've tested this with UZBL, Surf, and Chromium: the > first two share this problem, but the last does not. > > I tried disabling java, javascript, and plugins as a hail mary, but it > didn't make a dent. > > This is the only thing that keeps me going back to Chromium with Vimium... I have no chromium here, but surfing on named pages seem's to be as fast as on other pages. What takes the time, loading th html or to view it in the browser? Maybe Chromium uses a better caching, precaching and for this page better value for max piplining requests. I don't think that the bad performance lay in the vimprobable itself, but in the webkit engine, but I'm not sure. Daniel |
|
From: Hannes S. <ha...@yl...> - 2011-09-03 08:18:49
|
Hi! niemand nobody <nie...@gm...> wrote: > Is there any particular reason why the link hinting uses numbers > instead of letters? Personally, I prefer Vimium's link hinting, which > uses common letters like "asdfghjkl" that my fingers are already > resting on, as this is a smidge more convenient than "123456780". Yes, there is a very particular (good) reason. That being that there are many people (me included) who don't just enter a hint's number, but type part of the link text to activate it. A feature which these less advanced hinting functions of other browsers don't seem to allow at all (making them unusable). Hannes |
|
From: niemand n. <nie...@gm...> - 2011-09-03 03:22:50
|
Again, this was sent to the old list. Sorry! -N ---------- Forwarded message ---------- From: niemand nobody <nie...@gm...> Date: Fri, Sep 2, 2011 at 8:14 PM Subject: Link hinting To: Vim...@vi... Hi, Is there any particular reason why the link hinting uses numbers instead of letters? Personally, I prefer Vimium's link hinting, which uses common letters like "asdfghjkl" that my fingers are already resting on, as this is a smidge more convenient than "123456780". While on the matter of link hinting: I've noticed that hints for links that extend into a new line will show up at the start of the line that the link begins. This seems a bit unintuitive, and certainly a bit confusing when there is also a link at the beginning of that first line. I've noticed that other link hinting instead puts the hints of multi-line links simply at the start of the link (e.g. the way Vimium does it). Is there any reason why we wouldn't want to do it that way, too? If there isn't, I just might be able to figure out the hinting code enough to patch it myself! Thanks, niemand |
|
From: niemand n. <nie...@gm...> - 2011-09-03 03:22:06
|
Ayayay, apparently we use a different mailing list these days! Living in cave has it's disadvantages, apparently... -N ---------- Forwarded message ---------- From: niemand nobody <nie...@gm...> Date: Fri, Sep 2, 2011 at 7:58 PM Subject: Some sites reeeeeally slow on Vimprobable To: Vim...@vi... Hi there, Certain websites lag A LOT on Vimprobable. One example is creativecommons.org. I've tested this with UZBL, Surf, and Chromium: the first two share this problem, but the last does not. I tried disabling java, javascript, and plugins as a hail mary, but it didn't make a dent. This is the only thing that keeps me going back to Chromium with Vimium... Thanks! niemand |
|
From: Daniel C. <dan...@gm...> - 2011-08-30 21:52:08
|
Hi! I mentioned hat vimprobable crashes if I try to open a previous visited page that's URL is longer than MAXTAGSIZE (200). This is a possible patch to prevent the crash. The second patch removes some compiler warnings about g_strdup_printf() without format specifiers. I'm not sure if I made it right or if I misunderstood the code. Daniel |
|
From: Hannes S. <ha...@yl...> - 2011-08-29 16:00:01
|
I believe I may have found another bug (just in time *after* the public release): - Go to a site with *many* links. For demonstration purposes, let's take http://www.imdb.com/title/tt0064904/ - Scroll down so that the "Message Boards" heading is on top of the window. - Activate hinting by pressing "f". - Notice that the message board topics are hinted, but using numbers in the 40s instead of starting with 1. All the links on the bottom of the page ("Explore more") are not hinted at all. A strange hint appears in the upper left corner of the window (47 for me). Hannes |
|
From: Hannes S. <ha...@yl...> - 2011-08-28 16:04:22
|
Hi, as discussed recently, here is another intermediate pre-1.0 release. The main change is the revamped hinting feature by Daniel Carl - now supporting even frames! Apart from that, we've got a few bugfixes and minor enhancements: - feedback for text yanking (Daniel Carl) - man page corrections (Jason Ryan) - scrollbar fixes (Daniel Carl) - respecting XDG_CONFIG_HOME environment variable (Raphael Nestler; ticket #3) - memory leak fix in quickmark function (Tilman Sauerbeck) Some other proposed changes (read: mine) now need to be adapted to the new hinting scheme. So please be patient a little while longer. Hannes |
|
From: Hannes S. <ha...@yl...> - 2011-08-28 14:58:22
|
Applied |
|
From: Hannes S. <ha...@yl...> - 2011-08-28 14:57:56
|
Applied |
|
From: Hannes S. <ha...@yl...> - 2011-08-28 14:57:44
|
Applied |
|
From: Hannes S. <ha...@yl...> - 2011-08-28 14:57:22
|
As much as I try, I cannot reproduce this. If it's still valid, please enter it into the bug tracker so that I don't forget to investigate this further. Hannes |
|
From: Hannes S. <ha...@yl...> - 2011-08-28 14:22:59
|
Applied, thanks again! Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-08-27 16:19:44
|
Hi Hannes! On Sat, Aug 27, 2011 at 03:47:49PM +0200, Hannes Schüller wrote: > this seems to be very solid now. Since this is a rather large change, > however, I'd say I make a new release now with just this plus a few > pure bugfixes, saving the other feature changes already posted for > later. That way, this can get a little more testing. Agreed? Yes, I think it should be released to be tested. And I belive it could make some things easier to be implemented if it's released. Maybe we could do some refacturing to the c part too. The main.c is horrible long and could be split into pieces, the global varibales could be replaces by structs and some of hte methods could be split into smaller ones. I suppose it's a big issue to make the code more readable and solid to easily fix bugs and implement fetaures. But I know it't wouldn't be easy to not loose the plot by many patches sent over mailinglist that aren't available in an upstream repository. Maybe we should think about dedicated feature/refacture branches that are more up-to-date than the current master. Daniel |
|
From: Hannes S. <ha...@yl...> - 2011-08-27 13:48:08
|
Hi, this seems to be very solid now. Since this is a rather large change, however, I'd say I make a new release now with just this plus a few pure bugfixes, saving the other feature changes already posted for later. That way, this can get a little more testing. Agreed? Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-08-25 22:20:40
|
Hi! On Thu, Aug 25, 2011 at 10:24:24PM +0200, Daniel Carl wrote: > Hi! > > I found a little bug. If I use hinting on a page with only one link, the link > is immediately opened like expected, but keeps in hintMode (. or , appear in > input box). > > In the main.c file in input() function following lines seems to cause the > behavior by inserting the last input content (arg->s) into the inputbox: > > /* to avoid things like :open URL :open URL2 or :open :open URL */ > gtk_entry_set_text(GTK_ENTRY(inputbox), ""); > 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); > gtk_widget_grab_focus(inputbox); > gtk_editable_set_position(GTK_EDITABLE(inputbox), -1); > > How can we avoid that vimprobable keeps in hintmode even if the only hint was > successfully fired and the mode where set to NormalMode? I found a solution, but I'm not sure if it doesn't insert another bug. To move mentioned lines before the hint script is executed solves the bug. This solves also the bug, that hints aren't create if url was opened and is still present in inputbox (:open url). If 'f' or 'F' is pressed when the url is still in inputbox, the hints where not created and I have to press ESC and start hinting again. Both bugs appear also in current HEAD revision of vimprobable2. Attached patch was done on top of the hinting-refacture. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-25 20:24:53
|
Hi!
I found a little bug. If I use hinting on a page with only one link, the link
is immediately opened like expected, but keeps in hintMode (. or , appear in
input box).
In the main.c file in input() function following lines seems to cause the
behavior by inserting the last input content (arg->s) into the inputbox:
/* to avoid things like :open URL :open URL2 or :open :open URL */
gtk_entry_set_text(GTK_ENTRY(inputbox), "");
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);
gtk_widget_grab_focus(inputbox);
gtk_editable_set_position(GTK_EDITABLE(inputbox), -1);
How can we avoid that vimprobable keeps in hintmode even if the only hint was
successfully fired and the mode where set to NormalMode?
A possibility to avoid this behavior is to not fire a single hint, but this
makes browsing a little slower.
Daniel
|
|
From: Hannes S. <ha...@yl...> - 2011-08-25 08:21:14
|
Daniel Carl <dan...@gm...> wrote: > On Wed, Aug 24, 2011 at 11:13:02PM +0200, Hannes Schüller wrote: > > I'd say the problem is a difference in the Webkit versions. 100000 > > still works for me, 1000000 doesn't. So I'd say we use something > > like 100000 for reasons of compatibility. > Thank you for inspecting the issue. Can you make the patch with al > lower value? > I'm wondering that 10000000 doesn't work. > In http://www.puidokas.com/max-z-index/ mentioned restriction are > higher than our current value. But on most serious pages also a > z-index of 100000 should fit our needs. Thanks! I'd say it's just a bug in Webkit, but you're right - the lower value should be no issue for any practical purposes. Back to testing now. Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-08-25 06:25:19
|
Hi Hannes! On Wed, Aug 24, 2011 at 11:13:02PM +0200, Hannes Schüller wrote: > I'd say the problem is a difference in the Webkit versions. 100000 > still works for me, 1000000 doesn't. So I'd say we use something like > 100000 for reasons of compatibility. Thank you for inspecting the issue. Can you make the patch with al lower value? I'm wondering that 10000000 doesn't work. In http://www.puidokas.com/max-z-index/ mentioned restriction are higher than our current value. But on most serious pages also a z-index of 100000 should fit our needs. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-24 21:40:59
|
Hi! Hope there will be an end of the patches. Removed unneeded retreiving of the textual content of hintet element. Daniel |
|
From: Hannes S. <ha...@yl...> - 2011-08-24 21:13:19
|
Hi! Daniel Carl <dan...@gm...> wrote: > Can you try to find the reason for this missbehavior, I couldn't > reproduce it here. Maybe you can try to change the z-index, remove > userdefined configuration or get into the issue by inspecting hints > and hintet elements via webinspector. I think I've got it pinned down. You set z-index to 10000000. This does not seem to work. In fact, it is stripped out completely: The hints have no z-index attribute at all! Lowering this value to 1000, for example, makes it work again. I'd say the problem is a difference in the Webkit versions. 100000 still works for me, 1000000 doesn't. So I'd say we use something like 100000 for reasons of compatibility. Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-08-24 20:50:05
|
Hi Hannes! Can you try to find the reason for this missbehavior, I couldn't reproduce it here. Maybe you can try to change the z-index, remove userdefined configuration or get into the issue by inspecting hints and hintet elements via webinspector. Daniel |
|
From: Hannes S. <ha...@yl...> - 2011-08-24 20:39:15
|
Daniel Carl <dan...@gm...> wrote: > Please can you check if there's a diff between your hinting.js and my > attached version? The files are exactly identical. Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-08-24 20:25:15
|
Hi Hannes! On Wed, Aug 24, 2011 at 06:25:38PM +0200, Hannes Schüller wrote: > > Have you applied all patches? For me it seems to work. I will test it > > later for previous versions too. > > Yes, patches 1 to 32. I've apllyed all patches from mailbox too on commit 1d44c153d91a15b854d6967c906b2f3259ab795a "description sync" of upstream repository. I got a single warning about whitespace error, but all patches apply well. Also the hints looks right on described page http://www.goodolddays.net/forum/forum.php?id=4. I can't find critical structures in the pages html and css. At the moment I have no idea where to look for the overlayed hints. Please can you check if there's a diff between your hinting.js and my attached version? Daniel |
|
From: Hannes S. <ha...@yl...> - 2011-08-24 16:25:52
|
Daniel Carl <dan...@gm...> wrote: > On Wed, Aug 24, 2011 at 05:00:16PM +0200, Hannes Schüller wrote: > > I've been having one minor issue: On some sites, the hints appear > > behind the hinted element (making them unusable). This includes > > sites which worked before, like for example this one: > > http://www.goodolddays.net/forum/forum.php?id=4 (check the "New > > Topic" and "New Poll" buttons). > > Have you applied all patches? For me it seems to work. I will test it > later for previous versions too. Yes, patches 1 to 32. Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-08-24 15:48:20
|
Hi Hannes! On Wed, Aug 24, 2011 at 05:00:16PM +0200, Hannes Schüller wrote: > I've been having one minor issue: On some sites, the hints appear > behind the hinted element (making them unusable). This includes sites > which worked before, like for example this one: > http://www.goodolddays.net/forum/forum.php?id=4 (check the "New Topic" > and "New Poll" buttons). Have you applied all patches? For me it seems to work. I will test it later for previous versions too. Daniel |
2 messages has been excluded from this view by a project administrator.
