Commit behaviour for in-line editing

Help improve MediaMonkey 5 by testing the latest pre-release builds, and reporting bugs and feature requests.

Moderator: Gurus

MattTown
Posts: 251
Joined: Sun Mar 15, 2009 5:09 pm
Location: Australia

Commit behaviour for in-line editing

Post by MattTown »

Hi,

I'm doing lots of database updates via inline editing, generally to a bunch of custom fields and the Comments field. I have found that an edit to an inline field will be committed if:
  • I press enter or
  • I click on another field in the line being edited or
  • I select another line on the same screen without moving the view.
I have also found that if I scroll the view sideways or up or down (for example to see more file or album context), the edit is abandoned.

I would like this behaviour to be changed so that if an edit under way and the view is moved then the edit is written to the database rather than being abandoned.

Cheers

Matt
MM 2024.3003 (WEF 9 Mar 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 25K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Lowlander
Posts: 56492
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: Commit behaviour for in-line editing

Post by Lowlander »

I think the risk here is unintentional edits, especially if the field to be edited is out of view.

For example you accidentally engage in-line edit and scroll away not noticing that key presses are editing.

I'm not sure if that's the reasoning behind this behavior.

Inline edits allow you to edit tags directly in the Filelisting: https://www.mediamonkey.com/wiki/WebHel ... Media_Tree
Rob_S
Posts: 879
Joined: Wed Mar 10, 2021 1:53 pm

Re: Commit behaviour for in-line editing

Post by Rob_S »

I would not like edits to be committed merely by scrolling away from my location.

Current implementation works fine for me, and I use it a lot.

If you want to commit, press enter, and then scroll is better.
Using 5.1 LATEST alpha or beta build on Windows 10, HP laptop, managing 13k tracks
MattTown
Posts: 251
Joined: Sun Mar 15, 2009 5:09 pm
Location: Australia

Re: Commit behaviour for in-line editing

Post by MattTown »

Lowlander wrote: Wed Jul 27, 2022 12:18 pm I think the risk here is unintentional edits, especially if the field to be edited is out of view.
Thanks for the response Lowlander.

I understand the issue of unintended edits but my experience is that it is actually somewhat *difficult* to initiate an inline edit - I have had to learn a specific double click timing and careful location of the cursor to get editing to initiate in the field that I want (apart from rating - reported separately). And even then I sometimes have to try several times to get a field to edit, especially if I'm not near the left edge of the field.

I seek clarification of your point about an edited field being out of view - you can't initiate an inline edit of a field unless it is in view, so I don't understand what you're getting at there. My perception is that the chances of an untended edit of an inline field is low, unless you're in the habit of randomly clicking around the screen, which is not smart behaviour in the first place.

I have lost many more uncompleted edits to intuitive screen moves than I have had unwanted edits. I understand that it is sensible to bias behaviour to protect data, but a balance with usability has to be struck.

Cheers
MM 2024.3003 (WEF 9 Mar 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 25K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
MattTown
Posts: 251
Joined: Sun Mar 15, 2009 5:09 pm
Location: Australia

Re: Commit behaviour for in-line editing

Post by MattTown »

Rob_S wrote: Wed Jul 27, 2022 1:24 pm I would not like edits to be committed merely by scrolling away from my location.

Current implementation works fine for me, and I use it a lot.

If you want to commit, press enter, and then scroll is better.
Thanks Rob,

I understand that we probably all approach this complex and capable system in different ways. I am stuck with pressing enter to complete an edit and do manage to do that most times. But (repeating the point made to Lowlander above) that I frequently want to see other data before completing a field edit and, over decades of software use, am pretty much hardwired to go find (scroll to) that data before completing the edit.

So commit on scroll would suit me better, but if it doesn't get any traction then I'll just get on with it.

Cheers
MM 2024.3003 (WEF 9 Mar 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 25K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Lowlander
Posts: 56492
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: Commit behaviour for in-line editing

Post by Lowlander »

You could start an inline edit in view and scroll out of view. Or of it closes on scroll out of view, it would be a commit.
MattTown
Posts: 251
Joined: Sun Mar 15, 2009 5:09 pm
Location: Australia

Re: Commit behaviour for in-line editing

Post by MattTown »

Hi Lowlander
Lowlander wrote: Fri Jul 29, 2022 12:04 pm You could start an inline edit in view and scroll out of view.
In my experience, if I start an inline edit in view and scroll out of view then the edit is abandoned, in every instance. If there is a way of not having a scroll abandon an inline edit then I'd love to hear it.
Lowlander wrote: Fri Jul 29, 2022 12:04 pm Or of it closes on scroll out of view, it would be a commit.
I don't understand what you're saying here - an inline edit can only be initiated in view. I haven't found a way of having an in-view edit scroll out of view and be committed, can you elaborate please?

Cheers
MM 2024.3003 (WEF 9 Mar 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 25K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
MattTown
Posts: 251
Joined: Sun Mar 15, 2009 5:09 pm
Location: Australia

Re: Commit behaviour for in-line editing

Post by MattTown »

Another annoyance with in-line editing for me is that in my system (current MM but slow hardware) the black background that allows the editing of a inline field sometimes lags by a second behind the dotted outline selecting the field. So, on my system, the sequence for inline-edits often is:
  • Use tab to move from one main panel edit field to the next (typically a Custom Field for me)
  • dotted line appears around the field
  • <variable delay> black edit background fills the field
  • edit the field contents
  • tab onwards.
The problem for me is that the occasional delay between the dotted line outlining the field and the black edit background causes keystrokes entered then to be interpreted as search request and my editing view gets blown away to the search result. The new functionality to use ESC to undo the search does help but does not always work. When I'm doing lots of editing this can happen about once every half hour or so, and that gets tedious.

Could the code could be examined to see whether that delay between outline and black edit background can be minimised or eliminated? I know that having a slow and small system probably exacerbates this problem, but it still is a problem and might be behind some of the user experience problems you get.

Cheers
Matt
MM 2024.3003 (WEF 9 Mar 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 25K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
MattTown
Posts: 251
Joined: Sun Mar 15, 2009 5:09 pm
Location: Australia

In-line Editing - Delay to Edit Background

Post by MattTown »

Hi,

I had made this point in another thread but that got no traction. This particular matter is subtly different to the original thread so I thought it was worth a separate thread.

A persistant annoyance with in-line editing for me is that in my system (current MM but slow hardware) the black background that allows the editing of a inline field sometimes lags by one or more seconds behind the dotted outline selecting the field.

So, on my system a typical sequence for successful inline-edits is:
  • Use tab to move from one main panel edit field to the next (typically a Custom Field for me)
  • dotted line appears around the field
  • <occasional delay> black edit background fills the field
  • typing to edit the field contents
  • tab onwards.
The problem occurs when I type during the occasional delay between the dotted line outlining the field and the black edit background. If I type a second before the black edit background turns up then the keystrokes get interpreted as a search request and my editing view gets blown away to the search result.

The typical sequence with an edit background delay is:
  • Use tab to move forward
  • dotted line appears around the field
  • <1-2 sec delay> several characters typed in
  • search box at top right is invoked and typed characters initiate a search
  • edit view gets blown away to search view
  • delete search characters and get the main panel back to the previous edit view.
The new functionality to use ESC to undo the search does help but does not always work. Note - the "previous view" icon just takes me to the top of the All Tracks list, well away from my edit location. When I'm doing lots of editing this can happen about once every half hour or so, and that gets tedious. I have taken to having a search for artist or album that can be readily invoked through the search pulldown to rapidly return to the edit view, but that is a workaround that should not be necessary in the first place.

Could the code could be examined to see whether that delay between outline and black edit background can be minimised or eliminated? I know that having a slow and small system probably exacerbates this problem, but it still is a problem and might be behind some of the user experience problems you get.

Cheers
Matt
MM 2024.3003 (WEF 9 Mar 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 25K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
MattTown
Posts: 251
Joined: Sun Mar 15, 2009 5:09 pm
Location: Australia

Re: Commit behaviour for in-line editing

Post by MattTown »

I have found a solution which fixes my overall search blowing away edit problem. There is a (now?) a control in Tools > Options > Search to "Show results only after pressing ENTER". For me, that has fixed my main complaint about the UI immediately changing an edit view to a search view. Now if I type ahead of the capacity of the system to show me a black edit background, the only thing that happens is that the characters go to search box without (thankfully!) immedately changing the view away from my established edit view. It is then a simple matter to erase those errant characters and get on with the intended edit.
Has that always been there? If not, thanks for updating the system. If so, guidance to use it would have saved me months of frustration.
MM 2024.3003 (WEF 9 Mar 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 25K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Lowlander
Posts: 56492
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: Commit behaviour for in-line editing

Post by Lowlander »

No, that option is new.
MattTown
Posts: 251
Joined: Sun Mar 15, 2009 5:09 pm
Location: Australia

Re: Commit behaviour for in-line editing

Post by MattTown »

Awesome, thanks. It has made a big difference to the usability of the system for me.
Cheers
MM 2024.3003 (WEF 9 Mar 2024, Portable Mode), Gold lifetime license, user since 2009.
Currently 25K files. Library and music files are on a separate partition (E:\) on external USB drive.
Windows Surface Book (Original), i5, 8GB RAM, 250GB SSD.
Win10 Home 64 bit, update: 22H2 19045.3570
MMA 2.0.0.1103, Android 13 on Nokia XR20, music files on SD card.
Post Reply