Re: [Vimprobable-users] [PATCH] Refactured hinting
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
From: Daniel C. <dan...@gm...> - 2011-08-17 12:05:06
|
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? I think we should depending of pressed key give additional params from C-Layer to the scripts createHints() function. These param would be set in the object and used to do the right thing in the fire() function. We have to differ between opening new window or not and returning the url of hint or open it. Uzbl uses two variables for this 'newwindow' and 'returnuri', don't know if we need both too. Cases: f (open in current window): - 'newwindow' set to false - dispatch click event on hinted element - links within frames should be opened in the current frame - would also fix some sites using tabmenu with links that are observed for cnklick event -- these will cause the site to be reloaded in the current version because the fire() function retrieves the url to the C-Layer - return nothing to C-Layer F (open in new window): - 'newwindow' set to true - dispatch CTRL-Click event (seems not to work) alternate set target='_blank' dispatch click event and remove target attribute - should work like the pentadactyl plugin, that opens the link into a new window Yank URL (not implemented): - return the src or href attribute value to the C-Layer Other Modes (not implemented): - return some other nice information of the hinted element to the C-Layer I think for the more sofisticated hint actions like the ;... in pentadactyl we have to set a mode for the hinting.js so that the script knows what for an information to return on fire(). Daniel |