Closed
Bug 18033
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] platform specific keybindings
Categories
(SeaMonkey :: General, defect, P1)
SeaMonkey
General
Tracking
(Not tracked)
VERIFIED
FIXED
M13
People
(Reporter: tor, Assigned: akkzilla)
References
Details
(Whiteboard: [PDT+] [by 12/15] [checked in, but dependent on 21610])
Currently mozilla provides the same keybindings on every platform it
runs on. While this provides a consistent interface across platforms,
it also means that it doesn't mesh nicely from a UI point of view with
other applications on the platform. It also means that mozilla acts
differently at a muscle-memory level than Netscape 4.x.
Problems from a unix point of view:
* Menu keybindings are bound to Control-whatever, while Netscape 4.x
uses Alt-whatever.
* Text entry widgets don't have the usual emacs keybindings like
Netscape 4.x, but instead have some strange set of binding I have
yet to determine.
While I can only speak from a unix point of view, I'm sure that MacOS and
Windows users have similiar expectations regarding compliance with standard
keybindings for their platform.
Mozilla should switch keybindings depending upon which platform it is running
on to match the expected standard set. A preference for overriding this
default choice may also prove useful.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M12
Assignee | ||
Comment 1•25 years ago
|
||
Accepting and would like to work on this for M12. Yes, MacOS has some
platform-specific keybindings as well, but fewer of them.
Assignee | ||
Comment 2•25 years ago
|
||
Talked to Mike; there are some hitches in the implementation of the selection
interface to move the cursor around from JS. He's working on the problem, I've
offered to help if I can. Marking a dependency.
Updated•25 years ago
|
Priority: P3 → P1
Comment 4•25 years ago
|
||
bumping up priority since it is a PDT+
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] [by 11/26 -- if depencies are resolved]
Comment 7•25 years ago
|
||
this has been investigated and akkana has an idea on how to resolve this one
but, this one can't be worked on until the dependencies are resolved. She may or
may not need assistance from saari, mjudge, brade and hyatt.
Comment 9•25 years ago
|
||
In a couple of cases I hope a union could be done - for example I don't see any
reason why Ctrl-A and Ctrl-E in a text field couldn't work the same on Windows
and Mac as they do in Unix.
Assignee | ||
Comment 10•25 years ago
|
||
You bet. The lack of these bindings has been the main reason I avoided using
our past client on Windows any more than necessary.
Since these will be done in XUL, the user will eventually be able to substitute
in whatever set of key bindings he prefers, and those of us who want the
Unix/emacs bindings can have them on all platforms.
Updated•25 years ago
|
Whiteboard: [PDT+] [by 11/26 -- if depencies are resolved] → [PDT+] [dependent on 13378 getting resolved]
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] [dependent on 13378 getting resolved] → [PDT+] [dependent on 18046 getting resolved]
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] [dependent on 18046 getting resolved] → [PDT+] [dependent on 19981 and 18046 getting resolved]
Assignee | ||
Comment 11•25 years ago
|
||
11818 (the renaming of the xul key) is in, so now the main impediment is getting
the APIs for moving the selection around, 18046, which in turn has been waiting
for 19981.
Meanwhile, I'll be working on things like getting the platform overlays loaded
(they don't seem to be doing anything now) since that's where the platform
specific keybindings will live.
Comment 12•25 years ago
|
||
talked with Trudelle to see if saari could set 19981 as a top priority, Trudelle
will talk with saari and see what it will ential to resolve 19981, and they will
assign a fix by date. Once the fix by date is set on 19981, then mjudge can set
a fix by date on 18046. When 18046 gets a fix by date, then this bug can have a
fix by date.
Akkana, in a perfect world -- how long do you think it will take to resolve this
bug when 19981 and 18046 are resolved?
Assignee | ||
Comment 13•25 years ago
|
||
There's one other unsolved issue: platformGlobalOverlay.xul doesn't seem to be
loaded, or at least its keyset doesn't merge in with the editor default keyset.
I'm talking to waterson and saari to find out what needs to be done there; can't
give a good estimate until I get an answer for that.
Once that's solved, and the API for 18046 is in place, it's just a matter of
writing some xul and js; a few days. I'll guess a week for the whole thing
(helping out with the implementations for 18046, writing editor APIs, writing
the xul and testing everything).
Assignee | ||
Comment 14•25 years ago
|
||
Strike that last remark. I talked to saari and waterson and they showed me
where I was going wrong, and the problem is solved and the platform overlays are
being loaded just fine.
So it'll probably only take a few days (allow 2-3) for implementing and testing
once the selection controller is working. I'll be working on the
editor-specific APIs in the meantime.
Updated•25 years ago
|
Whiteboard: [PDT+] [dependent on 19981 and 18046 getting resolved] → [PDT+] [by 18046 fix by date + 3 days] [dependent on 19981 and 18046 getting resolved]
Comment 15•25 years ago
|
||
setting fix by date to be 3 days after 18046 fix by date.
Assignee | ||
Comment 16•25 years ago
|
||
Making progress: checked in the editor API for various delete methods, and an
initial set of emacs keybindings. The only ones hooked up so far are ^D=delete
and ^H=backspace; the rest still waiting on nsISelectionController.
Assignee | ||
Comment 17•25 years ago
|
||
Beth just pointed out 10642, which is clearly another API which needs to be in
for this bug (I thought Home and End were included in the 18046 API, but if Mike
considers them separate bugs, he knows best).
Comment 18•25 years ago
|
||
adding some extra data for the PDT team, based on coversation from today's
meeting. The keybindings that aren't in the menus are things like left arrow,
right arrow, up arrow, down arrow, pageup, pagedown, home, end. Users want to be
able to do the following kinds of things via keybindings:
* move caret to beginning of line / end of line
* move caret to beginning of paragraph/end of paragraph
* move caret to beginning of document/end of document
* scroll document to beginning of document/end of document
* move caret to next word/previous word
* move caret up/down one line
* delete previous/next character
Akkana, can you list any other keybondings that do not have an associated menu
item?
Assignee | ||
Comment 19•25 years ago
|
||
Other big ones you didn't mention are delete forward/backward character/word,
and kill to end of line.
Last weekend I checked in a starter set for Unix (unimplemented since we're
still waiting on 18046 for the selection motion routines). See
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/unix/platformGlobalOverlay.xul
for my Unix starter set.
This bug isn't on the complete list, though; it's on the concept of being able
to have these sorts of key bindings. Once we get a basic set working, if there
are specific bindings missing, people can file bugs against them.
Comment 20•25 years ago
|
||
The keybindings in
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/unix/platf
ormGlobalOverlay.xul
has things like
closeCmd.{label,key,accesskey}
quitApplicationCmd.{label,key,accesskey}
redoCmd.{label,key,accesskey}
appear to come from
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/locale/unix/platfo
rmGlobalOverlay.dtd
Shouldn't the platformGlobalOverlay.dtd exist under some locale (e.g., "en",
"de", "fr", "ja") sub-directories for localization because close, quit and
redo may use different characters in German, etc.?
Cc'ing Tao.
Assignee | ||
Comment 21•25 years ago
|
||
closeCmd and friend aren't part of what I put there -- they were there before.
They don't appear to be working, but I didn't remove them (at least not this
time around) because I assumed that someone else had plans for them.
If you decide that the .dtd file should be by-locale or otherwise need
modifications, please make that a separate bug since it's not related to this
one.
If the overall key bindings need to be localized, that's another interesting
issue -- again, not this bug but a separate one. If you file one, please cc me
on it if it might involve moving key binding files to a different directory
structure.
Comment 22•25 years ago
|
||
cc rchen
Comment 23•25 years ago
|
||
I filed another bug report for locale issue. The # is bug 20296. This happens
in the build tree not in the product.
Comment 24•25 years ago
|
||
Just another vote to please allow the opition of Emacs key bindings
on all platforms. It looks like it's going that way, but I just wanted
to make clear that there's lots of people that feel strongly about this.
I also know Windows uses who would love to have HOME and END keys work
for C-a and C-e respectively. I also like the idea of the doing the
union of all platforms when there is no conflict. (e.g. Both HOME and C-a go
to the beginning of the line)
Comment 25•25 years ago
|
||
Agreeing with emacs bindings vote, this should be
presented as a pref to the user? Maybe a xul file
you just drop in would be good enough for beta.
Assignee | ||
Comment 26•25 years ago
|
||
As of now, you can drop in the appropriate platform overlay and get the unix
bindings on any platform. I.e. copy
xpfe/global/resources/content/unix/platformGlobalOverlay.xul instead of
win/platformGlobalOverlay.xul into dist/bin/chrome/global/content/default.
Or you can edit dist/bin/chrome/global/content/default to customize your key
bindings to anything you want. Eventually I'd like to make this loadable from
something like ~/.mozilla/globalOverlay.xul, but that will come later.
Comment 27•25 years ago
|
||
A while ago, Hyatt and Hangus worked together to revamp the platform provider
scheme: instead of having all platform providers installed in dist/, they
decided to let the platform variants live in the source tree and install only
the valid one to dist/.
Keybinding is one obvious example of platform-specific resources.
Yes, lots of UNIX users prefer emacs keybindings. We can either resort to a new
package type such as "chrome/keybindings/" or a locale type variant of all
packages. For localization purpose, the latter is more intuitive.
Updated•25 years ago
|
Whiteboard: [PDT+] [by 18046 fix by date + 3 days] [dependent on 19981 and 18046 getting resolved] → [PDT+] [by 12/10] [dependent on 19981 and 18046 getting resolved]
Comment 28•25 years ago
|
||
*** Bug 10642 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 29•25 years ago
|
||
Another update: I've checked in the IDL files for bug 18046, with stub
implementations, and I've changed the unix key bindings to point to the stub
implementations. So now you'll get JS errors on the console telling you about
unimplemented functions, but once the real nsISelectionController
implementations for 18046 are written, the emacs bindings should magically "just
work". In reality, of course, there will probably be some bugs, so I won't
close this out until we have something actually working.
Updated•25 years ago
|
Whiteboard: [PDT+] [by 12/10] [dependent on 19981 and 18046 getting resolved] → [PDT+] [by 12/15] [dependent on 19981 and 18046 getting resolved]
Comment 30•25 years ago
|
||
updating fix by date
Assignee | ||
Comment 31•25 years ago
|
||
We have implementations for 18046, and a mostly-fix for 18046, and I have
updated the unix keybindings accordingly.
Current state: char motion and deletion events work (^b, ^f, ^h, ^d).
Things that don't work right yet:
- Page, word and kill-to-end actions don't quite work yet (Mike is looking, part
of bug 18046)
- Editor and browser window bindings aren't hooked up yet; these only work in
text fields and text areas.
- focus problem (which I think hyatt is looking at?) so you have to click in the
urlbar, click in the content area, click back in the url bar, then click again
in the url bar to set the caret and have events get through. Ugh.
Comment 32•25 years ago
|
||
The key bindings should also be adapted for the different keyboards. On my
German keyboard the Go|Back = Alt-] doesn't work (I type [AltGr]+[9] to get the
] and Alt-AltGr-9 doesn't work and isn't comfortable.)
Concerning Alt vs. Ctrl under unix, I must admitt I favour ctrl because e.g.
nedit uses it as well.
Comment 33•25 years ago
|
||
burnus, see bug #20296. It's also no problem to edit the keybindings, if they
don't please you.
Assignee | ||
Comment 34•25 years ago
|
||
Unfortunately, with hyatt's latest fixes, the xulkey setting is no longer
settable in the xul keyset; he removed my code to parse the xulkey from the
keyset and hardwired it by platform (so on Unix it's hardwired to alt). Hyatt
assures me that this is temporary and that it will be settable via CSS, and the
menu access key (currently hardwired to alt on all platforms, which is obviously
a problem on Unix) will be settable via the same mechanism. Once that's in
place, it will be no problem for burnus and other users used to the Windows
model to use control as their xulkey.
Comment 35•25 years ago
|
||
I'd like to use windows keybindings on unix too.
I certainly hope Alt+F will select file menu as standard on both Windows, OS/2
and Unix GUIs. (I dislike the 4.x behavior).
Assignee | ||
Comment 36•25 years ago
|
||
Status update: this is mostly in for text fields/areas, but you have to click
inside, outside, then twice inside the text field before the bindings are
loaded. See bug 21610. Also ^K gives a JS error, but I have a fix for that
awaiting review (really part of bug 18046, and see bug 21534 for a patch).
Updated•25 years ago
|
Assignee: akkana → hyatt
Status: ASSIGNED → NEW
Comment 37•25 years ago
|
||
i will take this and make the overlay load synchronously.
Updated•25 years ago
|
Assignee: hyatt → akkana
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] [by 12/15] [dependent on 19981 and 18046 getting resolved] → [PDT+] [by 12/15] [checked in, but dependent on 21610]
Comment 38•25 years ago
|
||
final m12 candidates are spinnning now. moving to m13.
if we fall off track and need to respin m12 for some
yet unknown reason we can consider this if you get
a fix in hand.
Comment 39•25 years ago
|
||
not sure but this may be in hyatts latest checkin to the
trunck and picked up in the merge to the SeaMonkey_M12_BRANCH
can someone check the tip and see if its working?
Assignee | ||
Comment 40•25 years ago
|
||
Nope, hyatt's checkin last night didn't fix this -- we're still not loading the
platform keybinding files.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 41•25 years ago
|
||
This was working as of Hyatt's checkin on Saturday. Let's hope it stays
working!
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 42•25 years ago
|
||
verified
Assignee | ||
Comment 43•25 years ago
|
||
*** Bug 20574 has been marked as a duplicate of this bug. ***
Comment 44•25 years ago
|
||
If this is fixed and verified, how come the Home and End buttons doesn't work in
the browser? PgUp and PgDown works fine!
Assignee | ||
Comment 45•25 years ago
|
||
Probably because of bugs 14026 and 23401. The browser controller is all screwed
up and isn't handling most keystrokes. Page up and down don't work for me
either.
Comment 46•25 years ago
|
||
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•