[Dillo-dev] Address bar keys (bug #1012)

[Benjamin Johnson]

Rogutes Sparnuotos wrote:

> Benjamin Johnson (2011-10-20 15:56):How should dillo behave when a user  
> binds Ctrl-A?

It should perform the action bound to Ctrl-A, of course.

Just to clarify, the only thing I want to change is the key bindings when  
the user is typing in the URL input box.  Specifically, I'm talking about  
the CustInput::handle() function in ui.cc:
   http://hg.dillo.org/dillo/file/e82663b3c477/src/ui.cc#l96

Dillo intercepts several key bindings normally handled by the input box  
itself.  The problem is, some of these key bindings conventionally have  
different meanings than Dillo assigns (see below).

Not all the bindings are bad.  I'd keep the binding for Ctrl-L, for  
example, which rehighlights the input text when you're typing in the box.   
That's pretty intuitive, and matches the behavior of other browsers.

On the other hand, most users aren't familiar with Unix command line  
bindings, and even those who are usually don't expect that behavior in a  
graphical application such as Dillo.  It might be convenient, but  
usability isn't always about convenience; it's about doing what users  
*expect*.

Basically, a good interface is one an unwitting mere mortal could figure  
out without ever reading the manual, or even thinking too hard.  Joel  
Spolsky explains it a lot better than I do:
   http://www.joelonsoftware.com/uibook/fog0000000249.html

> > >Having it consistent over all text inputs and  configurable via>  
> >keysrc sounds reasonable to me. I don't know the keysrc details>  
> >though, so I might miss something.> >Cheers,> >JohannesHaving  
> input/insert mode and macros in keysrc would be interesting, if nottoo  
> complex.

It would be interesting, but it certainly would be complex, and I'm not  
sure the benefits outweigh the costs.  I suspect most users are probably  
fine with just the basic key bindings FLTK already provides.

There's also the matter of consistency, not just within Dillo, but between  
Dillo and other FLTK applications.  Part of the advantage of using a  
toolkit *is* the consistency; that was the original motivation behind KDE,  
for example.

> > I was thinking just a simple boolean option in dillorc -- and turn> it  
> OFF by default (i.e., no Unix keys), because it's not typical GUI>  
> behavior, and anyone who wants it on can quite easily set it in his> or  
> her own dillorc.Would be a strange dillorc option. A real patch would  
> implement this inkeysrc :)

Hard-coding is much stranger than either of those, and much uglier, too.

The dillorc option would actually make sense here, because these  
particular bindings usually go together as a group (it seems weird to do  
the Unix Ctrl-A, but not the others).  Though it would make more sense  
still just to leave well enough alone, since there's no real need to  
change the input box's behavior.

> Somehow I failed to notice that Ctrl-A for select all is "typical GUI 
> behavior", perhaps I am not using GUIs enough...
> [...snip...]
>Here, Ctrl-A goes to the beginning of the line in all the input boxes 
> ("find text", "web search", <input> in forms).

Ctrl-A is conventionally used for select all, and at least on Windows,  
FLTK binds it to select all in input boxes.  It may be that FLTK uses the  
Unix bindings (Ctrl-A for beginning of line, Ctrl-E for end, etc.) on  
those platforms, in which case Dillo's hard-coding that behavior is  
pointless and redundant.  I haven't booted into Unix in a while, so  
offhand I haven't checked.

Now, I know there will likely never be Windows support in mainline Dillo,  
and so you're probably wondering why Windows' key bindings should matter  
to you.  While Unix doesn't have any formal standards for graphical user  
interface design -- indeed, the X Window System was deliberately designed  
that way -- most toolkits tend to follow what Windows does.  Windows has  
explicit formal standards for command names, menu layouts, shortcut keys,  
etc., and not only are they standardized (at least on that platform),  
they're also well known since roughly 97% of desktop computer users run a  
Windows operating system.

(Microsoft also helped design Motif, if anyone remembers that -- which is  
kind of weird for me to say, since I was roughly two years old at the  
time.  Moving on...)

For reference, here's FLTK's human interface guidelines, which borrow  
"common elements from the CDE/Motif, GNOME, KDE, MacOS, and Windows  
environments":
   http://www.fltk.org/hig.php

And here's a list of standard accelerator keys from Qt's documentation,  
which explicitly recommends following Microsoft's recommendations:
   http://doc.qt.nokia.com/5.0-snapshot/accelerators.html

To get back on topic, what does all this mean for Dillo?  My own opinion  
is, the toolkit designers put a lot of thought into this stuff, and  
probably know more about how their widgets should behave than you and I  
do.  So personally, I don't think we should override that behavior at all  
unless there's a really good reason to do so.

> > Although I will add, the Shift-{Left,Right} bindings in the address>  
> bar *have* to go.  They're fine elsewhere, if a bit quirky, but in> the  
> address bar they interfere with text selection.  Ctrl-Tab and>  
> Ctrl-Shift-Tab are much more logical and convenient, anyway.> ~Benjamin 
> Are we using different versions of dillo? Shift-{Left,Right} doesn't do 
> anything here.

I'm talking about this block of code right here:
   http://hg.dillo.org/dillo/file/e82663b3c477/src/ui.cc#l117

Pressing Shift-{Left,Right} in the address bar moves between tabs, rather  
than selecting text as expected.  (Maybe something left over from dillo2?)

> For the arguments sake, how would having to press Ctrl-Shift-Tab be more 
> "logical and convenient" than Shift-Left? It's a matter of taste (habit). 
> In my opinion, both bindings have a disadvantage: Ctrl-Shift-Tab is 
> difficult for the fingers, Shift-Left is unusual to most people. That's 
> why it is configurable, isn't it?----  Rogut s Sparnuotos

Well, Ctrl-Tab's nice because of the obvious mnemonic; because it's really  
easy to type; and (you can probably guess what's coming) because it's  
familiar, since lots of other browsers use it.

In contrast, the Shift-{Left,Right} keys are much harder to type,  
especially on a cramped laptop keyboard where your fingers are right on  
top of each other.  And of course, it's a bit weird because I (and  
probably most users) associate those keys with "select text," not "change  
tabs."

Basically, what all this boils down to is that consistency is key.  Yes,  
it may be the hobgoblin of little minds, but when faced with an unfamiliar  
interface, *every* user has a little mind.

So anyway, there's my rant for tonight. :-)

Regards & cheers,
~Benjamin