Joost->Matthias: ...please think about....most of the shortcuts you
mention are often used and their use is mostly restricted by window
managers. 

SBA: ... restricted by various window managers of various operating
systems. The outcome would be that a window manager would "catch" the
keyboard input and the office has no chance to react at all. There are
already some "Standard" shortcuts that don't work on all window managers.

But in general, the current (OO.org 6744) limitation looks a little
poor: In the dialog, only the 4 Options "Key alone" or "Key plus Shift
/ Control / Shift+Control" are offered.

Reassigned to Bettina.

*** Issue 3207 has been marked as a duplicate of this issue. ***

*** Issue 18886 has been marked as a duplicate of this issue. ***

*** Issue 23861 has been marked as a duplicate of this issue. ***

*** Issue 32905 has been marked as a duplicate of this issue. ***

*** Issue 40286 has been marked as a duplicate of this issue. ***

It would also be great to have shortcuts for subscript and superscript. I know 
you can customize this but in the version I am using (1.1.4) there is no 
keyboad command for Cntrl + = although there is one for Cntrl + + (presumably 
one has to enter Cntrl + Shift + =). In MS Word, Cntrl + = renders characters 
in subscript whereas Cntrl + + (or Cntrl + Shift + =) would render characters 
in superscript.

*** Issue 18648 has been marked as a duplicate of this issue. ***

*** Issue 54854 has been marked as a duplicate of this issue. ***

Additional requests:
   d) differentiate between the num-pad and the rest of the keyboard.
Example: In M$ Word Ctrl+- gives you a conditional hyphen, whereas Ctrl+NUM- 
gives you a long dash. In OOo 2.0 they both do the same (conditional hyphen), 
because they are treated as the same shortcut.
   e) (as suggested on other issues before) drop the system of selecting a new 
shortcut from a predefined list. Instead, let the users press the actual 
shortcut themselves (and have OOo read it from the keyboard), as in M$ Word.

You can already press a shortcut key, but first you have to give focus to the 
shortcut keys field. This saves a lot of pointless scrolling searching for the right 
shortcut. 

@pesala:
I know. But I can't assign a shortcut to, say, Ctrl+Shift+- because it's not in 
the list. Or Ctrl+^ or Ctrl+, or Ctrl+#  etc.,etc.,....

*** Issue 58138 has been marked as a duplicate of this issue. ***

*** Issue 67697 has been marked as a duplicate of this issue. ***

The missing possibility to use the Alt key for shortcuts is IMHO one of the big
shortcomings of OOo and above all one main reason why OOo cannot be be used
easily as an MS Office replacement. 

People who have to use Word and OOo Writer in coexistence want to use the same
key shortcuts for both applications and want therefore to customise OOo to use
the well-established word shortcuts. It is a hassle always having to switch
between different key sets if you switch applications. Word makes heavy use of
the Alt key, for instance when selecting heading levels. 

The popularity of the AltKeyHandler Macro (even though this software is a hassle
to install - impossible for non-nerds... - and use - because it is not
integrated in the normal ui functions for keyboard assignments and furthermore
often fails to function correctly) and the frequency of questions regarding this
issue in discussion groups clearly shows that this issue MUST FINALLY BE SOLVED.

The fact that under some OSs the Alt key seems to be unusable for applications
(Linux?) cannot be accepted as a reason not to support this key in other OS
versions of OOo. 

When will you finally act?

In addition to rollom's comment: solving this issue will also enable OOo to have
a Word compatibility mode. Such a compatibility mode can greatly help OOo's
acceptance, esp. in corporate settings (where re-training employees is a major
issue).

Remember that Word itself owes a large part of its success to its WordPerfect
compatibility mode (still available, at least partially, even in Word 2003).

changing component to "framework".

i think that would be very nice to have more hotkeys. you got my vote.

This is a ridiculous limitation.  Every key combination should be assignable.

