Bug 1961

Trinity Dolphin does not exhibit this behavior nor do Dolphin or Konqueror in KDE4.

*** Bug 1740 has been marked as a duplicate of this bug. ***

Sorry for the long delay in fixing this; it ended up requiring a complete rewrite of the TDEListView movement key handlers in file management mode.  The original code was over 14 years old and never functioned properly as far as I could tell; the new code behaves in a much saner manner.

Fixed in GIT hash 4ffab32 (tdelibs).

Thanks for reporting!

>Fixed in GIT hash 4ffab32 (tdelibs).
Looks good here. Thanks.

Still experiencing the same problem here, with yesterday's GIT sources.
Reopened.

(In reply to Michele Calgaro from comment #5)
> Still experiencing the same problem here, with yesterday's GIT sources.
> Reopened.

That doesn't make any sense.  What view mode are you using in Konqueror?

I too have the same behaviour as described in initial post, using today's git (I did not try earlier).

When using "icon view", or "multicolumn view", I have the focus following the cursor arrow keys as expected.

But when in "tree view", "info list view" and "detailed list view",  I still have the kind of "ghost" selection that is moving, but the actual focus remains on the initially mouse-selected item.

Tested with both existing and fresh profile, same result.

In the past couple of days I have seen the ghost behavior return, probably three times. I use tree view exclusively and have not tested other view modes. I have not yet noticed my usage pattern that would help trigger the behavior repeatedly.

(In reply to Francois Andriot from comment #7)
> I too have the same behaviour as described in initial post, using today's
> git (I did not try earlier).
> 
> When using "icon view", or "multicolumn view", I have the focus following
> the cursor arrow keys as expected.
> 
> But when in "tree view", "info list view" and "detailed list view",  I still
> have the kind of "ghost" selection that is moving, but the actual focus
> remains on the initially mouse-selected item.
> 
> Tested with both existing and fresh profile, same result.

I'm currently doing a full rebuild of tdelibs and tdebase on my development machine in case something snuck in the source and was not built/installed for some reason; this will take several hours.

I did test just now (with the mismatched binaries; I am still waiting on the rebuild) and what I see is a focus rectangle that is movable with the cursors but does not change focus unless Shift is held down or Spacebar is pressed.  If I hold down Shift and use a down movement key the focus rectangle moves down, selecting items as it goes; if I switch to an up movement key the focus rectangle moves up, deselecting items as it goes.  At no point while Shift is held down (excepting the very first keypress after depressing Shift, or if Spacebar is pressed) do I see a focus rectangle without an active selection underneath it.

Is this 1.) the expected behaviour (from my perspective yes it is) and 2.) if not, what *exactly* you are seeing?

Thanks!

(In reply to Timothy Pearson from comment #9)
> (In reply to Francois Andriot from comment #7)
> > I too have the same behaviour as described in initial post, using today's
> > git (I did not try earlier).
> > 
> > When using "icon view", or "multicolumn view", I have the focus following
> > the cursor arrow keys as expected.
> > 
> > But when in "tree view", "info list view" and "detailed list view",  I still
> > have the kind of "ghost" selection that is moving, but the actual focus
> > remains on the initially mouse-selected item.
> > 
> > Tested with both existing and fresh profile, same result.
> 
> I'm currently doing a full rebuild of tdelibs and tdebase on my development
> machine in case something snuck in the source and was not built/installed
> for some reason; this will take several hours.
> 
> I did test just now (with the mismatched binaries; I am still waiting on the
> rebuild) and what I see is a focus rectangle that is movable with the
> cursors but does not change focus unless Shift is held down or Spacebar is
> pressed.  If I hold down Shift and use a down movement key the focus
> rectangle moves down, selecting items as it goes; if I switch to an up
> movement key the focus rectangle moves up, deselecting items as it goes.  At
> no point while Shift is held down (excepting the very first keypress after
> depressing Shift, or if Spacebar is pressed) do I see a focus rectangle
> without an active selection underneath it.
> 
> Is this 1.) the expected behaviour (from my perspective yes it is) and 2.)
> if not, what *exactly* you are seeing?
> 
> Thanks!


I believe you are describing the same situation I am seeing; but from what I understand, this is also what was described in initial post as a bug... 
So, it this is the expected behaviour, what was exactly the original bug ? And what did you fix exactly in GIT ?

I think I can sum up like this:
- Darrell says that the "focus rectangle" or "feint box" or "ghost" exists only in Konqueror/TDE in detailed view only. It does NOT exist AT ALL in Dolphin/TDE, konqueror/KDE4 nor Dolphin/KDE4, nor even Konqueror/TDE in icon view. So this is an inconsistency for the user experience and should be corrected.
- You say this is not a bug, but the expected behaviour of Konqueror. I agree that Konqueror for KDE3 has always had this behaviour.

