On Jul 7, 3:16 am, nyteshade <[email protected]> wrote:
> This is not a very good design. In use, the right-arrow key is on the
I guess you mean: "Tab cyles completion and right-arrow completes" is
not a very good design. I agree. It is the design used on Google
Chrome's WebInspector, which is one reason I used it as a starting
point.
Despite my negative tone below I appreciate your feedback. In future,
consider starting your post with "The new completion has some nice
features but I think it could be improved by...".
> opposite end of the keyboard from the tab key. Also with the automatic
> pop-up, cycling is more logically done with up/down/pageup/pagedown
up/down arrows cycles are already implemented for 1.6a17.
> keys. Enter should select the highlighted element in the popup and tab
> should still complete the selected element.
I don't agree with this statement, but mainly because it is
incomplete. The conditions under which the return key ('enter')
should cause the completion to be accepted depends upon how the
completion list is created. Consider this example:
Two candidate completions:
win
window
If the user types
win<enter>
then what action do you want?
If you just say "Enter should select the highlighted element", then
the user experience is unsatisfactory. A user who wants to see the
value for 'win' will be force to study the completion list before
hitting enter, to determine if their choice ('win") is selected. If
"window" is selected they then have to type some other keys to reject
this choice. Once they have 'win' selected, they can hit Enter. In my
opinion this is unacceptable. Completion should not cause you to type
something you would not have to type if there was no completion.
In 1.6a17 the preselected completion list candidate will be the
shortest one among those offered. That way if you hit enter in the
case above you will get "win". If you want "window" you will have to
either type "d' or cycle the completions.
> This is a known and accepted behavior for other applications/
> platforms. Please don't change it. Also, clicking on things in the
In my opinion, completion key bindings from other applications should
not be a primary design goal. Rather the goal should be to offer
completion that does not cause extra work if you don't use it and
requires minimal extra work if you do. That means the key binding will
need to be content-specific. A secondary design goal is consistency
with other completions in Firebug. Third would be consistency with
other web dev tools. Way down the list would be other applications. We
are completing javascript expressions and that means the key bindings
depend upon the syntax and context of javascript. ( Or CSS or HTML in
the other Firebug editors).
> console to inspect them in the DOM tab seems broken with FF4.0b1/Mac.
I think you should wait for FF 4.0b2. b1 has too many problems.
jjb
--
You received this message because you are subscribed to the Google Groups
"Firebug" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/firebug?hl=en.