...IMHO, what OOo really lacks is the ability to create custom key combinations,
like M$ office has. For example, in M$ office one can set some functions to
Ctrl+] or Ctrl+[, in OOo that's impossible. In M$ office you can even enter
something exotic like Crtl+Alt+Shift+NumPad5 as hotkey for some action, and that
will work.

This is not something critical, but it would be great if such functionality
would be implemented...

See also Issue 96184 where (on Mac OS X) 
alt-shift-left 
alt-shift-right 
alt-shift-up
alt-shift-down 
_MUST NOT_ manipulate tables. 

SBA: I regard the initial problem (i.e. >Alt> not working as solved in OOo 3.0.
Having this old issue open makes no sense. Set to "Worksforme".

Remove block link to issue 4579. THAT one is about special characters, THIS one
was more general about <Alt> key.
Closed.

SBA: Sorry, wrong issue solution. Reopened.

Adjusting summary. It is about the <Alt> key and that should be visible.

I spoke to PL. <Alt> combinations are possible to implement, but the
OpenOffice.org worls must be regarded as "Works on all platforms". Being reduced
to Windows and serving people looking for a free-to-use MS Office clone would
have meant that this issue would have been adressed long time ago.

But OOo is NOT a Windows-only free MS Office clone!

As said before, given the variety of opereating systems and window managers OOo
did, does and will run on (Welcome, Mac OS X, by the way), THAT many are already
used in total that it makes no sense to have OOo shortcuts that use <Alt>. They
would have to be altered for every system.

Anyone willing to document the existing options and limitations (taking ALL
platforms and window manager versions into account!!!) after having dropped the
"Windows only MS Office clone" idea)?

To me, it looks like "implementing the <Alt> key" would serve only the "one
platform only" user to spread his personal adjustments. On the next system, half
of them would lead to unexpected results.

Reassigned to requirements.

I am undecided to close the issue as wontfix. But I set it to wontfix as this is
the current opinion among those who contribute developer ressources here.

Set to "wontfix".

What a disappointment. I use OOo on Windows and Linux and have been waiting for
this option for years. We're not asking for the <Alt> keys to be pre-assigned or
anythying, just for the option to include any key combination.  I would invite
you to write a technical article using a large portion of the Greek alphabet
plus some mathematical operators, etc. without the option of hotkey combinations
for each symbol and decide whether this issue is important. <Alt>+a puts in an
"alpha" much easier that reaching for the mouse, moving over "Insert > Special
Character > selecting "Times" > selecting "Basic greek" > clicking on "alpha"
and closing the window... or remembering all of the key codes and trying that
route... Let's not forget that Ctrl+Shift, Super+Ctrl, Super+Shift,
Super+Ctrl+shift etc. also can have bindings in the window manager.  At least
the MW let's me select anything I want as a combination!  Not giving the option
doesn't help - it's just leaves us who are willing to sort out the WM and OOo
key bindings out in the cold.

i'm disappoint too about the "WONTFIX" decision.   :-(

people who do not need Alt+soemthing hotkey could easily leave those unassigned.

on the otehr hand, people who needed that hotkeys should be able to choose it.

OOo can use ALT key already, but you have to edit the configuration file
directly. This issue is not about the question whether OOo should use ALT-key
but it is about giving the user an UI to assign such shortcuts easier.

Of cause there are some OS which use some of the possible short cuts. But that
is no problem. We do not ask to use such short cuts as default in every OOo
version. But if a Windows wants to use ALT key, do not force him to edit
configuration file. If such a Windows user configures his keyboard, this will
not hurt any other user.

Besides I think, it is not a good way, to set an issue wich such a lot of votes
an duplicates to "wontfix" without discussing this on discuss@ux.openoffice.org.  

I can see no possible reason why this option should not be adopted. Flexibility
is usually the hallmark of OpenOffice and is better encouraged than opposed.

@sba:
Sorry, but your argument is completely stupid!
1) What does the Alt-key have to do with the operating system or platform? 
Anybody can get an industry-standard keyboard that features an Alt-key!
2) If platform-compatibility is the only thing you care about, then I suggest 
to remove the colors from all icons *immediately*, since some platforms might 
only support monochrome displays.

Bottom line: Enabling Alt-key-shortcuts improves the lives of (at least) 95% of 
all users, and doesn't do any harm to the rest. We've been waiting for this 
feature for more than 6 years now!!

@regina

could u please teach me how to edit the ini file to enable Alt+key hotkeys?

@sba

i respectfully ask you to reconsider your decision about this issue.

I totally agree with regina.

Besides everything, a statement like "I set it to wontfix as this is the current
opinion among those who contribute developer ressources here" is unacceptable.

What also is not acceptable is introducing new keyboard shortcuts with Alt
(Ctrl+Alt+N for notes in OOo3) on the one hand, but keeping users from
configuring that very shortcut via the UI on the other hand. If interoperability
were a concern, there shouldn't be hard coded shortcuts with Alt in the first place.

Note that there was or there is issue 32 (!), and issue 6342 which more or less
target on the same thing like this one here.

@tommy27

You find a German description on http://www.ooowiki.de/TastaturAnpassen, part
2.2 "Händisches Bearbeiten der Konfiguration". If you need a translation to
English please contact me directly, I'll try to help.

@regina

sorry, i don't understand german.
i think an english translation would be of interest for everybody round here.

@other users

please don't be harsh with sba.
i don't share his point of view about this issue but i think we should not 
offend him. let's keep the discussion on a civilized level

@tommy27, @everyone:

Hear, hear!  While I feel it is important on the one hand that sba and the other
OOo devs understand how their behaviour is coming across (apparently negatively
enough to quite anger some people following this thread), I feel it is equally
important that we keep this discourse civil.  So for anyone else possibly
frustrated with how things are happening, please express yourself politely.  One
can make a forceful point without including inflammatory language -- and, in
fact, any point will be all the more forceful if it is well received.  It is
worth noting that insults and flaming generally aren't.  

Cheers,

-- Erik Anderson

For stirring such debate/contention, I am partly to blame. 

Whilst no-one has requested from me an apology, I do feel that I should offer one. Sorry!

Clearly, this is an emotive subject. I assume that discussions will continue in 
irc://irc.freenode.net/#ooo_macport and in other channels.

Re http://wiki.services.openoffice.org/wiki/MacOSXPortMeetings I see a meeting, which will be logged, 
scheduled for Wednesday 26th November. 

I will aim to be present in IRC for that meeting.

Before the 26th: it should be good to gain … if not consensus, then at least *clarity of options*.

For now, quoting from another ticket:

> A quiet period of maybe twenty-four hours or more may be helpful. 

Respect, and peace,
Graham

I read many comments. Already a positive one on sba's question ? ( "Anyone
willing to document the existing options and limitations (taking ALL platforms
and window manager versions into account!!!) after having dropped the "Windows
only MS Office clone" idea)? " )
I offer to help with WinXP and Gnome on Linux. But I don't mind to do only one.
Those interested may contact me directly, if they so wish.
Ciao,
Cor

@tommy72

I have written an English guide and put it temporarily on
http://wiki.services.openoffice.org/wiki/User:Regina/MyDrafts#Customize_Keyboard

thanks regina

issue has been reopened.

thnak you sba for your understanding.

 

@ regina: thanks, 
http://www.diigo.com/annotated/00b38c25e61547ab61dd4d0f791a073e for an annotated view of your 
wiki page.

See also Issue 96235 

> Tools menu | Customize… | option to customise Keyboard is 
> missing if Tools menu is called whilst Start Centre is present

Being the original reporter I feel like I should respond to the recent comments
as well:

1. Please read my first comment. The Alt key combinations were just one out of
three examples, so please don't reduce the issue to just the "Alt+..." part.

2. tommy27 wrote
> people who do not need Alt+soemthing hotkey could easily leave those unassigned.
Exactly. Nobody would be hurt.
I might add that probably most users only work with OOo under one OS only and
therefore wouldn't even notice that the shortcut possibilities might be
different on different OS.

3. The discussion whether OOo is a M$ Office clone or not seems totally
irrelevant to me. Given that most OOo users are Windows users, offering a
Windows-only solution would still make sense imho. Even offering features only
available on Mac OS and/or Linux can make sense. There is imho no problem with
OS specific features in OOo as long as they are documented for the user.
Besides a lot of features in OOo are used only by a minority of people, and
compared to them the features suggested in this issue have (quite obviously) a
LOT of potential users.

100% agree with matthiasbasler

Ditto Matthias's comment.  And I point folks also to burg1's comment: 

  (as suggested on other issues before) drop the system of selecting a new 
  shortcut from a predefined list. Instead, let the users press the actual 
  shortcut themselves (and have OOo read it from the keyboard), as in M$ Word.

Some of sba's (and the other devs'?) concern seems to be with predefined OOo
shortcuts that might have to be different on different OSes.  While I see no
problem with that in principle (users of multiple OSes generally understand that
key bindings are perforce different on the different platforms), I also think
burg1's suggestion also has a lot of merit -- user-defined shortcut
possibilities should not be constrained to a predefined list of key options. 
Matthias's original posting likewise suggests this:

   c) Allow Shortcuts with language-specitic characters for foreign keyboards,
      as for example Strg+"Ö" or Alt+Shift+"å"

Basically, if the user has any particular key on the keyboard, they should be
able to use that for any user-defined keyboard shortcut -- be that "å" or Alt or
Apple or Hyper, or what have you.  

Concerns about window managers grabbing the keypress instead of OOo should be
addressed not by limiting OOo options, but rather by:

  1) OOo querying the WM and notifying the user if a certain combo is 
     unavailable (ideal, but much more complicated) 

     or

  2) simply warning the user in the keyboard shortcut definition dialog
     that the WM might already have certain key combos defined, such that 
     certain OOo keyboard shortcut possibilities might not work.

Restricting OOo shortcut options, though simpler to develop, does not strike me
as a particularly user-friendly approach.  Just my $0.02.

Cheers, -- Erik Anderson

> Opened: Sat May 11 19:59:00 +0000 2002

> ------- Additional comments from matthiasbasler 
> Sun Nov 16 13:10:43 +0000 2008 -------
> Being the original reporter I feel like I should respond to the
> recent comments as well:

Thanks to matthiasbasler for following this issue with such great
patience.

> just one out of three examples, so please don't reduce the issue to
> just the "Alt+..." part.

+1 to that plea.

> 2. tommy27 wrote
> 
>> people who do not need Alt+soemthing hotkey could easily leave
>> those unassigned.
> 
> Exactly. Nobody would be hurt.

+1 

> I might add that probably most users only work with OOo under one OS
> only and therefore wouldn't even notice that the shortcut
> possibilities might be different on different OS.

+1 

On this point: by coincidence at the weekend I took an unbiased
colleague from Plone community with me to 
irc://irc.freenode.net/#dev.openoffice.org 
and quizzed him for responses to scenarios in which shortcut keys
might not behave as expected if ever he found himself using OOo on a
platform other than his preferred Linux.

From this person: there were no cries of displeasure, which (to me)
supports the multi-platform *user* observation made by matthiasbasler. 

However: focusing on the multi-platform *application* there is a
critical observation:

>> tables being wrecked in OOo

-- and with such wreckage in mind (without any argument over recent
points in this issue 4756, and without detracting votes from this
issue) I refer readers to issue 96184 where -- on Mac OS X -- certain
shortcuts historically associated with tables _MUST NOT_ manipulate
tables.

With all due respect I suggest that developers should visualise some
balance between: 

a) the time and effort required to generally improve the
keyboard-related _options_ in OOo _without regard to platform_

b) the time and effort required to more urgently address _conflicts_
in which a traditional shortcut on a particular platform is found to
have a confusing or (worse) destructive effect on another platform.

Issue 96184 is just one example of a destructive issue. As use of OOo
3 spreads (we should welcome this spread) so I suspect that other
destructive issues may be found.

Already, as Erik draws attention to the quoted text concerning
accented characters, I realise that I _always_ use alt key combined with 
_a wide variety of letters on the keyboard_ to produce é è and 
_a wide variety of other on-screen characters_ that are not
keyboard-standard in my locale. 

Such conflicts may prove to be non-destructive (I have not
experimented, I should do) but in any case we should:

i) be prepared for further reports of such conflicts (I should not be
surprised to discover current and future tickets that Bugzilla
organisers may wish to treat as duplicates of this one)

and

ii) be prepared to deal gracefully with complaints -- respect each
other's wishes and requirements.

> ------- Additional comments from erikanderson3 
> Sun Nov 16 23:36:08 +0000 2008 -------

> Restricting OOo shortcut options, though simpler to develop, does
> not strike me as a particularly user-friendly approach.  Just my
> $0.02.

-- and in issue 96184 -- where a very common shortcut that's intended
for system-wide simple selection of words is found to have destructive
effect in OOo -- even when I aim to manipulate OOo configuration files
at file system level, I find no way of removing the offending shortcut.

(I assume that OOo mod2 is 'alt' on Mac as 
OOo mod2 is 'alt' on other platforms, yes?)

Incidentally, I did wonder whether 'destructive' is too strong a word
but all things considered I think it is fair. For someone like me who
copy types and uses the tab key and other keys within tables _without
looking at the screen_, it is truly destructive to find (when one does
look at the screen) that OOo has wrecked a previously good table. 

There are undo commands, true, but it feels very bad. 

Just my twopenneth. 

To close my comment, with a focus on the summary lines of issues 

> Expand shortcut possibilities (Use of <Alt> key is not offered)

-- this issue 4756 may be related to expansion of OOo _options_

-- my issue 96184 involves _conflicts_ without options, for which
workarounds (if any) may be terribly obscure.

While I appreciate this issue arouses the interest of the community, I would
like to remind my fellow users of OOo that holding discussions in issues is not
very productive. Instead, join the discuss@ux.openoffice.org mailing list, please.

@ mbayer: thanks, and apologies. In some other trackers discussion is encouraged but I see that in OOo it 
rapidly makes tickets difficult to follow. I find http://wiki.services.openoffice.org/wiki/HowTo_Join_the_User_Experience_Community and have 
completed step one of five. 

a question to sba and OOo developers.

is this enhancement (allow more hotkeys combinations) difficult to implement?

as regina said it's already possible to to it by editing the configuration file
directly. unfortunately this method it's not very user friendly.

it seems to me that if an expert user can do it manually, it should not be that 
hard for developers to implement this enhancement in the GUI.

Sorry, but isn't this issue a duplicate to issue 6342 (or vice versa ;-)) ?

Nevertheless, without going into all the details of the long discussion here: of
course the request to be able to use ALT for *custom* shortcuts is absolutely
valid. Moreover, we already use ALT for *preconfigured* shortcuts already, so I
can't see any reason not to support that in the configuration dialog.

The effort for this feature isn't extraordinarily, but it's also not low. A
rough estimation: 2-3 weeks development time plus QA.

well, if 2-3 weeks are needed i think it could be done for OOo 3.1 which is 
planned to be released at the end of March.

user waited so long for this isses which is one of the oldest here but a target 
milestone has not been decided yet.

@ Tommy27, Hi Tomy,
You write "i think it could be done for OOo 3.1" 
When you talk about your own agenda, you might be right ... only you just missed
the feature freeze date. Pls see.
http://wiki.services.openoffice.org/wiki/OOoRelease31
Sorry, but an excellent product needs good planing and testing.
Cor

u r right.
so, let's do it for 3.2   :-)

Discussion at http://n2.nabble.com/-tt2214450.html rephrases what was explicit in issue 93749 
(implicit in issue 96184): 

> Impossible to select words using the keyboard in OOo 3 for Mac OS X

Created attachment 59657 [details]
~/Library/Application\ Support/OpenOffice.org/3/user/config/soffice.cfg/modules/swriter/accelerator/en-US/current.xml

Created attachment 59658 [details]
~/Library/Application\ Support/OpenOffice.org/3/user/config/soffice.cfg/modules/swriter/accelerator/en-US/current.xml

Apple Human Interface Guidelines: The Keyboard
<http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGUser
Input/chapter_12_section_3.html>

Apple Human Interface Guidelines: The Keyboard: 
Extending Text Selection With the Shift and Arrow Keys
<http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGUser
Input/chapter_12_section_3.html#//apple_ref/doc/uid/TP30000361-TPXREF17>

Apple Human Interface Guidelines: Keyboard Shortcuts Quick Reference
<http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGKey
boardShortcuts/chapter_950_section_1.html>

http://wiki.services.openoffice.org/wiki/Documentation/How_Tos/Edit_Keyboard_Configuration_File 
(not tested on Mac) thanks to Regina.

Re issue 93749: four lines that must be corrected for 
Apple HIG for The Keyboard are probably at 
<http://www.openoffice.org/nonav/issues/showattachment.cgi/59658/current.xml> 
lines 68
      69
      95
      96

In HIG <http://tinyurl.com/apple-hig-ooo-93749> the 
four corresponding statements are:

> Shift–Option–Right Arrow
> To the end of the current word, 
> then to the end of the next word

> Shift–Option–Left Arrow
> To the beginning of the current word, 
> then to the beginning of the previous word

> Shift–Option–Up Arrow
> To the beginning of the current paragraph, 
> then to the beginning of the next paragraph

> Shift–Option–Down Arrow
> To the end of the current paragraph, 
> then to the end of the next paragraph 
> (include the blank line between paragraphs in 
> cut, copy, and paste operations)

---

Re issue 96184: sorry, I can not find the conflicting lines that must be corrected, but I will keep 
looking. The summary line there reminds us that the four key combinations 

> MUST NOT manipulate tables

I guess that I must identify the keyboard configuration file that relates to edition of tables. 

Sorry, I forgot that Bugzilla breaks long URLs. 
Here are the tinyurl equivalents:

Apple Human Interface Guidelines: The Keyboard
<http://tinyurl.com/apple-hig-the-keyboard>
<http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGUser
Input/chapter_12_section_3.html>

Apple Human Interface Guidelines: The Keyboard: 
Extending Text Selection With the Shift and Arrow Keys
<http://tinyurl.com/apple-hig-ooo-93749>
<http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGUser
Input/chapter_12_section_3.html#//apple_ref/doc/uid/TP30000361-TPXREF17>

Apple Human Interface Guidelines: Keyboard Shortcuts Quick Reference
<http://tinyurl.com/apple-hig-keyboard-shortcuts>
<http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGKey
boardShortcuts/chapter_950_section_1.html>

Created attachment 59659 [details]
grep -R "accel:mod2" ~/Library/Application\ Support/OpenOffice.org/3/user

Created attachment 59660 [details]
sudo grep -R "accel:mod2" /Applications/OpenOffice.org.app

Please ignore all 25th/26th January comments/attachments from me. Terribly sorry. Confusion with 
duplicates. I completely lost sight of issue 92224. Thanks to Regina for off-ticket steering me.

i think that after almost 9 years this issue deserve to be fixed.

please consider it for OOo 3.2 which is planned for september 2009
http://wiki.services.openoffice.org/wiki/OOoRelease32

Please don't be too optimistic with development goals.

If you want this issue to be fixed in one of the next releases of OOo, submit a
patch for it, or join the discuss@ux.openoffice.org mailing list in order to
make the UX team recommend this issue for development, please.

The UX mailing list is also the right place for all kinds of discussions about
this issue.

ALT-Keys are usable for shortcuts since quite some time. It's just the dialog
that wasn't changed (because it needed a complete rewrite). 

As keyboard shortcut configuration in 3.1 is now based on configuration files it
should be easier to provide a new shortcut configuration dialog. Perhaps someone
is motivated to write an extension?!

Just for clarification: ux has important tasks. Recommending issues for
development, however, is not one of those.

@mba: I don't see why this should be left to an extension, since this issue is
about making OOo configurable via OOo's GUI.

@cornouws: I'm sorry; I somehow must have misunderstood UX's role in the
Quarterly Reviews.

@mba

do u think that dialog could be rewritten in time for OOo 3.2? 
are 7 months from now enough to do it?

@mbayer:
no problem that you estimated ux@OOo's role higher - better than the other way
round, afaiac ;-)

@tommy27: 
code freeze is in about 5.5 months, but for an extension, that does not sound
impossible.
I didn't have time yet to look at the upcoming 3.1 ... but of course, for time
being, people who don't want to wait can edit the configuration files directly
as a solution.

ok, i hope that manual editing ot the shorcut configuration in OOo 3.1 would be 
a simple think and doens't require NASA engineering skills...

Just enabling the dialog to use "ALT" is easy, but we always thought that we
shouldn't leave the users alone with the situation that many configurable
shortcuts won't work because the system takes them over.

But if it was acceptable to ignore that for now, it would be possible to
implement "ALT"-Support soon.

nice news.

i'd be glad to use ALT shortcut at my own risk: u warnned me.

It is the status quo especially under Linux, that many of OOo's pre-defined
keyboard shortcuts cannot be used, because the window manager/ desktop manager
"catches" them: just think Ctrl+F1 ... Ctrl+F12 which switches to virtual
desktop 1 ... 12, or Ctrl+Tabulator which switches to the next virtual desktop,
and so on.

But I think this is not a reason against, but *for* making the Alt key available
for keyboard shortcuts configuration via the GUI: that way the user has more
choices to *avoid* a shortcut is being "catched" by the desktop manager.
Currently one is limited to shortcuts without the Alt key.

On the other hand, since there are some pre-defined keyboard shortcuts in OOo
which use the Alt key (think Ctrl+Alt+Cursor up, or the newly introduced
Ctrl+Alt+N), one has to be able to define an other shortcut for these actions
(e.g. in case the default is already in use for the desktop manager). Currently
one cannot configure these shortcuts at all.

Thus, I cannot see why OOo should preclude its users from defining/ undefining/
redefining keyboard shortcuts with the Alt key any longer.

*** Issue 6342 has been marked as a duplicate of this issue. ***

I will try to move that forward. This will comprise the change of the dialog and
moving existing "hard coded" shortcuts using "ALT" to the configuration files.

I will add support for "ALT" and "SHIFT ALT". We could also add "CTRL-ALT" and
"CTRL-SHIFT-ALT"...

There are a lot of other questions to solve (platform specific issues etc.) but
for now let's just solve the first problem with the missing support in the
dialog, everything else can be solved later.

assigning to myself

If Alt-key combinations are actually assignable through the config files at
present, is this also true for the other combinations in the original request
(ie. allowing shortcut combinations for symbols and keyboard-specific characters)?

In other packages, I regularly assign Ctrl+"<" and Ctrl+">" which (on some
keyboards) are Ctrl+Shift+"," and Ctrl+Shift+"."
Or Ctrl+"[" and Ctrl+"]".

Or should those be spun off into a separate issue, if the Alt question is resolved?

mba i appreciate very much that u decide to take care of this issue and that 
you set target milestone to OOo 3.2.
have a good work

@measdale: Using [ and > and such other keys is already tracked in issue 27081.

Just a comment from my side about how I see the platform problem.

VCL defines several keyboard modifiers. Since I can remember we always had MOD1
and MOD2 that e.g. on Windows map to CTRL and ALT. I don't know how many
modifiers we support nowadays on the different platforms, but I will find out.
In general we can offer access to all keys and modifiers that VCL shows us. To
my current knowledge this does not allow us to differentiate between the numeric
and the normal keyboard. And I also doubt that the configuration format can do
that. I have to find that out.

The different platforms will create the following problems:

- Some keys are "reserved" on platform X, but not on platform Y. That means that
we must not use them for predefined shortcuts (that's true already now!) and we
either leave it up to the user to find out if his desired personal shortcut in
OOo works on his platform or we can try to assist him. As the latter will be
quite some effort, I opt for not doing this, at least now.

- a user keyboard shortcut might work on one platform but not on another. This
can create a problem in a user profile shared between several platforms. I
consider this a very rare case and again would like to leave it up to the user
to define shortcuts in a way that they work on all used platforms.

@mba:

I strongly recommend that OOo be allowed to use *any* recognizable keycode,
beyond just Ctrl, Alt, and Shift.  I regularly make use of the Win and Alt-Gr
key modifiers, for instance.  

Concerns about desktop environments or window managers catching the keypresses
could be alleviated simply by notifying the user that this might happen.  If
someone is going so far as to customize their keyboard input, they are very
probably already savvy enough to deal with such concerns, provided they have a
hint at where to look to change their system settings.  

Another option for avoiding key combos that the DE or WM catch instead is to
have the user input the desired key combo in the dialog -- I believe this is
what MS Word already does, and is also what the KDE config dialogs do.  If the
desired key combo produces a strange effect instead of appearing in the OOo
dialog, it's pretty clear that that key combo is being caught.

Just my $0.02.

@mba:

Looks like we just missed each other.  Thank you for explaining about VCL; I
assume this is a library that OOo uses?  And I agree about leaving it to the
user to deal with conflicts, provided that the OOo dialog includes a caveat
explaining this.  Perhaps something simple like, 

"WARNING: Some key combinations might be reserved by your operating system."

fixed in cws mba32issues01

NICE! Thanks to all who helped to fix this!

does this mean is gonna be available in OOo 3.1 or OOo 3.2?

As the "target milestone" is 3.2 ...

OK, i will patiently wait till September 2009.

thanks for fixing it!!!

Just a remark: the configuration dialog will support "no modifier", SHIFT, CTRL,
SHIFT-CTRL, ALT, SHIFT-ALT, CTRL-ALT, CTRL-SHIFT-ALT with the following keys:

KEY_F1- KEY_F12, KEY_DOWN, KEY_UP, KEY_LEFT, KEY_RIGHT, KEY_HOME, KEY_END,
KEY_PAGEUP, KEY_PAGEDOWN, KEY_RETURN, KEY_BACKSPACE, KEY_INSERT, KEY_DELETE

The following keys are supported only with at least CTRL or ALT pressed:

KEY_0 - KEY_9, KEY_A - KEY_Z, KEY_SPACE, KEY_ADD, KEY_SUBTRACT, KEY_MULTIPLY,
KEY_DIVIDE 

Several complaints have been given that the list of keys should be extended
also. While I agree to that I would like to fix that in a second step (unless
someone came up with undisputed(!) list now). This will be covered by issue 27081.

Excellent. This was a showstopper for me. I'm a keyboard and macro person and
not having these keyboard meant that changing to Writer from Word (which I would
like to do) would mean more compromises than I'm willing to make.

Thanks to developers and all other contributors for progressing this :)

For reference: 
http://download.openoffice.org/next/
http://eis.services.openoffice.org/
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fmba32issues01 

… and until integration occurs, I'll probably stop thinking about shortcuts (the shortcuts shown in the 
Customize dialogue are different from the actual shortcuts, but that's a different bug ;)

Thanks to developers and all other contributors for progressing this :)

For reference: 
http://download.openoffice.org/next/
http://eis.services.openoffice.org/
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fmba32issues01 

… and until integration occurs, I'll probably have to stop thinking about shortcuts (what's shown in the 
Customize dialogue contradicts the actual shortcuts, but that'll be a different bug ;)

Can you explain where you see contradictions? Some examples might suffice.

Issue 101133 … looking at it now, may be a duplicate of this issue 4756. 

Shall I upload a build for testing?

@mba: very kind, thanks, but don't build for me alone; I'm happy to wait for a relevant build to appear at http://download.openoffice.org/next/

O.K., so let's wait with judging about issue 101133 until then.

Hint for QA: the new functionality is described in #desc90.

Accessing shortcuts can be done by putting focus into the large listbox and
pressing the desired key combination.

seen in cws mba32issues01 - verified

Issue 3.2 has been scheduled for end of november.

I've also heard rumors about releasing a 3.1.1 between the incoming 3.1 (march 
7th) and future 3.2

Is there any chance we could  see the new hotkeys feature in the 3.1.1 instead 
of the 3.2?

waiting till november is very hard...

We don't add new features to "micro" releases, sorry.

ok, thanks 4 feedback.
i'll wait till november '09

Integrated into DEV300m48 - closing
You may download from:
ftp://ooopackages.good-day.net/pub/OpenOffice.org/MacOSX/Dev_DEV300_m48/
(Other builds are not yet available public.)

Verifying: I see the new behavior in DEV300_m52 (Linux) under Tools > Customize. 

I could assign a function to the Alt+G key chord and use it; deleting the custom
entry seems ok as well.

Nice!

works fine on my WinXP with DEV300m52
Thanks!

nice to see that the new feature has been correctly implemented!!!

thanks to the developers!!!

nice to see that the new feature has been correctly implemented!!!

thanks to the developers!!!

Thanks for the flowers. :-)

Nice to see that this has been fixed in 3.2. I can't wait for Ubuntu to 
incorporate that release.

this issue fix was one of the most useful updates of OOo 3.2.
thanks 4 fixin' it