Closed
Bug 153836
Opened 22 years ago
Closed 20 years ago
Bigger text as + and Stop as Escape
Categories
(Camino Graveyard :: Toolbars & Menus, enhancement)
Tracking
(Not tracked)
RESOLVED
FIXED
Camino1.5
People
(Reporter: stf, Assigned: moz)
References
Details
Attachments
(1 file, 1 obsolete file)
2.76 KB,
patch
|
Details | Diff | Splinter Review |
Would it be possible to use Cmd-+ for Bigger text, like in Mozilla and other
browsers, it's more logical.
I was not able to test Cmd-. to stop loading but generally Cmd-. are seldomly
working correctly with international keyboard.
Using Escape would be like in several other browsers.
Comment 1•22 years ago
|
||
keyboard requests
Assignee: saari → pinkerton
Summary: Bigger text as + and Stop as Escape → [RFE] Bigger text as + and Stop as Escape
Updated•22 years ago
|
Target Milestone: --- → Chimera0.5
Chimera uses Command+= currently, just the same as Mozilla. Mozilla calls it
"Command +", though since shift isn't held it isn't actually +.
This is WFM using Chimera/20020621.
Comment 3•22 years ago
|
||
Ditto what Greg said. We should eventually set the keyboard shortcuts to work
best for whatever keyboard goes with the default language on the user's machine;
this falls under that big "Internationalize/Localize Chimera" heading.
Mapping esc to stop loading seems like a good idea; cmd-. and esc are usually
interchangable, and esc doesn't do anything right now. Cmd-. has to the listed
shortcut for stop loading in the English version, however.
Reporter | ||
Comment 4•22 years ago
|
||
In Mozilla 1.1a Bigger text is on a French keyboard accessible via
cmd-= and cmd-+ (equals cmd-shift-=) but on numeric keypad cmd-= or cmd-+ are
also working. On french keyboard + is shift-= above = on the key.
May I suggest to use these keys in Chimera:
cmd-arrow up/down for font size that will solve the intl problem.
Cmd-= can be use to re/set back the font size to the default one on
page?or?pref, new feature.
Esc can stop page downloading, very handy any Mac able to use OS X has an Escape
key.
Esc when not downloading, can stop gif animations.
Esc = Cancel in a dialog
Comment 5•22 years ago
|
||
Mapping many commands into one key depending on a certain "mode" is never a
really good idea. Let's assume I want to stop loading, and press Esc, only to
find that all GIF animations have now stopped, since the downloading turned out
to be quick enough to end before I got around to pressing Esc. Not nice. Just
have the Esc key mirror Command-Period's functionality (in dialogs and in the
browser view).
Comment 6•22 years ago
|
||
A summary of European keyboard-safe shortcuts is in bug 36048. On the Classic
side Command-. was a special combination that worked even on keyboards that
require shift for typing the period. I haven't tested with OS X, though.
I think shortcuts should be considered as an internationalization issue rather
than a localization issue. There are a lot of people who use the main U.S.
English version with non-U.S. keyboards. Leaving shortcut compatibility up to
the localizations doesn't help those users.
Updated•22 years ago
|
Target Milestone: Chimera0.5 → Chimera0.9
Updated•22 years ago
|
QA Contact: winnie → sairuh
Updated•22 years ago
|
Summary: [RFE] Bigger text as + and Stop as Escape → Bigger text as + and Stop as Escape
Comment 7•22 years ago
|
||
On both consumer and professional Mac laptops, plus and minus keys are also on
the numeric keypad. On a desktop these keys would stand out much more clearly,
but ont he laptops, where space is at a premium, a compromise was made to still
have a numeric keypad without carrying extra keys and keyboards around with the
laptop. They achieve similating a numeric keypad by remapping select keys on
the keyboard with a special laptop-only "Fn" (function) key. The 10-key pad
keys are written on other keys in the corner in small blue type and are
activated by simply holding down function with the left pinky finger and
entering 10-key on the appropriate blue labelled keys. (This also allows you to
have a virtual numeric key pad using the normal size keys in the middle region
of the keyboard to avoid fatigue of using a more crammed keyboard. In fact, all
these keys measure out to be the same size as the full size keyboard. The only
smaller than normal keys are the non-alpha-numeric keys like F1-F12,
enter/return, etc.)
The characters in this chart on the left are the black regular unmodified keys.
The right side characters in quotes are what is actually entered when function
is held down in combination with them.
6=Clear 7="7" 8="8" 9="9" 0="/" -="="
U="4" I="5" O="6" P="*"
J="1" K="2" L="3" ;="-"
M="0" ,=(n/a) .="." /="+"
Example: to type 5+2= .. With your left hand finger of choice (pinky usually),
you would simply hold the blue fn key in the corner. you would hold the blue
function key and with your free right hand, just type: I/K-. (trust me, this
makes more sense when you see it, because the keys are color coded. iBooks and
Powerbooks are both the same in this respect at least on the US keyboard. The
function key is not present on the regular keyboard. It seems not seen to be
seen by software, so my guess is it's a hardware level implement that sends from
these keys the same codes as if they were the keys on a numeric keypad of a
normal USB keyboard. Therefore, we don't have to have seperate keymaps for
laptops or desktops to address the + and - differences on the numeric keypad.
The exception
to this rule is the use of the f12 key on ibooks for a substitute "eject" key.
This isn't a concern for us thought because as far s I understand browser
technology, there's nothing to eject in a browser. I think that the eject key
(on a standard keyboard) is reserved and non-acessible to regular applications
anyways at the OS level.
So, with that information about + and - (are you more confused now or less?) in
mind... possible solutions are:
SOLUTION 1: The - and + keys on the numeric keypad ARE distinguishable in
software from their counterparts on the top key row of the regular alpha-numeric
portion of the keyboard. Mac BU at Microsoft has already tackled this problem
obviously in noting IE 5.2's behavior here. It treats them by symbolic
location, instead of by proper key combination.. Under IE, (technically
speaking) it is command + '-' and command + '=' on the alphanumeric section of
keys... BUT on the keypad, it's command + "+" and command + "-" .. When you use
the browser, by touch and don't like to stare at the keyboard to figure out
technicalities, this seems to be the best solution, because you aren't stumbling
to see which key may also normally have to be shifted to represent + or -.
I think it's an OK compromise and given that one major browser does this
already, perhaps OK just to adopt their model. In this case, for Chimera to be
both easy to use, memorable and consistent by the "+" and "-" key symbols, I
think emphasis should be placed in this one exception on the location of the
symbols moreso than the technical correctness of their labelling in regards to
wether or not it would normally be shifted or not to produce those characters in
a text document, Chimera already mirrors IE behavior EXCEPT that on the numeric
keypad, you end up having to use Command + "=" in lieu of Command + "+" which
doesn't work. So I would suggest to simply remap the numeric keypad version of
these keys only only so that it only pays attention to the correctness of the
symbols preseent on the keys instead of wether or not the nee to be shifted.
People who get edgy about definitions can simply put a "+" sticker covering up
the = sign on than one infernal key that is causing this kind of discussion to
be necessary, and then handed a sticker that says, "don't worry be happy!"
SOLUTION 2: People who are "convenience" orientated personalities will argue
against having to shift the "=" key to produce a "+" because its too cumbersome,
yet on the flip side, people who are "technical propriety" driven will insist
that the key with "=" on it is only an "=" key unless it's shifted, and then it
and only then it becomes a "+" key. You can't satisfy both... This is an issue
of point of view. For example: Is Command + "<" just Command and pressing key
that has "<""," on it, or does that key that has both symbols *have* to be
shifted before it is allowed to be called a "<"..? I say avoid the whole issue
and use Command + uparrow/downarrow. This is by far the simplest, most
unconfusing, most directly logical way to macro increase/decrease text size.
SOLUTION 3: Use command+shift+"+" and command+shift+"-" in all terminology. If
you approach it like you've been told to do it, this can only have one meaning
wether it's proper or not.. and implement it as command shift -, = for keyboard
and command shift -, + for the numeric keypad. Still confused? Back to idea #
2 or ahead to # 4.
SOLUTION 5: Recall solution 2.. just use any set of keys that mentally
correspond to the increase or decrease of a value or position. Choose a new
pair of macro keys that are paired visually as opposites, but not allocated to
any function yet. There are two available possibilites for this. They are:
• "(" (Cmd + Shift + 9) for smaller and ")" (Cmd + Shift + 0) for larger. These
parenthesis are both shifted keys, and they only have one location on the
keyboard. There should be no confusion. The problem is that parenthesis are not
the first thing I think of when I equate something to size..
• "<" (Cmd + Shift + ,) for smaller and ">" (Cmd + Shift + .) for larger. These
greater or less-than keys look like arrows, represent opposite functions, and
even mathematically-speaking less than or greater than makes sense in terms of
size comparisons... making command + lesser than or command + greater than mcuh
better choices for these keyboard shortcuts!
* The only other viable choice I can see is to forget the complexity of
internationalization of the keyboard presets, but to simply create a preference
item letting the user choose the keys that make the most sense to them. We can
show who the real browser communist is (M$) by making Chimera more open for user
configuration in problems like these.. More choices for the user -AND- less
headaches in the bug complaint/feature request department, right? Of course
this is more difficult to implement than just changing the keys, so I think
perhaps switching the defaults to use < and > with command for now is a quick
fix, and allowing the user to pick later is a better full solution.
Comment 9•20 years ago
|
||
(In reply to comment #8)
> bigger fish to fry
You say that, because you have an US keyboard. In Camino enlarging text is
command-= which is a three keys combo on a German keyboard (command-shift-0). In
other browsers it's command-+ which is just these two keys and logical and easy
to press. Makes sufficient difference to be annoyed at Camino whenever I want to
enlarge text.
Please add command-+ as keyboard shortcut for bigger text.
Assignee | ||
Comment 10•20 years ago
|
||
*** Bug 287407 has been marked as a duplicate of this bug. ***
Comment 11•20 years ago
|
||
*** Bug 179606 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 12•20 years ago
|
||
This *should* fix both of these issues, but I humbly request that someone
compile with this patch and make sure (a) it does what I said, and (b) it
doesn't break anything. ;)
Assignee: pinkerton → mozilla
Status: NEW → ASSIGNED
Assignee | ||
Updated•20 years ago
|
Attachment #178400 -
Attachment is obsolete: true
Assignee | ||
Comment 13•20 years ago
|
||
Eeep, I was catching all the key down events and not passing them on instead of
catching just the escape key (thanks, Simon).
New patch!
Comment 14•20 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•20 years ago
|
||
*** Bug 176900 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•