You can try to use Dolphin/TDE: selecting an item with mouse puts the focus on it. Then, moving with cursor up/down moves the blue focus immediatly, removing the focus from previous item. There is no such thing as "focus box" at all.

Your description matches the old broken behavior. Since you patched this, I have seen a solid rectangle when I move the Up/Down keys with no Shift/Control key. Except for those few times I mentioned previously. That is, ignoring those few anomalies I see a solid rectangle now, which is what I expect and see in other file managers.

I use tree view exclusively and never use other view modes except for testing.

(In reply to Francois Andriot from comment #10)
> I believe you are describing the same situation I am seeing; but from what I
> understand, this is also what was described in initial post as a bug... 
> So, it this is the expected behaviour, what was exactly the original bug ?
> And what did you fix exactly in GIT ?
> 
> I think I can sum up like this:
> - Darrell says that the "focus rectangle" or "feint box" or "ghost" exists
> only in Konqueror/TDE in detailed view only. It does NOT exist AT ALL in
> Dolphin/TDE, konqueror/KDE4 nor Dolphin/KDE4, nor even Konqueror/TDE in icon
> view. So this is an inconsistency for the user experience and should be
> corrected.
> - You say this is not a bug, but the expected behaviour of Konqueror. I
> agree that Konqueror for KDE3 has always had this behaviour.
> 
> You can try to use Dolphin/TDE: selecting an item with mouse puts the focus
> on it. Then, moving with cursor up/down moves the blue focus immediatly,
> removing the focus from previous item. There is no such thing as "focus box"
> at all.

OK, I think I see the misunderstanding here.

First, it helps to think of the focus rectangle as a keyboard-driven cursor.  This is a nice feature of Konqueror that, as you state, does not exist elsewhere.  It allows the user to select non-contiguous files without having to resort to using the mouse, or even to select all and then deselect a single file.  This feature is NOT going to be removed; if the user does not wish to do such advanced tasks with the keyboard he or she can simply ignore the focus rectangle entirely.

The original bug was that when using the keyboard cursor (focus rectangle) to select items, the cursor always overshot the selected items leaving the last item deselected and requiring the user press Spacebar to select it.  This is unexpected and inefficient, and the user not only cannot just ignore the focus rectangle but also must know of the "magic" Spacebar keypress.

Make sense?

(In reply to Darrell from comment #11)
> Your description matches the old broken behavior. Since you patched this, I
> have seen a solid rectangle when I move the Up/Down keys with no
> Shift/Control key. Except for those few times I mentioned previously. That
> is, ignoring those few anomalies I see a solid rectangle now, which is what
> I expect and see in other file managers.
> 
> I use tree view exclusively and never use other view modes except for
> testing.

Seeing the answer from Tim, the "old broken behaviour" is not broken but expected, so it was not modified !
So, you should NOT have the "solid rectangle focus" moving with keyboard cursor in tree view (I don't)...

The truth is out there ..

The original long-standing bug was the rectangle never was solid when moving with the keyboard cursor keys in a list view. Always the rectangle was an outline when moving. The recent commit fixed that and the rectangle now is always solid. Please don't revert the commit as my original problem is resolved as reported. :)

With reference to comment 8, I discovered a way to revert the rectangle back to an outline: Perform a multiple select of a few files (Ctrl+click). Release the mouse and Ctrl key and use the keyboard Up/Down keys to move the cursor. The rectangle reverts to outline. Pressing Esc deselects the selected files and restores the rectangle to a solid rectangle.

Again, this is in tree view.

(In reply to Darrell from comment #14)
> The original long-standing bug was the rectangle never was solid when moving
> with the keyboard cursor keys in a list view. Always the rectangle was an
> outline when moving. The recent commit fixed that and the rectangle now is
> always solid. Please don't revert the commit as my original problem is
> resolved as reported. :)
> 
> With reference to comment 8, I discovered a way to revert the rectangle back
> to an outline: Perform a multiple select of a few files (Ctrl+click).
> Release the mouse and Ctrl key and use the keyboard Up/Down keys to move the
> cursor. The rectangle reverts to outline. Pressing Esc deselects the
> selected files and restores the rectangle to a solid rectangle.
> 
> Again, this is in tree view.


OK I believe I understand now.

I've tried 3 tests, please tell me if everyone is seeing the same thing.

Test 1:
1) Close konqueror. Open konqueror, file management profile, tree view mode.
2) Do NOT select any item in the list.
3) Press key Arrow up/down: the solid blue focus appears and is following your key press. There is no transparent focus.

Test 2:
1) Close konqueror. Open konqueror, file management profile, tree view mode.
2) Using the mouse, select any file/folder in the list.
3) Press key arrow up/down: the solid blue focus is staying on mouse-selected item. Also, a transparent focus appears and is following the key press without changing the actual focus.

