vimprobable-users Mailing List for Vimprobable (Page 30)
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: Hannes S. <ha...@yl...> - 2011-08-24 15:00:37
|
Hi, 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). Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-08-24 14:53:02
|
Hi! The hinting added hints for ankors without href attributes. This behavior is removed in attached patch. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-24 00:33:25
|
Hi!
I added a config object to the hinting.js to configure the behavior and look
of the hints and to clean the code from style settings.
If someone wants hints like pentadactyl generates could use following config
in the hinting.js.
...
hintCss: "z-index:10000000;font-family:monospace;font-size:9px;"
+ "font-weight:bold;color:black;background-color:white;"
+ "padding:0px 1px;position:absolute;opacity:0.8;border:1px solid #444;",
...
Daniel
|
|
From: Daniel C. <dan...@gm...> - 2011-08-23 19:16:35
|
Hi! On Tue, Aug 23, 2011 at 11:01:36AM +0200, Hannes Schüller wrote: > - Since lowercase "f" now also respects a link's target attribute, > target="_blank" is handled as well. This conforms to the HTML Following patch removes target="_blank" from links that should be opened into the current window. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-23 19:01:22
|
Hi! I have found out a missbehavior of hinting on some pages that uses JavaScripts that overwrites the Array constructor. On this pages for(e in foo) doesn't work as expected. This patch replaces this kind of for loops by more traditional way of iterating over the arrays. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-23 15:45:45
|
Hi Hannes! On Tue, Aug 23, 2011 at 11:01:36AM +0200, Hannes Schüller wrote: > I've still got an offset of six lines > in main.c when applying the patches (starting with patch 1) though. Are > you sure you don't have any other changes in your branch? This didn't > prevent me from applying the patches, but it might hint at some change > being missed in the series. I'm not sure. I got one warning about a whitespace clash during I made the patchfiles. I don't want to post again such a large number of patches. The branch on github should work - I've spent some time to rollback the github repositorie's master branch to the vimprobable2 upstream HEAD and rebased all branches on it. If needed I can post it here, but I promise it's nought there. > - Since lowercase "f" now also respects a link's target attribute, > target="_blank" is handled as well. This conforms to the HTML > specification, I guess, but I somehow liked to be able to ignore this > nonsense of opening links in a new window. Opinions? I agree that 'f' should force to load the link into the current window. For links that have the target _blank set as real attribute we can remove it before firering it - it would be easy to implement. But there are a number of pages that simulate the setting of the target attribute via an eventobserver or a JavaScript function to set the target on thy fly. I disbelieve that we would be able to open these links into the current window. > - This logic relocation clashes with this URI handler patch: > http://www.vimprobable.org/mailman/archives/vimprobable-users/2011-June/000781.html . > Not necessarily a showstopper, needs to be kept in mind, though. Thank you for the hint, I'll have a look at the patch and try to adapt the hinting to work together with it. Daniel |
|
From: Raphael N. <rne...@hs...> - 2011-08-23 12:02:22
|
On Sat, Aug 20, 2011 at 07:35:47PM +0200, Hannes Schüller wrote: > Hi! > > Raphael Nestler <rne...@hs...> wrote: > > Here is a patch to let vimprobable use the XDG environment variable > > XDG_CONFIG_HOME to find its configuration files. > > It's implemented with a global variable config_base which is set at > > startup to either $XDG_CONFIG_HOME or the standard path ~/.config/ > > This looks like a resolution of ticket #3 > (http://sourceforge.net/apps/trac/vimprobable/ticket/3) :) > Yes I've seen this ticket and thought that it doesn't take too much time to implement it :) Raphael |
|
From: Hannes S. <ha...@yl...> - 2011-08-23 09:01:56
|
Hi! Daniel Carl <dan...@gm...> wrote: > On Sat, Aug 20, 2011 at 08:03:47PM +0200, Hannes Schüller wrote: > > after applying all patches in succession, hints don't appear in this > > version at all anymore. Also, there is now a tremendous amount of > > history in these patch series. I think it might be time to create a > > new, clean patch series to begin systematic issue tracking? > > I think I've startet refacturing on the wrong branch. Maybe this was > the reason, that the patches didn't apply on top of eachother. I've > rebased the branch to top of vimprobable2 and made all patches again. > Hope they will work. Thanks, this seems to work! I'm giving it a stress test right now, but the first glance looks very good. I've still got an offset of six lines in main.c when applying the patches (starting with patch 1) though. Are you sure you don't have any other changes in your branch? This didn't prevent me from applying the patches, but it might hint at some change being missed in the series. First impressions: - Since lowercase "f" now also respects a link's target attribute, target="_blank" is handled as well. This conforms to the HTML specification, I guess, but I somehow liked to be able to ignore this nonsense of opening links in a new window. Opinions? - This logic relocation clashes with this URI handler patch: http://www.vimprobable.org/mailman/archives/vimprobable-users/2011-June/000781.html . Not necessarily a showstopper, needs to be kept in mind, though. Hannes |
|
From: Matto F. <ma...@ma...> - 2011-08-21 15:48:14
|
Hi, On Sun, Aug 21, 2011 at 01:57:52PM +0200, Daniel Carl wrote: > On Sat, Aug 20, 2011 at 09:19:33PM +0200, Hannes Schüller wrote: > > The current patch applies against keymap.h which only exists in > > Vimprobable2. For Vimprobable1, this might be useful, though. Any other > > opinions? > The feature is pretty nice, and I would use it. I have not thought about bind > to change the user-agent. I think for vimprobable1 this could be a nice patch, > but a can't decide, I always use vimprobable2. Same here, twice :) In other words: seems a nice feature, and I only use vimprobable2. Cheers, Matto |
|
From: Daniel C. <dan...@gm...> - 2011-08-21 11:58:13
|
Hi! On Sat, Aug 20, 2011 at 09:19:33PM +0200, Hannes Schüller wrote: > The current patch applies against keymap.h which only exists in > Vimprobable2. For Vimprobable1, this might be useful, though. Any other > opinions? The feature is pretty nice, and I would use it. I have not thought about bind to change the user-agent. I think for vimprobable1 this could be a nice patch, but a can't decide, I always use vimprobable2. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-21 11:49:30
|
Hi! On Sat, Aug 20, 2011 at 08:03:47PM +0200, Hannes Schüller wrote: > after applying all patches in succession, hints don't appear in this > version at all anymore. Also, there is now a tremendous amount of > history in these patch series. I think it might be time to create a > new, clean patch series to begin systematic issue tracking? I think I've startet refacturing on the wrong branch. Maybe this was the reason, that the patches didn't apply on top of eachother. I've rebased the branch to top of vimprobable2 and made all patches again. Hope they will work. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-21 11:34:31
|
Hi! On Sat, Aug 20, 2011 at 08:49:46PM +0200, Hans-Peter Deifel wrote: > Your patches appear to be generated with git, so it would be really cool > if you could just upload a git branch somewhere (in addition to posting > the code to the list, of course). Then people could just clone/push to > try your changes which would certainly increase your testers/user base ;) > > Thanks, > HP I have and upstrem git repository at https://github.com/fanglingsu/vimprobable.git the branch with the changes is the "fls/hinting-refacture". Daniel |
|
From: Hannes S. <ha...@yl...> - 2011-08-20 19:20:05
|
Hi! Jan Niemeyer <ne...@on...> wrote: > Excerpts from Hannes Schüller's message of Sa Aug 20 20:56:21 +0200 > 2011: > > This seems to be a patch against Vimprobable2. I don't think this > > construct is really necessary; why not just use the :bind command to > > define a few :set useragent=... commands? > > Indeed, then it would be unnecessary. I'm ashamed to admit that I > didn't know the :bind command. It was written for vimprobable1 > though. Seems I've checked the wrong repository. The current patch applies against keymap.h which only exists in Vimprobable2. For Vimprobable1, this might be useful, though. Any other opinions? Hannes |
|
From: Jan N. <ne...@on...> - 2011-08-20 19:16:50
|
Excerpts from Hannes Schüller's message of Sa Aug 20 20:56:21 +0200 2011: > This seems to be a patch against Vimprobable2. I don't think this > construct is really necessary; why not just use the :bind command to > define a few :set useragent=... commands? Indeed, then it would be unnecessary. I'm ashamed to admit that I didn't know the :bind command. It was written for vimprobable1 though. Seems I've checked the wrong repository. Jan |
|
From: Hannes S. <ha...@yl...> - 2011-08-20 18:56:55
|
Hi!
Jan Niemeyer <ne...@on...> wrote:
> I hacked together a small patch to quickly change the
> useragent of vimprobable. It's based on my old quickmark-code and
> works like this: w{1..9} sets the respective line in USERAGENT_FILE
> as the new useragent.
This seems to be a patch against Vimprobable2. I don't think this
construct is really necessary; why not just use the :bind command to
define a few :set useragent=... commands?
Hannes
|
|
From: Hans-Peter D. <hpd...@gm...> - 2011-08-20 18:47:51
|
Hi On 17:03 Sat 20 Aug , Daniel Carl wrote: > Hi! > > I hope the hinting is now functional like before refacturing. > Fixed bug that caused vimprobable to keep in hintmode, even if hint was fired. Sounds cool, but I'm too lazy to figure out what patches to apply onto what and Hannes seemed to have problems with that as well. Your patches appear to be generated with git, so it would be really cool if you could just upload a git branch somewhere (in addition to posting the code to the list, of course). Then people could just clone/push to try your changes which would certainly increase your testers/user base ;) Thanks, HP |
|
From: Jan N. <ne...@on...> - 2011-08-20 18:24:39
|
Hi
I hacked together a small patch to quickly change the useragent of
vimprobable. It's based on my old quickmark-code and works like this:
w{1..9} sets the respective line in USERAGENT_FILE as the new useragent.
It's not a very elegant solution at the moment but given there's enough
interest I'd do do a more cleaner version.
One problem is that the default browser needs to be in USERAGENT_FILE.
I often change my useragent for various reasons, so this feature is pretty
handy (for me). For example, one problem I recently ran into was the login
page of paypal.com that didn't render correctly until I changed the
useragent to that of Safari.
Using the useragent of an IOS device can also be really useful, as you
get the - sometimes hidden - mobile version of a web page, which often
'sucks less'.
Jan
|
|
From: Hannes S. <ha...@yl...> - 2011-08-20 18:04:21
|
Hi, after applying all patches in succession, hints don't appear in this version at all anymore. Also, there is now a tremendous amount of history in these patch series. I think it might be time to create a new, clean patch series to begin systematic issue tracking? Hannes |
|
From: Hannes S. <ha...@yl...> - 2011-08-20 17:36:27
|
Hi! Raphael Nestler <rne...@hs...> wrote: > Here is a patch to let vimprobable use the XDG environment variable > XDG_CONFIG_HOME to find its configuration files. > It's implemented with a global variable config_base which is set at > startup to either $XDG_CONFIG_HOME or the standard path ~/.config/ This looks like a resolution of ticket #3 (http://sourceforge.net/apps/trac/vimprobable/ticket/3) :) Hannes |
|
From: Daniel C. <dan...@gm...> - 2011-08-20 15:04:04
|
Hi! I hope the hinting is now functional like before refacturing. Fixed bug that caused vimprobable to keep in hintmode, even if hint was fired. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-19 21:24:33
|
Hi! I've fixed some minor bugs in the new hinting.js. Daniel |
|
From: Raphael N. <rne...@hs...> - 2011-08-19 12:53:30
|
Hi There Here is a patch to let vimprobable use the XDG environment variable XDG_CONFIG_HOME to find its configuration files. It's implemented with a global variable config_base which is set at startup to either $XDG_CONFIG_HOME or the standard path ~/.config/ Looking forward to your feedback. Raphael |
|
From: Daniel C. <dan...@gm...> - 2011-08-18 11:02:56
|
Hi! I removed to many lines of code, so that the ESC-Key does not remove the hints. Attaches patches sould be appliet on top of all previous patches. Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-17 21:02:01
|
Oh previous patch causes that the hints would not be removed if the ESC kay is pressed. Can someone check what to change in the C Layer? Daniel |
|
From: Daniel C. <dan...@gm...> - 2011-08-17 20:43:45
|
Hi Hannes, On Tue, Aug 16, 2011 at 09:51:21PM +0200, Hannes Schüller wrote: > Any idea of how to handle target attributes? As I said, I think the > current behaviour of the patch isn't too bad, but it's also not the > expected behaviour ;) So any chance of getting that working as well? > Which logic would need to be relocated? Attached patch is a first step to handle the target (applies in top o previous patches). The opening isn't done via JavaScript and not from C-Layer as before. I'm really confused by the c code. The patch makes the checks for JavaScript returned string useless, they could be removed. The patch causes that vimprobable keeps in hintmode after a hint was fired. Could you fix this behaviour in the c code? The indented behaviour of the JavaScript is to return "0" if the hint ws focussed or opened, all other modes cause the JavaScript to return a string (for example the url to be yanked). Daniel |
2 messages has been excluded from this view by a project administrator.
