Feedback required: double click in tables

[Zini]

Feature: https://bugs.openmw.org/issues/1918

The idea here is that double clicking in a table row (representing a record) should trigger the edit record action. Which is not possible, since double click is already used to trigger the cell edit. That's just how Qt tables work.

Now as I noted in the issue linked above we could use double click with modifier keys (shfit, ctrl) to provide access to edit record (and maybe other actions) via double click.

But there is a problem with that. A double click starts with a single click. And a single click with shift/ctrl will modify the selection in the table beyond just selected the cell that is clicked upon. This is an undesirable side-effect that we can not avoid (at least I have no idea how).

Now the question is: Go with it and accept the side-effect or just scratch this feature? We will still offer keyboard-shortcuts for quick access to edit record and other actions, so the double click feature isn't absolutely needed. But it would still be kinda convenient.

Opinions?

[sirherrbatka]

just scratch this feature

IMHO. BTW, can we have single key shortcuts? For instance F5 to edit?

[Nomadic1]

Why not press Enter or Space or something to edit?

[Zini]

Getting a bit confused with the terminology. There is "edit the cell in place" vs opening a dialogue subview (which is called "edit record" in the context menu). Sorry, not sure which one both of you are referring to here.

[Greendogo]

I advocate double-clicking opening the full edit table for an object instead of editing the cell in the current table.

I really think the way it is now should be the secondary method of editing and the main edit window (the one you have to currently open through a right click menu) of an object should be the primary way, accessed through the easiest action possible (double-clicking).

My reasoning is that the full attenuated controls for setting the properties of an object are not available in the table view. I think it would be more realistic to expect most people would want to deal with the full controls often enough they'd want it to be easier to access than a right-click->move-mouse->left-click action.

I may be wrong about end-user preference; what do others think?

[Okulo]

Can't you just put an "edit cell" function in the context menu?

Alternatively, what if, when you single click on a text cell, it selects the row and puts focus on the cell. Then, when you start typing, it empties the cell and allows you to write "over" the old value?

[Zini]

Using (hardcoded, unmodified) double click to open the dialogue subview is not an option. That would leave us without a way to trigger an in place cell edit via mouse.

My reasoning is that the full attenuated controls for setting the properties of an object are not available in the table view. I think it would be more realistic to expect most people would want to deal with the full controls often enough they'd want it to be easier to access than a right-click->move-mouse->left-click action.

I may be wrong about end-user preference; what do others think?

I would expect users to primarily work within the table. There aren't actually that many fields that can only be accessed in the dialogue subview. That is definitely the secondary interaction mode.

Can't you just put an "edit cell" function in the context menu?

I do not agree with this option. In place editing will be the primary way the user is interacting with the table. Forcing him to go through the context menu for that sounds like very bad usability.

Alternatively, what if, when you single click on a text cell, it selects the row and puts focus on the cell. Then, when you start typing, it empties the cell and allows you to write "over" the old value?

We need to work within the framework that is provided by Qt. I don't even know if what you propose is possible without hacking Qt itself. And it wouldn't work for dropdown list type cells anyway.

[Zini]

Apparently I am an idiot. There is a really easy way to work around the side effect I mentioned in my original posting. Which means the whole discussion is pointless. We can have a fully configurable system with double click, shift-double-click, ctrl-double-click and shift-ctrl-double-click each triggering what ever action the user desires. Sorry for being dense.

[Greendogo]

Nice!

I'll take your word for what user-preference will be. You designed it so you should know better than I; my bias is definitely partially influenced by Beth's system- I just 'expect' the dialogue subview to be the most reminiscent of what I'm used to working with so I figure those who've worked with Beth's CS may feel the same until we all gain more skill with your system

[Zini]

Actually, this feature is really cool. Adds a lot of usability. The only downside is that there aren't enough modifier keys do bind all possible actions to it.

The feature is now available on github (in my double branch). I'll try to wrap it up today and merge it into master.