Test 3:
1) Close konqueror. Open konqueror, file management profile, tree view mode.
2) Do NOT select any item in the list.
3) Press key arrow up/down: the solid blue focus is moving with the cursor (as in test 1).
4) Using the mouse, click on another file/folder.
5) Press key arrow up/down again: the solid blue focus is STILL moving with the key press. The transparent focus does not appear as in test 2.


I don't have a real opinion on this, if everyone agree, we can close the bug.

(In reply to Francois Andriot from comment #13)
> Seeing the answer from Tim, the "old broken behaviour" is not broken but
> expected, so it was not modified !
> So, you should NOT have the "solid rectangle focus" moving with keyboard
> cursor in tree view (I don't)...

No, not quite. :-)  The fastest way to see the difference is to boot up an old TDE 3.5.13.2 installation alongside the R14 installation and try to use the keyboard select in both versions; the change will be obvious.

(In reply to Darrell from comment #14)
> The original long-standing bug was the rectangle never was solid when moving
> with the keyboard cursor keys in a list view. Always the rectangle was an
> outline when moving. The recent commit fixed that and the rectangle now is
> always solid. Please don't revert the commit as my original problem is
> resolved as reported. :)

Don't worry, nothing is being reverted. :-)

> With reference to comment 8, I discovered a way to revert the rectangle back
> to an outline: Perform a multiple select of a few files (Ctrl+click).
> Release the mouse and Ctrl key and use the keyboard Up/Down keys to move the
> cursor. The rectangle reverts to outline. Pressing Esc deselects the
> selected files and restores the rectangle to a solid rectangle.

Yeah, I could see that being a problem; when using the mouse Konqueror has no idea if the select is going up or down.  Let me look into it.

>I could see that being a problem; when using the mouse Konqueror has no idea if 
>the select is going up or down.
Not sure whether the behavior is a problem. The user explicity selects multiple files. For the rectangle to revert back to solid requires deslecting the selected files. An outline cursor makes some sense when multiple files are preselected.

Regarding Francois' tests: I see the same behaviors. Test 2 revealed to me how I likely saw the outline rectangle I described in comment 8.

I see now that when mixing mouse clicks and keyboard movement that konqueror gets confused whether to display an outline or solid rectangle.

Probably have to tinker with other file managers to compare behaviors.

A quick glance at the Mate Caja file manager:

Clicking once with the mouse on a file results in a solid rectangle. Releasing the mouse and using the Up/Down keys results in the solid rectangle moving, thereby abandoning the original mouse selection. This behavior makes sense to me rather than the Konqueror behavior of the selected file remaining solid and the moving rectangle becoming an outline.

Multiple selecting files with the mouse results in multiple solid rectangles. Releasing the mouse and using the Up/Down keys results in the selected files being deselected and a single solid rectangle remaining solid moving as directed by the keyboard. I can see arguments for both the Caja and Konqueror behavior but I think to most users the Caja behavior would be more accepted.

At no time in Caja did I see an outline rectangle. Nor do I recall any such behavior since I started using Caja months ago.

(In reply to Darrell from comment #19)
> A quick glance at the Mate Caja file manager:
> 
> Clicking once with the mouse on a file results in a solid rectangle.
> Releasing the mouse and using the Up/Down keys results in the solid
> rectangle moving, thereby abandoning the original mouse selection. This
> behavior makes sense to me rather than the Konqueror behavior of the
> selected file remaining solid and the moving rectangle becoming an outline.
> 
> Multiple selecting files with the mouse results in multiple solid
> rectangles. Releasing the mouse and using the Up/Down keys results in the
> selected files being deselected and a single solid rectangle remaining solid
> moving as directed by the keyboard. I can see arguments for both the Caja
> and Konqueror behavior but I think to most users the Caja behavior would be
> more accepted.
> 
> At no time in Caja did I see an outline rectangle. Nor do I recall any such
> behavior since I started using Caja months ago.

Caja is hardly a fair comparison--if I thought Mate's (back then Gnome's) interface was sufficiently powerful for my needs I would never have started the TDE project. ;-)

That being said I don't objectively really see a problem here.  Even when I used the mouse and the keyboard interchangeably the behavior was consistent and logical as long as I kept track of where the focus rectangle was at any given time.

The only nit is that I could see where it would be desirable to have the focus rectangle placed on the last item selected with the mouse instead of the first.  If you concur with this, I can have a patch fairly rapidly.

Other than this nit I think this report is resolved.  Konqueror is a powerful tool, especially in list view mode, and with that power comes some degree of complexity.  I don't want to lose the unique ability of using the keyboard to select multiple non-contiguous files.

Sorry for the late reply. I use "detail list view" mode only.
This are my 2 cents.

IMO, there has been some misunderstanding about what the expected behavior should be, with people having different ideas about it.
1) blue focus rectangle moves with the keyboard arrows
2) blue focus rectangle does NOT moves with the keyboard arrows, only the "ghost" focus.

A) Long term solution (after v14.0.0):
we should add a check box to let the user select between the two different options (for example I prefer option 1 but Tim prefer option 2. Other people coming from other DE may be confused since they may be expecting behavior 1.)

B) Short term solution: 
I am OK with keeping the behavior of option 2 which is the "standard Konqueror way" apparently, as Tim said in comment 12
> This is a nice feature of Konqueror that, as you state, does not exist 
> elsewhere.  
But we should at least making it consistent, i.e. behave always in the same way.
What I have observed so far is that sometimes the blue focus moves, sometimes only the ghost focus moves (for example the tests described in comment 15 are a good example, but you can just play around a while with keyboard arrows and mouse and see different behavior quite easily).

What do you think?

>What do you think?
I prefer a solid rectangle at all times. :)

I have modified the interaction between mouse and keyboard selection to be more intuitive in GIT hashes 2167947 (tdelibs) and 4e5a99f (tdebase).  Using the mouse to select items, then using the keyboard with Shift+movement keys will cause all previously selected items to deselect and the keyboard operation to start selecting items from the focus rectangle (keyboard cursor) position.  This is then consistent with what happens when moving the keyboard cursor and subsequently depressing Shift+movement keys.

If the mouse is depressed in a rubber band selection and the keyboard is simultaneously used the modifiers will be ignored and the focus rectangle will move without selecting items; this seems to be a reasonable reaction to contradictory commands from the two input devices.  The only other option would be to disable the keyboard entirely during rubberband operations, however the current behavior might be slightly more useful under certain circumstances.

(In reply to Darrell from comment #22)
> >What do you think?
> I prefer a solid rectangle at all times. :)

It sounds like some users (yourself and Michele included) prefer a less advanced and less powerful selection system; one that requires the mouse in order to perform non-contiguous selection.  That's OK, however integrating such a different system into TDE will take time and I don't believe this new feature request should block R14 or even be tacked on to this report.

Can you file a new enhancement reqeust detailing *exactly* what you want to see out of a simplified selection system?  As there is much interaction between keypresses, and the list view remembers state (e.g. moving up, moving up past the initial selection item after initially moving down, etc.) the specification will be somewhat lengthy, however this is the only way to hammer out exactly what is desired so that someone like myself can implement it properly.  Also important is what happen when pressing Spacebar and Esc; as there would be no focus rectangle available and the current item cannot therefore be deselected what should happen instead?

I'm going to close this report as the "advanced mode" selection system in Konqueror seems to be functioning as intended at this time.

Thanks!

The behavior with the last GIT sources is as follow:

1) open Konqueror in list mode, do not select any file with the mouse, use the keyboard to move up and down: the blue square moves up and down with the key pressed.

2) select only one file with the mouse and use the keyboard to move up and down. Again the blue square moves up and down with the key pressed.

3) select 2 or more files with the mouse and use the keyboard to move up and down. Now the blue square does not move and instead the ghost focus moves up and down with the key pressed.

4) select only one file with the mouse and use the keyboard to move up and down. Now the blue square does not move and instead the ghost focus moves up and down with the key pressed. The behavior is different compared to 2), even though we are repeating the same sequence.

5) press ESC, select only one file with the mouse and use the keyboard to move up and down. Now the blue square moves once again up and down with the key pressed.

This seems to be now deterministic, I can repeat it several times.
I guess this is the "Konqueror way", i.e. when selecting more than one file with the mouse or the keyboard, we enter a "multiple select allowed" mode, which require pressing ESC to exit from.

I am not going to reopen this bug report for v14.0.0, but instead I will file a new bug report for post v14.0.0 for implementing an option to allow the user to choose his/her preferred behavior.

Tim, thanks for the good work.

(In reply to Michele Calgaro from comment #24)
<snip>
> This seems to be now deterministic, I can repeat it several times.
> I guess this is the "Konqueror way", i.e. when selecting more than one file
> with the mouse or the keyboard, we enter a "multiple select allowed" mode,
> which require pressing ESC to exit from.

All of what you describe sounds correct and intended.  That last bit about multiple select mode is a good way to describe it.

If you look carefully you will notice that even in single select mode the focus rectangle (keyboard cursor) is still there, it's just hard to see around the solid blue selection indicator  Maybe this will help you understand the intention of the selection modes a bit better? ;-)

> I am not going to reopen this bug report for v14.0.0, but instead I will
> file a new bug report for post v14.0.0 for implementing an option to allow
> the user to choose his/her preferred behavior.

Sounds good.  When opening that report please post the bug number here so that anyone reading this (lengthy) discussion can link over.

> Tim, thanks for the good work.

No problem, glad it's improved even if it's not (yet) your cup of tea!

Tim

I filed bug 2154 for the enhancement user option.