Details for the issue

What did you do?

I tried to resize a single column in the 'Browse Data' section of the app. I had no columns selected, but I did have a single row selected.

What did you expect to see?

Only the column I was trying to resize being resized.

What did you see instead?

ALL of the columns resizing, not just the specific one I was trying to resize. Making matters worse, due to a second issue (described below) this caused the column I was resizing to shoot off the side of the screen.

Explanation in Detail:

I believe the reason this is happening is there's a logic flaw in the column-resize code. Normally, to resize multiple columns at once, a person would use the column headers to select the columns they want to resize. This would select the entirety of those columns. Then resizing any one of them would make the rest of them match that column's width.

Note: This behavior does work as expected with one somewhat major caveat (issue 2 below.) But before we get there, the bigger, more frustrating issue is Issue 1 here.

Issue 1:
Your multi-column resizing logic doesn't check if a column is selected for inclusion, it checks if any part (i.e. even a single field) within that column is selected and incorrectly includes that column in the resizing operation if there is, which is not what a user would reasonably expect.

In this case, since I had a single row selected, that means every column has a selected field in it (for that row), and thus, every column was resized when I was only trying to resize a single one. Again, it should only ever operate on the exact column a user is resizing, plus any other completely-selected columns (i.e. those selected via their column headers), not just those that have a selection somewhere in them.

Selecting a row of data to 'highlight' it while you're looking for something, then resizing specific columns to show more data for that column if needed is a very common use-case when browsing through data. Your current design prohibits that usage.

Making matters worse, this trashed all of the column widths I had manually set before with no way to undo that operation and in my table with tons of columns, this is really frustrating, exacerbated by issue 2 below as it caused the column I was looking at to go shooting off the right side of the screen.

Issue 2:
The other issue is the resizing of a column only matches up exactly with the mouse when it's the only column being resized, or it's the first column if you're sizing more than one. If you resize any other column (i.e. you have selected 1-4 and are resizing 2 or higher), the mouse 'separates' from what's underneath it providing a disjointed feeling to the user. The further to the right the column is, the more magnified this disjointing becomes.

Here's a scenario explaining this. Say all columns in a browse tab are currently at a width of 100 units. The edges of the first four columns are as follows:

Column 1: L=0, R=100
Column 2: L=100, R=200
Column 3: L=200, R=300
Column 4: L=300, R=400

You now select columns 1-4 by clicking on header 1 and dragging through to header 4. You now resize column 1 making it 10 units wider. The new results are this...

Column 1: L=0, R=110
Column 2: L=110, R=220
Column 3: L=220, R=330
Column 4: L=330, R=440

More importantly, when you started the resize-drag, the mouse started at position 100 and moved to position 110 (i.e. a delta of 10.) 110 perfectly lines up with the new right edge of column 1, also at 110, meaning the arrow is properly tracking the UI as a user would expect.

Now... same scenario but instead of resizing column 1, you resize column 4. In this case, the mouse starts at position 400 and is dragged to position 410 (again, same 10-unit delta so all columns are still resized to 110 units wide). However, the right edge of column 4 has now shot out to position 440 (same as before) meaning it's 30 units away from the mouse's current location back at 410. This 'disconnects' the mouse from what they are dragging and is not what a user would expect.

As stated, the more columns there are, the more this is affected. For instance, when you have ten columns selected, you'd be off by 90. 20 columns selected, you'd be off by 190. In the case above where I had a single row selected, which then included all the columns in my table, it was off by hundreds sending the column I was looking at, whizzing off to the right, far from where it started. This is the epitome of getting frustrated at software because there is no reasonable case where a user would ever want that!

How To Address This

The logic required to address this is to total up all the width-change deltas of columns to the left of the one you're resizing, then adjust the horizontal scrollbar by adding that amount to the current scroll position.

In this example where I'm resizing column 4, that means columns 1-3 are to the left. Since each changed by 10, that yielded a total-change-delta of 30. By adjusting the horizontal scrollbar by adding that 30 to the current scroll position, you give the illusion that the left edge of the column you're resizing is stationery (even though it's actually shifted by 30, but that shift was visually canceled by the reciprocal adjustment of the scrollbar) and the right edge of that column now perfectly tracks your mouse as expected. Try it. You'll see this is a much more natural response.

Important: You have to calculate the actual width-change delta for all columns to the left. You can't simply say "I resized it by 10, and there are three columns to the left, therefore the total is 30." An example of why is this scenario: Same as above, but this time, columns 1 through 3 are only 10 units wide when you start. Column 4 is still 100. When you resize column 4 to 110, it changed by only 10, but columns 1-3 each changed by 100 (they were 10 but are now 110, matching column 4), meaning that cumulative change-delta to the left is actually 300! That's how much you have to adjust the scrollbar by.

Note: There is one other issue and that's when the cumulative width-change of the columns to the left goes negative (i.e. you are shrinking column widths.) In that case there is the chance you can't adjust the scrollbar far enough as you can't set it less than zero.

For instance, if the scrollbar is currently at position 40 when you started, the mouse will only stay 'connected' to what's under it if the cumulative delta to the left of the resizing column is at most -40 and not less. Any more than that (i.e. -45) and you'll get that 'disconnected' feeling again because you can only offset the scrollbar by 40 so you'll be disconnected by 5.

Likewise, if the scrollbar is all the way to the left when you start, you can't do any compensation. This obviously is not an issue when widening columns as there is no upper limit. Only a lower-limit of zero.

Even so, when resizing that way, it's more natural, especially if at the start of the drag, you cached not only the width of those columns (to calculate the deltas) but also the starting position of the scrollbar and perform the math against that starting point, which would allow you to 'snap back correctly' should you drag it back under that 40 you started with.

Again, it's all in the user experience and this will make much more sense once you try it. You'll see it feels much more natural and 'connected' when the mouse stays over what you're resizing and things aren't unexpectedly moving underneath you.

Hope all that made sense.

Fix both of these issues and the columns will again resize as expected, and only when expected.

Useful extra information

The info below often helps, please fill it out if you're able to. :)

What operating system are you using?

• Windows: ( version: ___ )
• Linux: ( distro: ___ )
• Mac OS: ( version: 10.14.6 )
• Other: ___

What is your DB4S version?

• 3.11.2
• 3.11.1
• 3.10.1
• Other: ___

Did you also

• Try out the latest nightly version: https://github.com/sqlitebrowser/sqlitebrowser#nightly-builds
• Search for an existing similar issue: https://github.com/sqlitebrowser/sqlitebrowser/issues?utf8=%E2%9C%93&q=is%3Aissue%20