[Bug 1065096] Re: Certain keyboard shortcuts disappear between 4.9.1 and 4.9.2
Bug Watch Updater
1065096 at bugs.launchpad.net
Thu Oct 11 20:18:56 UTC 2012
Launchpad has imported 29 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=307823.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2012-10-04T10:54:54+00:00 Bojan Vitnik wrote:
In KDE SC 4.9.1, if you search something in Kickoff search field, after
search results are shown, you can press "Down Arrow" key and then
navigate with arrow keys to select one of multiple search results to
open/run (by pressing "Enter").
In KDE SC 4.9.2, after search results are shown pressing "Down Arrow"
key does nothing except that search field looses focus. After you press
"Down Arrow" (or "Up Arrow") key, no other key is effective any more
except "Tab" key. It takes multiple presses of "Tab" key to get to the
search results list and be able to select one of the results with arrow
keys. This bug existed in 4.8 I think and was fixed in 4.9. Now its here
again and it kills productivity.
Reproducible: Always
Steps to Reproduce:
1. Open Kickoff menu
2. Start typing something (like "konso")
3. Press "Down Arrow" key.
Actual Results:
After step number 3, if you press any other key on keyboard except "Tab", it doesn't have any effect and you can't focus either search result list or search field.
Expected Results:
After step number 3, first search result in search result list should be focused and you can use arrow keys to select search result you want to open/run.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/0
------------------------------------------------------------------------
On 2012-10-04T10:56:23+00:00 Bojan Vitnik wrote:
Forgot to say, I'm using Kubuntu 12.04 with KDE SC 4.9.2 from backports
PPA.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/1
------------------------------------------------------------------------
On 2012-10-04T22:12:39+00:00 Andrei ILIE wrote:
Confirming this against 4.9.2.
Furthermore, Enter/Return doesn't work anymore when browsing the apps in the "Favorites" kickoff tab - try this:
1. Press Alt+F1 to open Kickoff launcher;
2. In the "Favorites" tab select an app, using up/down arrows;
3. Press Enter --> nothing happens :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/2
------------------------------------------------------------------------
On 2012-10-04T23:04:33+00:00 Bojan Vitnik wrote:
I didn't even notice that :), but yes, I can confirm the problem
present.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/3
------------------------------------------------------------------------
On 2012-10-05T06:54:19+00:00 Rickstockton-7 wrote:
(In reply to comment #2)
> Confirming this against 4.9.2.
>
> Furthermore, Enter/Return doesn't work anymore when browsing the apps in the
> "Favorites" kickoff tab - try this
....
Yikes. NONE of the tabs work, except for the "Applications"
flipScrollView. (Computer, Recently Used, and Leave tabs). They also
fail to execute a 'member' program after you've highlighted it and
pressed 'Enter'.
I've modified both 'priority' and 'importance', and attempt fix over the
weekend. It may be difficult, because the so-called "controller" doesn't
firmly know whether you are focused within the search "view" or the
applications lists (i.e., flipScrollView). It only receives the keyboard
events, and contains a MESSY sequence of "if" blocks (based on the
characters involved) to decide what to do.
I'll comment on a re-design in a couple of days. One possible approach
is to "mark" the Up and Down arrow keys by adding different modifiers
based on the source of unique child (search text view, flipScrollView,
or "search results"). I can also translate to/from variations of the
"Tab" key.
But more important: Somehow, the logic now swallows up the 'Enter' key
and goes to do something wrong, before deciding that "it" should execute
the selected program. That's the first priority; convenient navigation
follows afterwards.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/4
------------------------------------------------------------------------
On 2012-10-05T13:09:32+00:00 Till Schäfer wrote:
i can confirm that the bahaviour of 4.9.2 very confusing. tab sometimes
works and sometimes not and sometimes you have to press it multiple
times. after this you have to use the arrows to navigate. what was wrong
with the 4.9.1 behaviour (simply use the up/down arrow)? For me this was
the most productive solution.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/5
------------------------------------------------------------------------
On 2012-10-05T13:16:24+00:00 Till Schäfer wrote:
It is also a good habit, not to change the behaviour when there is no
real(at least for the user perspective) reason to do so. otherwise
people are getting annoyed because they have to learn everything again
and again.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/6
------------------------------------------------------------------------
On 2012-10-05T13:29:25+00:00 Bojan Vitnik wrote:
(In reply to comment #6)
> It is also a good habit, not to change the behaviour when there is no
> real(at least for the user perspective) reason to do so. otherwise people
> are getting annoyed because they have to learn everything again and again.
Well there was a real reason to change behavior. The patch that caused
this regression was supposed to fix bug 276932 and bug 297842 but it
broke more that it fixed :).
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/7
------------------------------------------------------------------------
On 2012-10-05T13:54:08+00:00 Till Schäfer wrote:
ok. i was not aware of bug 276932. For me it seems that the problems
you tried to fix in Bug 276932 is that the left/right arrow keys are
used ambiguously:
1. navigating the serarch field
2. navigating the kickoff-categories (i.e. applications, favorites, etc)
3. navigating the categories in application menu (level up / down)
The up/down arrow key are used to navigate up/down only. These keys are
OK.
My suggestion:
1. use left/right arrow only to switch the kickoff categories
2. use enter and backspace for navigating the application categories. this is consistent with the use of folders in dolphin.
3. use left/right arrow keys for navigating the search field only if a search term is entered. if the search term gets deleted switch back to kickoff categories
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/8
------------------------------------------------------------------------
On 2012-10-06T18:10:00+00:00 Rickstockton-7 wrote:
Thank you for all 3 comments (I will verify all in testing).
Now that I have introduced Tab as a functional key, I must support it -
together, WITH the arrow keys.
WRT switching kickoff categories: Our categories are more like choosing
between split panels, or (closest of all) Konqueror Browser tabs. Konq
uses "Ctrl+," and " Ctrl+." for switching between tabs (leftward and
rightward respectively). Till, I don't think that Dolphin "Places" are
as much a like this as Konqueror Browser "Tabs". are, and
"Enter+Backspace" goes only upwards. Would the Konq scheme be OK?
I have, of course, 3 other ways which could know that you desire a
left/right arrow to change the kickoff category, rather than modify a
search textArea:
#1 The textArea is empty - both arrows should modify the kickoff category, there is no question that this should work.
#2 You are highlighting the first character, and press "Left" -- should I modify the kickoff category? If so, I will still leave the cursor within the search data entry TextArea, until, you press an "up" or "down" arrow.
#3 You are highlighting the last character, and press "Right" -- same as #2.
Now, within the flipScrollView, should pressing "down" at the bottom of
a column, or "up" at the top of a coulmn, relocate you into the search
field? Or should you cursur and highlight just stay un-moved (the
current behavior), requireing you to know about "Tab" to get in there?
And, any other key combinations to utilize for switching from
flipScrollView (applications list, or matching search results) into the
"search" text entry textArea?
My thanks in advance, for advice and more WRT the user keys and
combinations to use.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/9
------------------------------------------------------------------------
On 2012-10-07T07:51:21+00:00 Rickstockton-7 wrote:
(In reply to comment #8)
> The up/down arrow key are used to navigate up/down only. These keys are OK.
>
Not really. When the 'Applications' flipScrollView gets focus, you can see that the cursor no longer blinks within the search text. That's good -- it means that the flipScrollView *CAN* execute program items.
But, when going 'down' from the search bar into another tabview (RFU,
computer, favorites) the cursor is still blinking in the search text.
That's VERY bad, we needed to switch focus. (It's the cause of failure
to execute from inside those other tabs.)
Two other nits:
#1: the business about having to press "Tab", or key_down/key_up, twice (rather than once.) focus is getting lost in some other place, either the "launcher" itself or the tab bar. (The first keypress event is getting consumed by one of these two, and it's not generating a new one into the tabview or search bar which should have focus -- until it gets repeated.
#2: I should be able to rise "above the top" of a tabview column,
directly into the search text, when someone presses Key_Up while a
first-row item is highlighted. And at the bottom, I should be able to
"fall through the floor" and end up at the same place (i.e. the search
bar.)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/10
------------------------------------------------------------------------
On 2012-10-07T20:05:31+00:00 Bojan Vitnik wrote:
Created attachment 74395
Kickoff - Keyboard Navigation Proposal (WIP)
Here is my proposal of how keyboard navigation in Kickoff should be
implemented. It took me some time to make it. I don't know if it is
currently possible to implement the scheme I propose since I virtually
don't have any knowledge of Qt and Kickoff source code. On the other
hand, it has consistent behavior so it should not be hard to implement.
This is a WIP and I probably left something out and didn't cover all use
cases. I'll also attach original LibreOffice drawing so that it can be
edited.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/11
------------------------------------------------------------------------
On 2012-10-07T20:10:22+00:00 Bojan Vitnik wrote:
Created attachment 74396
Kickoff - Keyboard Navigation Proposal (WIP) (ODG)
Here is LibreOffice Drawing.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/12
------------------------------------------------------------------------
On 2012-10-08T07:47:24+00:00 Till Schäfer wrote:
@rick: (In reply to comment #9)
> Thank you for all 3 comments (I will verify all in testing).
>
> Now that I have introduced Tab as a functional key, I must support it -
> together, WITH the arrow keys.
>
> WRT switching kickoff categories: Our categories are more like choosing
> between split panels, or (closest of all) Konqueror Browser tabs. Konq uses
> "Ctrl+," and " Ctrl+." for switching between tabs (leftward and rightward
> respectively). Till, I don't think that Dolphin "Places" are as much a like
> this as Konqueror Browser "Tabs". are, and "Enter+Backspace" goes only
> upwards. Would the Konq scheme be OK?
i thought of a folder in dolphin because there is the same way the application categories are displayed on the top (i.e. applications > multimedia). But maybe both key combinations work well because there are multiple interpretations.
>
> I have, of course, 3 other ways which could know that you desire a
> left/right arrow to change the kickoff category, rather than modify a search
> textArea:
>
> #1 The textArea is empty - both arrows should modify the kickoff category,
> there is no question that this should work.
> #2 You are highlighting the first character, and press "Left" -- should I
> modify the kickoff category? If so, I will still leave the cursor within the
> search data entry TextArea, until, you press an "up" or "down" arrow.
> #3 You are highlighting the last character, and press "Right" -- same as #2.
>
i think the categories are complely switched off as soon as a search term is entered and therefore case #2 and #3 should never occur (at least this is the behaviour in 4.9.2). therefore it should be as simple as:
1. mooving kickoff kategories with left/right if and only if the search field is empty
2. mooving the cursor in the search field with left/right if and only if the search field is not empty
> Now, within the flipScrollView, should pressing "down" at the bottom of a
> column, or "up" at the top of a coulmn, relocate you into the search field?
> Or should you cursur and highlight just stay un-moved (the current
> behavior), requireing you to know about "Tab" to get in there?
>
typing any text should relocate the cursor in the search field. therefore it is possible to enter text at any position in the flipScrollView. therefore it sould be also fine to get back to the top column if pressing down at the bottom colum and vice versa.
> And, any other key combinations to utilize for switching from flipScrollView
> (applications list, or matching search results) into the "search" text entry
> textArea?
>
any text
> My thanks in advance, for advice and more WRT the user keys and combinations
> to use.
THX too for getting the users involved :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/13
------------------------------------------------------------------------
On 2012-10-08T07:58:33+00:00 Till Schäfer wrote:
(In reply to comment #10)
> (In reply to comment #8)
> > The up/down arrow key are used to navigate up/down only. These keys are OK.
> >
> Not really. When the 'Applications' flipScrollView gets focus, you can see
> that the cursor no longer blinks within the search text. That's good -- it
> means that the flipScrollView *CAN* execute program items.
>
> But, when going 'down' from the search bar into another tabview (RFU,
> computer, favorites) the cursor is still blinking in the search text. That's
> VERY bad, we needed to switch focus. (It's the cause of failure to execute
> from inside those other tabs.)
>
> Two other nits:
> #1: the business about having to press "Tab", or key_down/key_up, twice
> (rather than once.) focus is getting lost in some other place, either the
> "launcher" itself or the tab bar. (The first keypress event is getting
> consumed by one of these two, and it's not generating a new one into the
> tabview or search bar which should have focus -- until it gets repeated.
>
> #2: I should be able to rise "above the top" of a tabview column, directly
> into the search text, when someone presses Key_Up while a first-row item is
> highlighted. And at the bottom, I should be able to "fall through the floor"
> and end up at the same place (i.e. the search bar.)
i think there is no need to make it that complicated if you dont stay in
the "focus" thinking. as mentioned above. If we have different keys for
switching kickoff categories and application categories, we can think of
left/right as a key for kickoff categories / search text field cursor
and up/down only for navigating the colums. there is no need to switch
the focus to the search field or back because you can simply type any
text at any state of the kickoff starter. there is also no need to give
the kickoff categories any focus because the left/right keys should work
all the time.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/14
------------------------------------------------------------------------
On 2012-10-08T07:59:18+00:00 Till Schäfer wrote:
the same applies to Bojans comments
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/15
------------------------------------------------------------------------
On 2012-10-08T10:11:46+00:00 Bojan Vitnik wrote:
(In reply to comment #15)
> the same applies to Bojans comments
So if I understood you correctly, your idea basically comes to this:
- left and right arrow keys are always used for switching categories, except when search field has some text.
- Enter and Backspace are used to go into/out of subcategories (as I call them :) ).
That way it's "more practical" and it saves some unneeded key presses?
The problem with this scheme is that it is not very intuitive to
unexperienced users and users that are used to classic menu style (think
Win 95 style Start menu). In classic menu, you can get wherever you want
with only using arrow keys. That's what my proposal is all about. You
can get anywhere with *only using arrow keys*. People expect that.
Let's say a user is browsing the Applications category. He figures out
that he can move the focus with up and down arrow keys. Nice. Since his
fingers are already on arrow key he expects that he can go into
subcategory with right arrow key. *Wrong*. It sends him to another
category, messing up his work flow, and if he goes back, he probably
won't end up in the same subcategory he was in.
Enter and Backspace are used in file managers because you usually have
2D matrix of items where you must use all the arrow keys to navigate.
That's why Backspace is needed to send you back or to the parent
directory.
It's not very easy to figure out that Backspace can send you back to
parent subcategory.
Think about an average computer user that is maybe using a laptop and
that had learned some tricks like keyboard shortcuts and basic keyboard
menu navigation to "speed up" his work because touch pad is useless.
Experienced user will mostly rely on search and global keyboard
shortcuts and will very rarely go to navigate around Kickoff.
In the end, in my proposal, left and right arrow key will in most cases
change the category. Only exceptions are when search field is not empty,
and therefore categories practically nonexistent, and when Application
category is opened.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/16
------------------------------------------------------------------------
On 2012-10-09T15:10:09+00:00 Rickstockton-7 wrote:
(In reply to comment #14)
> i think there is no need to make it that complicated if you dont stay in the
> "focus" thinking. as mentioned above. If we have different keys for
> switching kickoff categories and application categories, we can think of
> left/right as a key for kickoff categories / search text field cursor and
> up/down only for navigating the colums. there is no need to switch the focus
> to the search field or back because you can simply type any text at any
> state of the kickoff starter. there is also no need to give the kickoff
> categories any focus because the left/right keys should work all the time.
Till, I think that you forgot the special problem with the
'Applications' menu (which I'm going to label as the flipScrollView):
It's 2D, not just a column. That causes two problems-
(1) You *need* 'Left' and 'Right' to navigate inside. From Application Group, on the "left" of the flipScollView, towards a particular Application (on the right, without any "children").
(2) Without focus in the breadcrumb, or support of 'Key_Left' within the flipScrollView, you can never move towards a "parent" on the left.
I think that a focus change is mandatory for this view (The Application
'flipScrollView'), but none of the others. One of my design mistakes in
the 4.8.x "solution" was to move focus in all cases, and we don't need
to do that in the other Views. In 9.1 the 'Favorites', 'Computer',
'Recently Used', and 'Logoff' just worked -- without focus. And they
should remain UNCHANGED. But flipScrollView needs focus-in and focus-
out.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/17
------------------------------------------------------------------------
On 2012-10-09T15:23:38+00:00 Rickstockton-7 wrote:
So - I'm with Bojan on a "need" for arrows within the Application view.
But, I don't think that we ever need to 'focus' the the content-switch
"tab bar":
(a) SearchView always has focus, unless:
(b) Applications 'flipScrollView' has gained focus via Key_Down, Key_Up, or Key_Tab.
(c) from anywhere within flipScrollView, you can send focus back to the
SearchView with Key_Tab.
And I will try to add the following:
(d) Key_Up, while at the TOP ROW of a flipScrollView column, sends focus back to the SearchView.
(e) Key_Down, while at the BOTTOM ROW of a flipscrollview column, sends focus back into the SearchView.
- - - - -
Bojan, I'm inclined to refuse your other enhancements (glow and etc.),
because this is scheduled to go away in 4.10 -- and also, because my
last "fix attempt" proved to be incompetent. I can program no better
than you ;) so let's keep it to an absolute minimum amount of code.
(bugfix, not enhancement.)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/18
------------------------------------------------------------------------
On 2012-10-09T15:58:32+00:00 Bojan Vitnik wrote:
(In reply to comment #18)
> But, I don't think that we ever need to 'focus' the the content-switch "tab
> bar":
>
> (a) SearchView always has focus, unless:
> (b) Applications 'flipScrollView' has gained focus via Key_Down, Key_Up, or
> Key_Tab.
>
> (c) from anywhere within flipScrollView, you can send focus back to the
> SearchView with Key_Tab.
>
Yes by the end of my "late night brain(dead)storming" I forgot that
categories are hidden when search field is not empty. Combined with left
and right arrow key changing category when search field is empty, focus
on category tab is never needed. F, A, C, R and L can be combined with
Alt so that use case is also redundant.
> Bojan, I'm inclined to refuse your other enhancements (glow and etc.),
> because this is scheduled to go away in 4.10 -- and also, because my last
> "fix attempt" proved to be incompetent. I can program no better than you ;)
> so let's keep it to an absolute minimum amount of code.
>
> (bugfix, not enhancement.)
Would you consider changing the Esc behavior the way I proposed it? Esc
first clears the search field, then closes the Kickoff. Maybe add
support for Home and End as proposed?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/19
------------------------------------------------------------------------
On 2012-10-09T16:06:05+00:00 Till Schäfer wrote:
(In reply to comment #17)
> (In reply to comment #14)
> > i think there is no need to make it that complicated if you dont stay in the
> > "focus" thinking. as mentioned above. If we have different keys for
> > switching kickoff categories and application categories, we can think of
> > left/right as a key for kickoff categories / search text field cursor and
> > up/down only for navigating the colums. there is no need to switch the focus
> > to the search field or back because you can simply type any text at any
> > state of the kickoff starter. there is also no need to give the kickoff
> > categories any focus because the left/right keys should work all the time.
>
> Till, I think that you forgot the special problem with the 'Applications'
> menu (which I'm going to label as the flipScrollView): It's 2D, not just a
> column. That causes two problems-
No, thats why i suggested different shortcuts for swichting flipScrollView and kickoff categories. In this case we dont have this problem. Nevertheless i could unterstand if you dont want to change this behaviour.
>
> (1) You *need* 'Left' and 'Right' to navigate inside. From Application
> Group, on the "left" of the flipScollView, towards a particular Application
> (on the right, without any "children").
> (2) Without focus in the breadcrumb, or support of 'Key_Left' within the
> flipScrollView, you can never move towards a "parent" on the left.
>
> I think that a focus change is mandatory for this view (The Application
> 'flipScrollView'), but none of the others. One of my design mistakes in the
> 4.8.x "solution" was to move focus in all cases, and we don't need to do
> that in the other Views. In 9.1 the 'Favorites', 'Computer', 'Recently
> Used', and 'Logoff' just worked -- without focus. And they should remain
> UNCHANGED. But flipScrollView needs focus-in and focus-out.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/20
------------------------------------------------------------------------
On 2012-10-09T16:07:56+00:00 Till Schäfer wrote:
(In reply to comment #18)
> So - I'm with Bojan on a "need" for arrows within the Application view.
>
> But, I don't think that we ever need to 'focus' the the content-switch "tab
> bar":
>
> (a) SearchView always has focus, unless:
> (b) Applications 'flipScrollView' has gained focus via Key_Down, Key_Up, or
> Key_Tab.
>
> (c) from anywhere within flipScrollView, you can send focus back to the
> SearchView with Key_Tab.
>
> And I will try to add the following:
> (d) Key_Up, while at the TOP ROW of a flipScrollView column, sends focus
> back to the SearchView.
> (e) Key_Down, while at the BOTTOM ROW of a flipscrollview column, sends
> focus back into the SearchView.
> - - - - -
>
> Bojan, I'm inclined to refuse your other enhancements (glow and etc.),
> because this is scheduled to go away in 4.10 -- and also, because my last
> "fix attempt" proved to be incompetent. I can program no better than you ;)
> so let's keep it to an absolute minimum amount of code.
>
> (bugfix, not enhancement.)
This looks reasonable for me. Its a good compromise without changing the
old behaviour to much. (Althoug i still prefer the solution with
differen shortcuts ;) )
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/21
------------------------------------------------------------------------
On 2012-10-09T16:11:05+00:00 Bojan Vitnik wrote:
Yeah, I forgot about Page Up an Page Down. Could be useful with looooong
lists.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/22
------------------------------------------------------------------------
On 2012-10-10T06:18:19+00:00 Rickstockton-7 wrote:
I've got a version which "kind of" works. It allows you to wander around
in the "All Applications" View with arrows in all 4 directions, and
execute an application with Key_Enter *or* Key_Return.
Instead of allowing the "All Applications View" to gain focus, it uses a
boolean, with getter and setter, for "do I send ALL arrows, and
Enter/Return keys into the "All Applications View" ?
Some cleanups are still needed, for Key_Tab versus Key_Up and Key_Down
(switching from inside a "View" back to the searchbar, or switching from
the searchbar down/up to a View).
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/23
------------------------------------------------------------------------
On 2012-10-11T16:15:29+00:00 Rickstockton-7 wrote:
It works, mostly -- but keyboard focus can get "trapped" inside the Tab
Bar "contentSwitcher", which cannot be escaped without pressing 'Tab'.
Here is our choice:
#1: I can make Up/Down do nothing EXCEPT switch between the searchView
and the Current content. For this case, I must write code in each type
of View (flipScrollView versus UrlView types) to make translate an
Up/Down into a Tab when the person is on the top or bottom item. Bad
things about this one: (A) It's a big change in behavior, compared to
the current case of simply staying on the current highlighted item when
you press an arrow key to go "past" it; (B) you will be REQUIRED to have
an empty search text in order to move between Views; (C) Code is awkward
and dangerous, adding a lot of new stuff. It would take another week to
finish writing and testing. OR:
#2: Stay with the design of 4.8.3 (maybe it was 4.8.2?) - you usually need to use a TAB key to move between views (and the content switcher is still is possible destination of focus). This is pretty much done.
- - - - -
I strongly prefer #2, and I'm willing to write a tiny "help" in EN-US to describe the use of the 'Tab' key in "keyboard-only" mode.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/28
------------------------------------------------------------------------
On 2012-10-11T16:21:48+00:00 Kde-gj5 wrote:
For 4.9.3, making it work more like previous releases is the right
answer. The behavior change in a point release in 4.9.2 is problematic,
which (I think) means I like #2.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/29
------------------------------------------------------------------------
On 2012-10-11T16:28:33+00:00 Rickstockton-7 wrote:
Thanks, Scott! To summarize- I'd prefer to revise this bug description
into: "can't execute items with <Enter> or <Return> in 'Favorites',
'Computer', 'Recently Used', or 'Leave' tab content areas". That is to
work like 4.8.x, (x > 2), and 4.y, (y < 7).
It's quite nasty enough to repair even that stuff, WHILE supporting
keyboard navigation and execution within Applications "flipScrollView"
(which didn't work with 9.0/9.1).
I'd like the basic functionality of executing items first (could be
finished in one or two hours). Then, maybe a separate bug for consistent
behavior of Up/Down in (A) leaving the search bar; (B) leaving (or even
avoiding) the Tab Bar; and (C) leaving a Tab Content area? And/Or a Doco
bug, "the use of Key_Tab is not documented in Kickoff "help"?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/30
------------------------------------------------------------------------
On 2012-10-11T16:58:55+00:00 Kde-gj5 wrote:
The original content of this bug was about going to search results from
a search. If I'm reading you correctly, you want to open a new bug for
that and change this to cover other easier to fix issues.
I would encourage you to get your can't execute fix in without changing
this bug (If you need a bug, file a new one for that and make that one
block this one - because that's a good fix) since the part you're
leaving for later is exactly what the original bug report is about.
I don't think that documenting the current behavior is sufficient for
this case. The use of tab to get into the search results is very
counter-intuitive and it is also quite difficult to tell when you have
the correct focus.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/31
------------------------------------------------------------------------
On 2012-10-11T17:50:10+00:00 Rickstockton-7 wrote:
Not so much "easier to fix", but more critical (comments 2-4). I'll
continue working on this as a single bug (with both problems included) -
but it will take longer. Thanks for coaching me to avoid the division,
if possible!
Reply at: https://bugs.launchpad.net/ubuntu/+source/kde-
workspace/+bug/1065096/comments/32
** Changed in: kdebase-workspace
Status: Unknown => In Progress
** Changed in: kdebase-workspace
Importance: Unknown => High
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kde-workspace in Ubuntu.
https://bugs.launchpad.net/bugs/1065096
Title:
Certain keyboard shortcuts disappear between 4.9.1 and 4.9.2
To manage notifications about this bug go to:
https://bugs.launchpad.net/kdebase-workspace/+bug/1065096/+subscriptions
More information about the kubuntu-bugs
mailing list