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-10 18:23:02
|
Hi Hannes, thank your for your answer to the patch. > I see some advantages of this behaviour, but also some potential > disadvantages. You did the right thing insofar that the hint numbers > don't change. It give the users better overview or confuse them due to > visual irritation (I'm undecided). It could be a problem that not all > hintable elements are clearly visible anymore if users want to correct > their selection. I'd like to hear more opinions. If the user changes his select the hints are shown again, like the hinting works on current upstream revision. 1) If the user hits a number all not matching hints will be removed. If the user deletes last number all possible hints will appear like expected. 1) The user hits a number and after that he decides to filter by text, the previous hints will also be removed and only the text matching ones will be shown also those hints that where removed by the numbered hinting. But your are right, if it's irritation it should be removed from the patch. I think I where in flow an tried to adapt the behavior of vimperator. > > - Implemented possibility to fire focused hint by return key. I hope > > this feature will make other hintingfeteatures easier to implement > > I'm not sure what the change is here. Return already fires the active > hint, doesn't it? For numbered hint filtering it's true. But if you filter by text, there is none hint focused or active and you can't activate it by return. > I disagree. The way I envision it (and the way I implemented the other > hinting modes), the Javascript code is the universal part and the > different actions/targets are remembered and implemented in C. Already, > the idea is to simply use fire() - that passes the selected data back > to the C layer, nothing else. The C layer needs to know what action the > hints have been requested for anyway (since this is where the request > originates). I don't see any advantage in passing that information > which we already have at that level to an even higher one in order to > implement more logic there. But maybe I'm misunderstanding your point. For now it's OK so, but what is with the mentioned link actions prefixed with ';'? For example yank hint URL to clipboard? Either a dedicated function in JavaScript is called or the fire function should know what to return, or did I misunderstood the code? To soothe you, I'm disimpassioned about the way where the different hint actions are handled, but I agree with you that we should decide us for one straight way and don't mismatch the concerns between the C layer and the JavaScript. Daniel |