welcome screen keyboard shortcuts strange behavior

users
#1

When opening LibreOffice 5.0.6.3 under Windows ("soffice.exe"), there
are shortcut keys that are supposed to perform a certain task, such as
creating a new Writer Document. The relevant keys are shown as
underlined (e.g. the letter "D" for a new Writer Document).

The same shortcuts are also available in older versions. When I was
using the older 4.4.x branch, these shortcuts were working correctly;
after opening LibreOffice ("soffice.exe") I was able to launch Writer
by simply pressing "d". After updating to 5.0.6.3, this same effect
(opening Writer) is _not_ being triggered by the same action (pressing
"d" on the keyboard).

Now, after opening LibreOffice 5.0.6.3 ("soffice.exe") if I open Writer
(by other means, instead of using the keyboard shortcut) at least once
and then close Writer again (thus, going back to the initial
LibreOffice screen), then the keyboard shortcuts start to work
correctly; i.e. pressing "d" will open Writer.

These shortcut keys will continue to work correctly, until I close
LibreOffice completely. When opening LibreOffice 5.0.6.3
("soffice.exe") again, the shortcuts will not work unless I open one of
the components (such as Writer) at least once, and then close the
component, as I described before.

Searching the web, I tried to use an adequate set of terms that would
lead me to some information about the matter, but I failed.

1_ Is this a known issue?

2_ Can it be replicated by other users?

3_ Is it present under other OS?

4_ Is there some new option that might have changed the prior behavior?
Perhaps the specific key's combinations have changed in some way?

5_ Is it still present in newer versions (such as the 5.1.x branch)?

6_ Is there a bug report already opened?

TIA,
Ady.

#2

@Ady, *

I just did a clean /a admin install of LO 5.0.6.3 x64 on Windows 8.1

While in the StartCenter -- icon bar on left or in the thumbnail preview
pane-- with this new user profile the .UI accelerators for the StartCenter
(<alt>+o, r, e, d, s, p, r, m, a, l, and x) all function as intended.

There has been a change now implemented for the 5.0 releases (not sure
which commit) where the <alt> key toggles from the StartCenter to the Main
menu bar. The <alt> key now has the toggle focus action that F10 alone
previously had.

Even so, the main Menu accelerators (<alt>+f, t, and h) still open their
assigned menus.

So, really do not see any issue here.

And of course this is mute, as 5.0 is entering EOL with the 5.0.6.3 release.
For the current 5.1 releases, the StartCenter accelerators have been
reassigned--any dev work or BZ reporting should be against that branch.

Stuart

#3

On Fri, May 13, 2016 at 7:48 PM, V Stuart Foote

@Ady, *

I just did a clean /a admin install of LO 5.0.6.3 x64 on Windows 8.1

While in the StartCenter -- icon bar on left or in the thumbnail preview
pane-- with this new user profile the .UI accelerators for the StartCenter
(<alt>+o, r, e, d, s, p, r, m, a, l, and x) all function as intended.

There has been a change now implemented for the 5.0 releases (not sure
which commit) where the <alt> key toggles from the StartCenter to the Main
menu bar. The <alt> key now has the toggle focus action that F10 alone
previously had.

Even so, the main Menu accelerators (<alt>+f, t, and h) still open their
assigned menus.

So, really do not see any issue here.

And of course this is mute, as 5.0 is entering EOL with the 5.0.6.3 release.
For the current 5.1 releases, the StartCenter accelerators have been
reassigned--any dev work or BZ reporting should be against that branch.

Stuart

--

Thank you very much for your reply.

In my prior email, I forgot to mention that testing with "Alt+d" generates
the same behavior as with "d" alone; i.e. Writer 5.0.6.3 initially fails to
open.

Based on your comments, I performed the following test:

1_ With all LibreOffice closed, I opened LibreOffice 5.0.6.3 ("soffice.exe").
2_ Press F10. The menu receives focus.
3_ Press F10 again. The sidebar receives focus.
4_ Press "d". Writer is successfully opened.

I repeated the test, replacing F10 with Alt. Same behavior.

I repeated the test, replacing "d" with "Alt+d". Same behavior.

So my conclusion would be that the difference between the 4.4.x (and older)
branch(es) and 5.0.6.3 is that the initial focus has changed. Wherever the
initial focus is located in 5.0.6.3, the shortcut keys shown in the sidebar
are _not_ valid for it. Changing the focus to the sidebar will allow the
shortcuts to be correctly used.

