[upstream] Ctrl-Shift-u underline interferes with gtk+ shortcut

Bug #163610 reported by Matthias
48
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenOffice
Won't Fix
Unknown
openoffice.org-l10n (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: openoffice.org

This bug applies especially to all localizations which have a Ctrl-Shift-u shortcut by default.
I have only verified it on the German localization, where Ctrl-Shift-u is underline in the OpenOffice-Writer

Since Version 2.10 GTK+ uses this shortcut for entering unicode characters. Compare the release notes:

http://www.gnomefiles.org/version.php?soft_id=370
> Version: 2.10 - Released on 2006-07-03 07:16:18 UTC
> * The hexadecimal Unicode input feature has been reworked. It no longer blocks the use of the sixteen Ctrl-Shift- key sequences. Now
> it only uses Ctrl-Shift-u.

So pressing Ctrl-Shift-u results in entering an underlined unicode character (and thus e.g. deleting any selected text)

Tested with ubuntu 7.10 (gutsy) (32 and 64bit)

Chris Cheney (ccheney)
Changed in openoffice.org:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
M Henri Day (mhenriday) wrote : Re: [Upstream] [hardy] Ctrl-Shift-u shortcut is impossilbe because of competing gtk+ shortcut

I have previously (up to and including Ubuntu 7.04) been able to use «Ctrl+Shift+u, hex code, space» to enter Unicode glyphs, e g, «Ctrl+Shift+u,5000, space» resulted in the Chinese glyph «倀». After the SCIM update to version 1.4.7, however, this is no longer possible ; when attempting to enter the glyph, I get «5000 » instead. This is the case both on Ubuntu 7.10 and the alpha 6 version of 8.04. SCIM is a wonderful feature and required for the type of work I do, but I should also like to have the opportunity to enter Unicode glyphs ad libitum. Can this interference - as I presume it is - be resolved, or another key pattern assigned to Unicode glyphs ?...

Henri

Chris Cheney (ccheney)
Changed in openoffice:
importance: Undecided → Unknown
status: New → Unknown
Changed in openoffice:
status: Unknown → New
Chris Cheney (ccheney)
Changed in openoffice.org:
status: Confirmed → Triaged
Revision history for this message
M Henri Day (mhenriday) wrote :

In the current version of Hardy, the result of the operation I mentioned above differs depending upon the SCIM settings ; thus, for example, if the input editor is set to input in Latin glyphs, entering «Ctrl+Shift+u» in the gedit text editor results in an underlined «u». When I continue by entering «5000», the result I see in the text editor is an underlined «u5000». If I then press the space bar, the graph «倀» does, in fact, appear. Thus, in contrast to the situation in March, when I first posted this bug notice, it *is* possible to use the «Ctrl+Shift+u» shortcut to input Unicode glyphs - it is merely that now one first sees an underlined «u» and then an underlined «u-hexcode» in the editor before the space bar is pressed, which was not the case previous to Feisty, when nothing at all was seen until the space bar was pressed. Note, however, that if SCIM is set to «Other - UIM direct», entering «Ctrl+Shift+u;5000» results in «5000» (no «u», no underlining) being seen in the text editor, precisely as described above. But since Unicode glyphs can now be successfully be entered as long as SCIM is set to Latin text, I think the status of this bug can be changed to resolved. I have checked this in OOo Writer, and it works in the same manner there....

Henri

Revision history for this message
Michael Nagel (nailor) wrote :

but it cannot be seen resolved because you are unable to select text and underline it via keyboard, because pressing alt-shift-u will delete your selected text and replace it with an underlined u...

so from this point of view it remains unresolved...

Revision history for this message
Chris Cheney (ccheney) wrote :

I didn't claim the bug was resolved, your bug (311164) was a duplicate of this bug (163610) which has already been submitted upstream. I just marked your bug as the duplicate, which it is.

Revision history for this message
Michael Nagel (nailor) wrote :

copied information over from duplicate:

------------------
I don't think this is a bug, but rather a gtk-"feature". Ctrl+Shift+u is used to provide an unicode-number for special-characters (e.g. U+00A9 for the copyright-sign). Try the same in gedit, it's default in every gtk-app.

Beginning with gtk+2.10, only the ctrl+shift+u shortcut is affected, before it was ctrl+shift+a-f (or so), where e.g. ctrl+shift+f (bold in ooo) did not work. The only way to "fix" this would be, to disable the gtk-input-method in favour of x-input-method.

An easier workaround would be to change the shortcut from ctrl+shift+u into e.g. ctrl+u.
------------------

Revision history for this message
Chris Cheney (ccheney) wrote :

It's a bug in OOo that it uses bad shortcuts that conflict with the desktop it is running on, which is why it is reported as an OOo bug in the first place.

Chris
Ubuntu OOo Maintainer

Revision history for this message
Chris Cheney (ccheney) wrote :

Michael,

Thank you for consolidating these duplicate bug reports.

Chris

Changed in openoffice:
status: New → Won't Fix
Revision history for this message
Robert Roth (evfool) wrote :

This issue seems to be somewhat related with the ancient bug #24346, mentioning the inconsistency caused by localizing keyboard shortcuts. Could this be a duplicate of that? This is only a part of that bug, that is an overall issue, this is a concrete example of the problem reported there.

Revision history for this message
Björn Michaelsen (bjoern-michaelsen) wrote :

Please reopen against libreoffice-l10n, if still relevant.

Changed in openoffice.org-l10n (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.