Bug 334577 - Leaving and returning to a scrolled query finds the scroll bar reset to its home position
Summary: Leaving and returning to a scrolled query finds the scroll bar reset to its h...
Status: CLOSED FIXED
Alias: None
Product: KEXI
Classification: Applications
Component: Queries (show other bugs)
Version: 2.9 Alpha
Platform: Mint (Ubuntu based) Linux
: NOR minor
Target Milestone: ---
Assignee: Jarosław Staniek
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2014-05-10 10:32 UTC by Ian Balchin
Modified: 2014-05-14 19:58 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 2.8.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Balchin 2014-05-10 10:32:01 UTC
I run a query and obtain a multi-page result. I scroll down to the particular record in which I am interested. I leave that tabbed window for, say, a form. When I return to that query window the scroll bar has reset to the top position.

Reproducible: Always

Steps to Reproduce:
1. open a query tab, then another tab
2. run the query with parameters that will return several pages of results
3. scroll down a page or so, and select a row
4. note the position of the scroll bar on the right
5. leave that query window for the other tab
6. return to the intial query window
7. note the position of the scroll bar
Actual Results:  
the scroll bar resets to the top position and the first page of rows

Expected Results:  
that the scroll bar stayed where it was left with the selected row still visible

Again, this behaviour introduces the necessity to do again what has already been done.
Comment 1 Jarosław Staniek 2014-05-10 11:08:32 UTC
Thanks for the quality report!
Comment 2 Jarosław Staniek 2014-05-10 23:04:37 UTC
Other observations:
- The same applies to tabular data view of tables as this is in fact the same component (table's data is a full SELECT query in fact)
- Horizontal position isn't retained too
- Even if we focus a distant cell, after returning to the view, it's scrolled to top-left corner
- in Forms the view's offset is retained but there's other issue instead: cursor position and text selection (if any) isn't retained: active field gets refocused when we return to a form view; I encourage to file another bug for this
Comment 3 Jarosław Staniek 2014-05-10 23:24:29 UTC
Applies to 2.8 too, so it would be good to have it fixed there.
Comment 4 Ian Balchin 2014-05-13 18:24:08 UTC
Jaroslaw, hi,

Your comment:

"- in Forms the view's offset is retained but there's other issue instead: cursor position and text selection (if any) isn't retained: active field gets refocused when we return to a form view; I encourage to file another bug for this"

Either I misunderstand this  or my 2.9 Pre-Alpha builds are exempt from this. If I highlight text in a Form field, then leave to look at another tab and may be do some action in that tab, then the highlighted text is still highlighted when I return to the form, and the cursor is still where I left it, even the scrolled position is retained  (is this what you mean by  ' the view's offset ' ?). 

Maybe I have not got the details correct under which your described action/results occur?

regards
Ian
Comment 5 Jarosław Staniek 2014-05-14 09:54:41 UTC
Will be fixed today in master and 2.8.4.
Comment 6 Jarosław Staniek 2014-05-14 10:06:37 UTC
By the 'view's offset' I mean position of scrollbars in a form view. I think we agree they're not changing after switching back to the form view.

Regarding text selection and cursor position, these are retained for Text Editor widgets (multiline box)  but not for Text Box (single line) widgets. So there's something to fix in Text Box.
Comment 7 Ian Balchin 2014-05-14 18:50:32 UTC
Hello, Jarosław,

On Wed, 14 May 2014 10:06:37 +0000
Jarosław Staniek <staniek@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=334577
> 
> --- Comment #6 from Jarosław Staniek <staniek@kde.org> ---
> By the 'view's offset' I mean position of scrollbars in a form view.
> I think we agree they're not changing after switching back to the
> form view.
Yes, I am with that one

> 
> Regarding text selection and cursor position, these are retained for
> Text Editor widgets (multiline box)  but not for Text Box (single
> line) widgets. So there's something to fix in Text Box.
You were way ahead of me on this one! I did not appreciate the
difference between Text Boxes and the Text Editor Boxes, and in my
main application all boxes were Text Editor Boxes.

I am experimenting, updating, changing as needed. I will see how the
plain Text Boxes perform and make an appropriate bug submission unless
someone gets there before me - may be a little while.

regards
Ian


-----
Ian Balchin
Fables Bookshop, Grahamstown.
Comment 8 Jarosław Staniek 2014-05-14 19:55:59 UTC
Git commit c84a9e15873d55719db3f8f325521478f873313a by Jaroslaw Staniek.
Committed on 14/05/2014 at 18:33.
Pushed by staniek into branch 'calligra/2.8'.

Only move to initial top-left position in table view on initial show
FIXED-IN:2.8.4
REVIEW:118134

M  +4    -1    kexi/widget/tableview/kexitableview.cpp
M  +1    -0    kexi/widget/tableview/kexitableview_p.cpp
M  +3    -0    kexi/widget/tableview/kexitableview_p.h

http://commits.kde.org/calligra/c84a9e15873d55719db3f8f325521478f873313a
Comment 9 Jarosław Staniek 2014-05-14 19:57:15 UTC
Git commit 64ef07cc53613c531b912220919ad1bcad9308a9 by Jaroslaw Staniek.
Committed on 14/05/2014 at 18:33.
Pushed by staniek into branch 'master'.

Only move to initial top-left position in table view on initial show
FIXED-IN:2.8.4
REVIEW:118134

M  +4    -1    kexi/widget/tableview/kexitableview.cpp
M  +1    -0    kexi/widget/tableview/kexitableview_p.cpp
M  +3    -0    kexi/widget/tableview/kexitableview_p.h

http://commits.kde.org/calligra/64ef07cc53613c531b912220919ad1bcad9308a9