I am not ready to update to 5.1.x yet. I hope the shortcut keys will be
valid immediately after opening LibreOffice (as it used to be in the 4.4.x
and older branches), instead of having to move the focus first. Whether this
means expanding the validity of the shortcut keys to additional areas of the
user interface, or changing the default initial focus to be located on the
sidebar, or some other alternative, I do not know.

Thank you,
Ady.

#4

Hi :slight_smile:

Thanks for seeking feedback from here before posting a
bug-report/feature-request. As you know, sometimes a change in behaviour
is required to consolidate inconsistent behaviour or to smooth out other
coding, or to keep-up with current trends in other, similar(ish) programs
or happens somewhat unintentionally. Usually any such changes are noted in
the change-log, neatly re-written at;
https://www.libreoffice.org/download/release-notes/

LibreOffice/OpenOffice is over 10 years old and a lot has changed in that
time. Hopefully the newer ways are easy to adapt to and are an
improvement. Where that is not the case it's fairly easy to post a
bug-report although carefully phrasing it as a feature-request seems to
have more chance of attracting interest.

So, please give it a fair go but feel free to post a
bug-report/feature-request now that you've narrowed it down to being a
change-of-focus issue.

Good luck and regards from
Tom :slight_smile:

#5

I am unsure whether I should open a bug report / enhancement request,
considering that I have not tested 5.1.x.

From Stuart's reply, I understood that some things have been changing
in the Startup Screen, and that they are still changing. I would guess
that having a request for enhancement without actually reporting the
behavior of the most current / updated release (5.1.x) would not
attract enough attention and would probably be considered an
incomplete report.

Additionally, the only version from the 5.0.x branch I have tested is
5.0.6.3, so the (initial) version number in which the behavior changed
would not be accurate (enough).

If I cannot test the current (5.1.x) behavior (because I am not ready
to update yet), how would I report a bug / request an enhancement? I
mean, I could, but it would probably be mostly ignored, wouldn't it?

I think it might be useful, before actually opening a request for
enhancement, if someone could try to replicate the behavior / tests in
the 5.1.x branch and report it here. Also, testing under other OSes
might be relevant too.

With more details and tests from different users under diverse
circumstances / versions, a request for enhancement might be more
relevant and taken more seriously.

Finally, I am still unsure whether this is really a request for
enhancement or rather a bug report with a regression between 4.4.x and
5.0.x, considering that the expected behavior was working correctly in
4.4.x, it is (partially) broken in 5.0.6.3 (and maybe in all the 5.0.x
branch), and I see no advantage from the users' perspective to not
have these shortcuts working from the start. Comments about this
matter would be very welcome.

I hope users can attempt these simple tests and report their results,
including the OS and version information, so a potential bug report /
request for enhancement would be actually worth.

TIA,
Ady.

#6

Hi :slight_smile:
Yes, i agree.

It's not worth posting bug-reports against any in the 5.0.x branch now.
Finding the exact release where the change happened is not hugely useful,
especially right now. It might be useful sometime after the
bug-report/feature-request is opened.

It is always difficult to gather everything that might be useful in the
first post of a bug-report/feature-request. It is probably better to just
"post early and update often" so keep the initial
bug-report/feature-request really short. Just a tiny post and maybe even
state "More to follow ..." at the bottom of the post so that any dev or
triager can see that they don't have to type in a request for further info.

There are so many bug-reports that the chances are that you will have been
able to add additional information before anyone gets a chance to read
yours. As you add information over the next couple of weeks that might
"bump the thread" a bit too try to keep it nearer the top but try to avoid
flagrant abuse of that. A little use of something sometimes makes a thing
more intriguing where a lot of use becomes a pain.

Many of us stick with the more stable branch so many on this mailing list
may not have moved to the 5.1.x either. Those who have may well be too
busy to try out someone else's issue just yet.

Also the issue is not causing the program or computer to crash or be
unstable or misbehave in that sort of way so it's not really a "bug" as
such, at least not to the devs ways of thinking. It's more like a
feature-request, but for something that used to work a certain way and now
works a different way.

So i'd recommend posting an initial feature-request asap, but with minimal
information = just the main issue. Stuart has helped pin-point the issue
quite a bit and hopefully that can help you keep the first post really
short and direct.

Regards from
Tom :slight_smile:

#7

Hi :slight_smile:
Errr, i meant posting it as being specific to the 5.0.x might not be
helpful. I think just post in a general way.

Obviously you can mention which release YOU first noticed the issue and
what version you used to use. That gives a broad spread of several
releases, perhaps even covering several branches, but that can be
narrowed-down later on if required. The exact time the change happened
might not even be useful at all. So that is something that can be worked
on while waiting for a response to the general idea.

Regards from
Tom :slight_smile: