vimprobable-users — Mailing list for Vimprobable users

Re: [Vimprobable-users] [PATCH] Refactured hinting

[Daniel C. <dan...@gm...>]

Hi!

At work I'm confronted with some cruel webapplications that uses frames and
a lot of hidden or overlayed elements. I'm dependent to use these application
for my daily work. Therefor I started to refacture the hinting.js to deal with
hinting also on framebased pages.
It's only a first attempt to make vimbrobable to work a little better on
framesites. Also if the hinting within frames could not fire the hints into
the right target, it's makes my work easier. I believe the hinting within
frames will become a more important thing if new hinting actions will be
implemented.

Daniel

Re: [Vimprobable-users] [PATCH] Refactured hinting

[Daniel C. <dan...@gm...>]

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

Re: [Vimprobable-users] [PATCH] Refactured hinting

[Andraž 'r. L. <ru...@co...>]

:2011-08-10T15:32:Hannes Schüller:

> 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.

Hmm I'm split on this as well. It might reduce the clutter but it might
be annoying.

-- 
Andraž 'ruskie' Levstik
Source Mage GNU/Linux Games/Xorg grimoire guru
Re-Alpine Coordinator http://sourceforge.net/projects/re-alpine/
Geek/Hacker/Tinker

I may not agree with what you say, but I'll defend your right to say it.

Re: [Vimprobable-users] [PATCH] Refactured hinting

[Hannes S. <ha...@yl...>]

Hello Daniel,

without getting into the coding issues right now (that should be the
second step), let's talk about the behaviour/policy changes this patch
introduces first.

"Daniel Carl" <dan...@gm...> wrote:
> - Implemented removing of hints if a number is selected. That means
> that hint are removed that don't match a given number like in
> vimperator. I you type 1 in hintingmode all hint except of [1,10-19]
> will be removed. The hintnumber will not be updated and it's already
> possible to tab or shift- tab through the remaining hints.

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.

> - 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?

> I this we should made some decision where to handle the different to 
> implement hinting actions (open link, copy linktext to clipboard,
> focus hinted element). In my opinion this could be given via
> parameter to the js-function that generates the hints, so we can
> later if the hint is selected simply use fire() to handle the action.
> This should also keep the c-code cleaner.

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.

> I could not find the path for copy the hinted url to clipboard that
> was mentioned in a previous mail, i think i should it merke into the
> patch.

http://www.vimprobable.org/mailman/archives/vimprobable-users/2011-June/000797.html

Hannes

[Vimprobable-users] [PATCH] Refactured hinting

[Daniel C. <dan...@gm...>]

Hi!

I used the chance to test the new mailinglist to public a refactured hinting.js. I spent some time in cleaning up the hinting code and added some changes so that the hinting acts like in the vimperator.

Changes i made:
- Ported hinting javascript in to object to make the code cleaner.
- Used speaking varibale names.
- Also removed useless code and added some utility methods
- Adde early breakout to hinting.js
- Also reduced some if else nesting by logical reduction
- Added focusHint() function and used cloning to generate hintelements
- Made some methods private
- Reduced number of variables in hinting javascript. 
  Hints are now saved with some metadata (element, number, text, span,
  backgrouncolor, color) into one array
- Removed extravariable for focused element in hinting.js
- Implemented removing of hints if a number is selected. That means that hint 
  are removed that don't match a given number like in vimperator. I you type
  1 in hintingmode all hint except of [1,10-19] will be removed. The   
  hintnumber will not be updated and it's already possible to tab or shift-
  tab through the remaining hints.
- Implemented possibility to fire focused hint by return key. I hope this   
  feature will make other hintingfeteatures easier to implement

Sorry for the squash patch, was much easier for me to generate.

I this we should made some decision where to handle the different to 
implement hinting actions (open link, copy linktext to clipboard, focus hinted element). In my opinion this could be given via parameter to the
js-function that generates the hints, so we can later if the hint is selected simply use fire() to handle the action. This should also keep the
c-code cleaner.

I could not find the path for copy the hinted url to clipboard that was mentioned in a previous mail, i think i should it merke into the patch.

Daniel

-- 
Daniel Carl
Gustav-Fischer-Straße 33
07745 Jena
0176/20166455




NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

[Vimprobable-users] Test

[Hannes S. <ha...@yl...>]

Test