Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In-place editing of track file #71

Open
Friptick opened this issue May 3, 2023 · 6 comments
Open

In-place editing of track file #71

Friptick opened this issue May 3, 2023 · 6 comments

Comments

@Friptick
Copy link

Friptick commented May 3, 2023

Is it, or might it in future be, possible to edit a (say) GPX file without having to go through a multi-step "export" process?

Maybe I'm missing something because it seems like obviously better UX than what I see at present.

Use case: I want to delete ("prune") a waypoint in a .gpx track coming from (say) Osmand. Here's the current fastest workflow:

  1. Run gpsprune $filename.gpx (or, slower, use the file opener widget to open it)
  2. Select and delete point with cursor (fast!)
  3. File > Export GPX
  4. OK accepting defaults
  5. Manually select filename of the (currently open) file from a list
  6. Save
  7. Overwrite

Quite fastidious!

Perhaps I'm missing something, or maybe there's a quicker workaround?

@activityworkshop
Copy link
Owner

Thanks for your feedback, that's interesting. And you're absolutely right, it does take a few clicks more than you might expect.

For loading the file, you're right, you can type in the filename to the launch command (or use tab to autocomplete, or use * as a wildcard). If you've opened the file before, it might still be in your "Recent files" list, but yes otherwise you'll have to use your file opener widget, I can't see a way to simplify that. GpsPrune remembers the directory, so if the next file is in the same directory then you shouldn't have to navigate as much. Your file opener dialog should allow you to type part of the name as well, to narrow the search.

As for saving, yes I understand what you mean. When I open a text file in a text editor, then I can just press "Save" and it knows that I want to save it back to the same place that I opened it from, without asking me if I'm sure. Perhaps there are some ways in which GpsPrune could get at least a little bit closer to that.

Part of the reason that GpsPrune doesn't make overwriting files so simple is that the coordinate files are valuable, and if I've spent hours collecting coordinate data I want to be really sure that I'm not deleting it all by accident. In fact I usually save edits to a different file than the one I loaded the data from. Secondly I really do want to see the options when I'm saving, so that I know what I'm saving, so for me I don't mind the extra "OK" click. And thirdly there's a bit of a conceptual difference - a text editor loads a single file, and if I load a second file then that opens up in a separate tab (with a separate save button). GpsPrune imports any kinds of files together into a track, so if I've loaded a gpx, a kmz and a txt, which of those three files am I saving to when I just press "Save" without any questions?

I guess the answer would be to have a menu option File -> Overwrite file "something.gpx" like Gimp has for example. And presumably that option would only become available when the number of files loaded is exactly 1, otherwise it's invisible or grayed out. In that case it still might make sense to show the options dialog (depending on the file type), but you could avoid the file selection and the confirmation about overwriting, because you've already explicitly asked to overwrite.

So to answer your question - no, I don't think you've missed something, it really does require four/five clicks to export a gpx file to overwrite an existing one. If we had a menu option for overwriting we could reduce this to two, but that's probably too late for version 23 now; we can put it on the list for a later release if you agree.

@Friptick
Copy link
Author

Friptick commented May 9, 2023

Thanks, useful. Yes, when overwriting without any built-in versioning, there does need to be a protection mechanism. IMO the ideal design pattern is an ephemeral Undo button which disappears after a few seconds, but a Confirm step is fine too.

I really do want to see the options when I'm saving, so that I know what I'm saving, so for me I don't mind the extra "OK" click

Except it's not just that, you also need to manually identify and select the filename from the folder because the filename field is empty by default (stage 5 above). That adds quite a lot of friction. If it were selected already then it would just be a question of hammering OK as you say. This might be a solvable Java toolkit issue or even a bug I'm experiencing, what do you think?

@activityworkshop
Copy link
Owner

I really do want to see the options when I'm saving, so that I know what I'm saving, so for me I don't mind the extra "OK" click

That sentence was specifically referring to your point 4, not point 5.

I addressed your point 5 separately in my final two paragraphs.

@Friptick
Copy link
Author

Friptick commented May 10, 2023

The improvement to

Manually select filename of the (currently open) file from a list

that I was suggesting (but didn't make clear) was that instead of

the answer would be to have a menu option File -> Overwrite file "something.gpx" like Gimp has for example. And presumably that option would only become available when the number of files loaded is exactly 1

you could just have the filename selected by default at stage 5 in the case that only that one file is loaded. That seems like good UX practice in any case.

(ADDENDUM: Was just doing all this again for my regular file and I can definitely say that if the aim is to "to be really sure that I'm not deleting it all by accident" (it is), then there is very much a problem with this current stage 5. After all, you have to be super careful to select the file you have just edited and not another one - or else you will wipe that other one and end up with two files with the same contents! Disaster. And very easy to do if the files have similar names. This really is the heart of the issue to be resolved here, by whatever means. Number of clicks is secondary.)

Your Gimp-style "File > Overwrite" (instead or additionally) would be a very simple solution, true.

Basically: if the user is opening and editing one file, then they likely don't want to "export" anything, they just want to "save".

What do you think?

@activityworkshop
Copy link
Owner

There's one more detail which I forgot to mention earlier.
Thanks to Issue #58, there's a small change coming with version 23:

File - Export GPX: Could use Name field to then generate default filename (eg. Name=Day1, filename=Day1.gpx)

The original intention was that when I'm exporting my data to a new gpx file, I can enter a track name, and then when I get to choose a filename for it, it uses the name which I've already entered as a suggestion. Then I can edit that filename if I want, and then export the file.

What now happens with version 23 is that you can load a GPX file which already contains a name, and this name will be remembered when you later export the track. If you don't edit this name, then it's possible that the suggested filename already exists (because you accepted this same suggestion last time you exported). So it's important that you check this carefully when it offers to overwrite the existing file or not.

@Friptick
Copy link
Author

What now happens with version 23 is that you can load a GPX file which already contains a name, and this name will be remembered when you later export the track

By "contains a name" you mean <metadata><name>The Name</name></metadata>? If so, okay. Might be an idea to strip any spaces in the generated filename.

The original intention was that when I'm exporting my data to a new gpx file

But what about the other, simpler, pattern of just opening and saving one GPX file? I'm bothered by this emphasis on exporting, which implies creating a second file. Would it not be straightforward to add a parallel "Save" function - with a single "Confirm overwrite" step as appropriate - whenever there is just one file opened? Personally, this is my only workflow.

Anyway, I believe the really important bit is to remove the manual selection of the file (stage 5 above) because it is super risky and error-prone. Any solution that allows me to click "Confirm" mindlessly and know that I won't overwrite another file is a great step forward.

Keep up the good work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants