Bug 126888 - Ctrl+Shift+; shortcut to insert current time stopped working
Summary: Ctrl+Shift+; shortcut to insert current time stopped working
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
: 125306 149331 (view as bug list)
Depends on:
Blocks: Shortcuts-Locale
  Show dependency treegraph
 
Reported: 2019-08-13 16:26 UTC by Martin
Modified: 2024-08-15 11:28 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin 2019-08-13 16:26:32 UTC
Description:
The shortcut for inserting current time stopped working. When selecting the option from the menu ( Insert / Time) it works fine.

Steps to Reproduce:
1.Create a new spreadsheet
2.when in cell press ctrl+shift+;


Actual Results:
semicolon character is inserted into the cell

Expected Results:
current time is inserted into the cell


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.3.0.4
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 4; OS: Linux 5.2; UI render: GL; VCL: kde5; 
Locale: en-GB (en_GB.utf8); UI-Language: en-US
Calc: threaded
Comment 1 Jean-Baptiste Faure 2019-08-13 20:48:23 UTC
Reproducible on LibreOffice 6.3.1.0+ built at home under Ubuntu 18.04 x86-64.

In my case, the actual results is nothing, this key combination does nothing.

Best regards. JBF
Comment 2 Xisco Faulí 2019-08-14 09:18:53 UTC Comment hidden (obsolete)
Comment 3 Martin 2019-08-14 15:37:37 UTC
(In reply to Xisco Faulí from comment #2)
> 
> Does it happen if you launch LibreOffice from commandline using
> 'SAL_USE_VCLPLUGIN=gtk3 soffice' ?

The shortcut works fine when setting this env variable
Comment 4 Jean-Baptiste Faure 2019-08-14 17:14:17 UTC
(In reply to Xisco Faulí from comment #2)
> [...]
> Does it happen if you launch LibreOffice from commandline using
> 'SAL_USE_VCLPLUGIN=gtk3 soffice' ?

I already use the plugin GTK3 and it does not work with any version I can test : 6.1, 6.2, 6.3 and master.
Could it be possible that the problem is linked to the use of an AZERTY keyboard?

Best regards. JBF
Comment 5 Michael Weghorn 2019-08-14 20:15:49 UTC
I cannot reproduce on Debian testing with KDE Plasma, German keyboard layout:

Version: 6.4.0.0.alpha0+
Build ID: fa774e16b1dfe4844ec5eb3f9372d6468f6b8a56
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

neither with the package provided in Debian testing (libreoffice 1:6.3.0-2):

Version: 6.3.0.4
Build ID: 1:6.3.0-2
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded


@Martin: What is your keyboard layout that works with SAL_USE_VCLPLUGIN=gtk3, but not with the "kde5" VCL plugin?

(In reply to Jean-Baptiste Faure from comment #4)
> I already use the plugin GTK3 and it does not work with any version I can
> test : 6.1, 6.2, 6.3 and master.
> Could it be possible that the problem is linked to the use of an AZERTY
> keyboard?

That's possible. Can you try whether it works as expected when you configure another keyboard layout?
Comment 6 Martin 2019-08-15 08:00:31 UTC
(In reply to Michael Weghorn from comment #5)
> 
> @Martin: What is your keyboard layout that works with
> SAL_USE_VCLPLUGIN=gtk3, but not with the "kde5" VCL plugin?
> 

Hi Michael,

I tested for polish ( pl ) and english ( us ). In both cases the issue goes away when I run libreoffice using the above mentioned env variable.

Cheers
Comment 7 Martin 2019-08-15 08:05:18 UTC
(In reply to Martin from comment #6)
> (In reply to Michael Weghorn from comment #5)
> > 
> > @Martin: What is your keyboard layout that works with
> > SAL_USE_VCLPLUGIN=gtk3, but not with the "kde5" VCL plugin?
> > 
> 
> Hi Michael,
> 
> I tested for polish ( pl ) and english ( us ). In both cases the issue goes
> away when I run libreoffice using the above mentioned env variable.
> 
> Cheers

Out of curiosity I tried german layout (swiss: ch). It behaves the same way as us and pl. That is, when I run libreoffice using SAL_USE_VCLPLUGIN=gtk3 the shortcut works as expected.
Comment 8 Jean-Baptiste Faure 2019-08-15 15:35:01 UTC
I tested the 4 following possibilities, none of them works :
1/ vclplugin=gtk3 (my default)
2/ vclplugin=gtk
3/ vlcplugin=gen
4/ English keybord layout (qwerty)

I can redefine the shortcut to "Ctrl+Shift+," or "Ctrl+shift+H" (or any other letter), but not to "Ctrl+Shift+'"
With the key ";" the only 3-keys shortcut that works is "Ctrl+Alt+;" 
"Shift+Alt+;" does not work too.

Best regards. JBF
Comment 9 Xisco Faulí 2019-08-15 18:35:47 UTC
*** Bug 125306 has been marked as a duplicate of this bug. ***
Comment 10 Michael Weghorn 2019-08-20 15:51:31 UTC
(In reply to Martin from comment #6)
> I tested for polish ( pl ) and english ( us ). In both cases the issue goes
> away when I run libreoffice using the above mentioned env variable.

Thanks. I can reproduce now if I switch keyboard layout to US.

What both US and PL keyboard layouts have in common is that the ";" character is typed by just pressing a single key, while DE layout requires typing Shift in addition to the key otherwise typing ",'.
For the US layout, pressing Shift in addition to the ";" key will result in ":".

This is what **might** be happening (didn't check yet): Instead of the three key codes for Ctrl + Shift + ';', only the key codes for Ctrl + ':' are sent,
(i.e. the conversion
    Shift+';' = ':'
takes place), and the shortcut then no longer matches.
Comment 11 Martin 2019-08-20 16:02:13 UTC
(In reply to Michael Weghorn from comment #10)
> (In reply to Martin from comment #6)
> 
> Thanks. I can reproduce now if I switch keyboard layout to US.
> 
> What both US and PL keyboard layouts have in common is that the ";" [...]

Actually, physically PL keyboard looks exactly like the US one. The way you get characters specific to Polish language is by key combination of right Alt key and a letter (eg. RightAlt+a).

I'm guessing that if it gets fixed for US layout, it'll also be fixed for other derived from it.
Comment 12 Michael Weghorn 2019-08-20 16:30:40 UTC
I quickly debugged into the code and at a quick glance at 'Qt5Widget::handleKeyEvent', it seems like this is passed in the QKeyEvent:

* for DE layout: key: Semicolon; modifiers: Shift + Ctrl
* for US layout: key: Colon; modifiers: Shift + Ctrl

(In reply to Martin from comment #0)
> Actual Results:
> semicolon character is inserted into the cell

@Martin: Does this actually insert a semicolon (";") character or a colon (":")? If it's actually a semicolon, that somewhat contradicts my expectations.

@JBF: What keyboard layout are you using? Does the behaviour change when you switch e.g. to US layout?
Comment 13 Martin 2019-08-20 16:33:39 UTC
(In reply to Michael Weghorn from comment #12)
> I quickly debugged into the code and at a quick glance at
> 'Qt5Widget::handleKeyEvent', it seems like this is passed in the QKeyEvent:
> 
> * for DE layout: key: Semicolon; modifiers: Shift + Ctrl
> * for US layout: key: Colon; modifiers: Shift + Ctrl
> 
> (In reply to Martin from comment #0)
> > Actual Results:
> > semicolon character is inserted into the cell
> 
> @Martin: Does this actually insert a semicolon (";") character or a colon
> (":")? If it's actually a semicolon, that somewhat contradicts my
> expectations.
> 
> @JBF: What keyboard layout are you using? Does the behaviour change when you
> switch e.g. to US layout?

You're right, it's a colon (:). Sorry abut the confusion.
Comment 14 Jean-Baptiste Faure 2019-08-20 16:44:01 UTC
(In reply to Michael Weghorn from comment #12)
> [...]
> @JBF: What keyboard layout are you using? Does the behaviour change when you
> switch e.g. to US layout?

Keyboard layout: Français(Variante)
No change if I use an English/US layout (see comment #8)

Best regards. JBF
Comment 15 Michael Weghorn 2019-08-20 17:14:06 UTC
Thanks for the clarifications.

I checked with a small sample Qt application that the values for the keys for QWidget::handleKeyEvent are submitted as described in comment 12 (i.e. Colon for US, Semicolon for DE layout).

I wouldn't say that this by itself is wrong, and it seems a bit unfortunate that the choice of allowed/used keyboard shortcuts including the Shift key allows for such ambiguous situations...

Right now, I don't really have a good idea on how to deal with this. It probably makes sense to take a closer look what e.g. gtk3 does (i.e. both the gtk framework and the LO gtk3 VCL plugin).
Comment 16 Martin 2019-08-20 17:18:16 UTC
(In reply to Michael Weghorn from comment #15)
> Thanks for the clarifications.
> 
> I checked with a small sample Qt application that the values for the keys
> for QWidget::handleKeyEvent are submitted as described in comment 12 (i.e.
> Colon for US, Semicolon for DE layout).
> 
> I wouldn't say that this by itself is wrong, and it seems a bit unfortunate
> that the choice of allowed/used keyboard shortcuts including the Shift key
> allows for such ambiguous situations...
> 
> Right now, I don't really have a good idea on how to deal with this. It
> probably makes sense to take a closer look what e.g. gtk3 does (i.e. both
> the gtk framework and the LO gtk3 VCL plugin).

I see.

Has something changed? This shortcut worked fine before I installed the latest version of Libre Office. I've been using this shortcut for close to two years now.
Comment 17 Michael Weghorn 2019-08-21 10:35:46 UTC
(In reply to Martin from comment #16)
> Has something changed? This shortcut worked fine before I installed the
> latest version of Libre Office. I've been using this shortcut for close to
> two years now.

The "kde5" (or "kf5") VCL plugin ("frontend") which is used on Plasma and LXQt by default, was only introduced with LibreOffice 6.2, so you were probably using "gtk3" or "gtk3_kde5" VCL plugin previously, which still works the same (as comment 3 says).

Another "interesting" case is that Ctrl+Shift+; inserts current time, while Ctrl+; inserts the date.
I see no way to actually insert the date like this when used e.g. with German keyboard layout , since typing ";" requires pressing Shift+, - so the time is inserted instead of the date. And I currently can't up with any "technical" solution to actually make both of them work at the same time, other than changing keyboard shortcuts (depending on layout??).
Comment 18 Buovjaga 2020-06-08 18:15:22 UTC
(In reply to Michael Weghorn from comment #17)
> The "kde5" (or "kf5") VCL plugin ("frontend") which is used on Plasma and
> LXQt by default, was only introduced with LibreOffice 6.2, so you were
> probably using "gtk3" or "gtk3_kde5" VCL plugin previously, which still
> works the same (as comment 3 says).

So this can not be called a regression, removing keywords.
Comment 19 m_a_riosv 2022-06-01 17:44:24 UTC
*** Bug 149331 has been marked as a duplicate of this bug. ***
Comment 20 Olivier Mehani 2023-07-18 11:33:48 UTC
I have this issue (only Insert/Time, not Insert/Date) with 

Version: 7.5.4.2 (X86_64) / LibreOffice Community
Build ID: 50(Build:2)
CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
7.5.4-3
Calc: threaded

On ArchLinux/amd64, with GNOME 44.3 and a Dvorak(intl, with dead keys) layout.

It only started happening recently, and wasn't present in earlier 7.5 minor.

Using `SAL_USE_VCLPLUGIN=gtk3 soffice` doesn't fix the issue.

Note that, unlike the original report, the Ctrl+Shift+; shortcut does nothing. It does not output a ";" in the current cell.
Comment 21 Colin 2023-07-18 11:45:21 UTC
Version: 7.4.7.2 (x64) / LibreOffice Community
Build ID: 723314e595e8007d3cf785c16538505a1c878ca5
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: sv-SE (en_GB); UI: en-GB
Calc: threaded

It has now changed for me also. I no longer get the semicolon ";" - just a blank cell. Still a Scandinavian keyboard.
FWIW If I insert a time using the menu insert time or the ribbon button into a blank cell so it is preformatted as a time value there are two? responses.
If the time is still present no operation so the time remains
If the time valkue is expunged first then still no operation the blank cell remains.
Comment 22 Olivier Mehani 2023-07-18 12:50:33 UTC
(In reply to Olivier Mehani from comment #20)
> On ArchLinux/amd64, with GNOME 44.3 and a Dvorak(intl, with dead keys)
> layout.

The same happens with a us(intl, with dead keys), and just plain us layout (no dead keys)
Comment 23 Cor Nouws 2024-04-15 07:42:40 UTC
(In reply to Michael Weghorn from comment #10)
> This is what **might** be happening (didn't check yet): Instead of the three
> key codes for Ctrl + Shift + ';', only the key codes for Ctrl + ':' are sent,
> (i.e. the conversion
>     Shift+';' = ':'
> takes place), and the shortcut then no longer matches.
seems confirmed by what others report, e.g. comment 11.
Comment 24 Colin 2024-04-15 07:52:52 UTC
(In reply to Cor Nouws from comment #23)
> (In reply to Michael Weghorn from comment #10)
> > This is what **might** be happening (didn't check yet): Instead of the three
> > key codes for Ctrl + Shift + ';', only the key codes for Ctrl + ':' are sent,
> > (i.e. the conversion
> >     Shift+';' = ':'
> > takes place), and the shortcut then no longer matches.
> seems confirmed by what others report, e.g. comment 11.

On a Scandinavian keyboard the semicolon is shift comma and the colon is shift fullstop(point) so the shift modifier should be the desired semicolon. The solution probably needs to rationalise the potential "double" shift implication
Comment 25 studog 2024-08-13 05:34:03 UTC
I suffered this issue, and suspected a global input interceptor. It turned out to be an issue in LibreOffice Calc; the "shift ctrl :" shortcut needs to be assigned to "Insert Current Time" **not** "shift ctrl ;".  
  
See more details at: https://forums.linuxmint.com/viewtopic.php?p=2509498#p2509498
Comment 26 Colin 2024-08-13 07:04:38 UTC
(In reply to studog from comment #25)
> I suffered this issue, and suspected a global input interceptor. It turned
> out to be an issue in LibreOffice Calc; the "shift ctrl :" shortcut needs to
> be assigned to "Insert Current Time" **not** "shift ctrl ;".  
>   
> See more details at:
> https://forums.linuxmint.com/viewtopic.php?p=2509498#p2509498

Unfortunately, not all keyboards are the same. Most European and Latin Asian keyboards have the colon and semi-colon keys as adjacent keys on the bottom row [Shift] stop and [shift] comma, whereas US keyboards use the [Shift] modifier on a single middle row key which is predominantly a key for other languages' special vowels.

The modification you desire may well cause grief for a substantial portion of the 200 million other users who already leverage the unique mapping of those vowels for other user keyboard shortcuts.
Comment 27 studog 2024-08-14 15:50:31 UTC
(In reply to Colin from comment #26)
> Unfortunately, not all keyboards are the same. Most European and Latin Asian
> keyboards have the colon and semi-colon keys as adjacent keys on the bottom
> row [Shift] stop and [shift] comma, whereas US keyboards use the [Shift]
> modifier on a single middle row key which is predominantly a key for other
> languages' special vowels.
> 
> The modification you desire may well cause grief for a substantial portion
> of the 200 million other users who already leverage the unique mapping of
> those vowels for other user keyboard shortcuts.

My keyboard layout, language and locale are all correct and set for US English. In this setup either "shift ctrl ;" should function as expected to "Insert Current Time", or, "shift ctrl :" should also be set to "Insert Current Time".  
  
Said another way...

In US English keyboard layout "shift ctrl ;" is an impossible keychord, except, by convention, keychords that use shift often refer to the non-shifted character on the key. If LibreOffice wants to abandon the convention, that's fine, but breaking normal usage to do so is wrong.
Comment 28 ady 2024-08-14 16:30:16 UTC
All the reports about keyboard shortcuts aimed at inserting date and/or time will keep showing up in one way or another, until the shortcuts (for any UI language, any OS language, and any keyboard layout) are implemented as:

* "Insert current date"
[CTRL]+ "whichever method to type a semicolon character, no matter its location on the keyboard layout."


* "Insert current time"
[CTRL]+ "whichever method to type a colon character, no matter its location on the keyboard layout."

If the specific keys (semicolon and colon) are introduced by adding [SHIFT], or [AltGr], or no other auxiliary keys, or any other auxiliary key, it should not matter.

As for the way it is expressed, we (users) do not care, as long as it is clearly understood, and that it works consistently.

It's been years, with multiple reports, depending on keyboard layout, OS language, OS type, OS version, input language, LO UI language, LO version...
Comment 29 Colin 2024-08-14 17:16:02 UTC Comment hidden (noise)
Comment 30 ady 2024-08-14 19:11:36 UTC Comment hidden (noise)
Comment 31 Colin 2024-08-14 19:19:02 UTC Comment hidden (noise)
Comment 32 Olivier Mehani 2024-08-15 08:56:06 UTC Comment hidden (noise)
Comment 33 Colin 2024-08-15 10:44:43 UTC Comment hidden (noise)