Cursor positioning after deleting files [FIXED]

Questions, glitches, bugs and crashes
Locked
User avatar
darek
Posts: 179
Joined: Thu Jul 16, 2015 4:50 pm
Location: Warsaw, Poland
Contact:

Cursor positioning after deleting files [FIXED]

Post by darek » Mon Aug 24, 2015 9:23 am

Something was bugging me for a while and just today I've tracked down the problem. See this screenshot (oops.. the board won't allow anything bigger than 200k? had to recompress):
cursor1.jpg
cursor1.jpg (106.03 KiB) Viewed 7574 times
I've selected files to delete, moved the cursor within the red range. Now, after deleting, since the file pointed by the cursor will be removed, I'd expect the cursor to move to the first available file, that is "2015-06-22 16.05.14.png". However, here's what happens:
cursor2.jpg
cursor2.jpg (61.65 KiB) Viewed 7574 times
It looks like the cursor gets confused by this scenario and I have to track down my previous position by hand.

User avatar
mike
Posts: 1060
Joined: Thu Jul 16, 2015 5:35 am
Location: Exeter, UK

Re: Cursor positioning after deleting files

Post by mike » Tue Aug 25, 2015 7:21 am

Darek,
Yep, there was no "true" mechanism to automatically move focus to "next" element.
It is tricky since there are different sorting modes, like date or size etc and the term "next" may mean anything :)
I've done some work for better prediction and perhaps it would be sufficient, you can check the results here:
http://filesmanager.info/downloads/prev ... (1216).zip

User avatar
darek
Posts: 179
Joined: Thu Jul 16, 2015 4:50 pm
Location: Warsaw, Poland
Contact:

Re: Cursor positioning after deleting files

Post by darek » Tue Aug 25, 2015 5:52 pm

Hmm... I'd say "next" in that context would mean the next in the list, visually. I've just tried this new build and it seems much better now, thanks! But I'd have to play with this a little longer to know for sure.

BTW, knowing "how the sausage is made" I'm usually wary of using these preview builds for daily work and I prefer to stick for official releases. Is this reasonable to expect that the official versions are more stable? Or can I just switch to the most recent preview build safely, because you're confident it's all good and safe?

Oh, which also brings another point... ;) How much confidence in general do you have in Files? Because when I'm moving large amounts of data between folders I'd really hate for example for a file to get lost of corrupted. I have no way of verifying the effect of copying, moving or other transformations (which will get more complex when "feed to listbox" gets implemented), so I have to trust that Files does the job properly. With tools like Total Commander or Finder, I can be sure that lots of people are using them, so if there was any serious issue, then it would be caught by someone. But with less popular tools like Files, I can only trust that the developer knows what he's doing.... So, well, can I? ;) I know that you're an experienced programmer and a very smart guy, so that's certainly a lot. But do you have for example a suite of automated test to check for regressions, and so on?

And I don't come off as offensive here... I'm just, you know, trying to feel it out the situation :)

User avatar
mike
Posts: 1060
Joined: Thu Jul 16, 2015 5:35 am
Location: Exeter, UK

Re: Cursor positioning after deleting files

Post by mike » Wed Aug 26, 2015 3:59 am

darek wrote:Hmm... I'd say "next" in that context would mean the next in the list, visually. I've just tried this new build and it seems much better now, thanks! But I'd have to play with this a little longer to know for sure.
Just for clarification of what I meant - Files updates it's directory listings upon change notification from an underlying filesystem (a real OS X one, or something virtual like PSFS). This can be caused by (for example) deleting items from Files itself or from other apps like Finder - it doesn't matter much from this aspect. And now that issue arises - you have to figure out a "next" item (regarding some visual sorting) which comes after an element which is non-existing now :)
Just trying to explain why it's a bit tricky and wasn't implemented before.
darek wrote: BTW, knowing "how the sausage is made" I'm usually wary of using these preview builds for daily work and I prefer to stick for official releases. Is this reasonable to expect that the official versions are more stable? Or can I just switch to the most recent preview build safely, because you're confident it's all good and safe?

Oh, which also brings another point... ;) How much confidence in general do you have in Files? Because when I'm moving large amounts of data between folders I'd really hate for example for a file to get lost of corrupted. I have no way of verifying the effect of copying, moving or other transformations (which will get more complex when "feed to listbox" gets implemented), so I have to trust that Files does the job properly. With tools like Total Commander or Finder, I can be sure that lots of people are using them, so if there was any serious issue, then it would be caught by someone. But with less popular tools like Files, I can only trust that the developer knows what he's doing.... So, well, can I? ;) I know that you're an experienced programmer and a very smart guy, so that's certainly a lot. But do you have for example a suite of automated test to check for regressions, and so on?

And I don't come off as offensive here... I'm just, you know, trying to feel it out the situation :)
Well... to begin with, if someone will ask me if my software is bug-free - I'll never answer "yes" :)

There're several dozen of automated tests running after every source code commit on a separate build machine.
I'm pretty confident that chance of data corruption using Files is close to non-existence, BUT any data should be backed up with some decent system!
(in my setup there're three of them simultaneously - TimeMachine, CrashPlan and DropBox)

As for current preview builds - there can be some visual glitches, missing translation or similar minor things, but otherwise they should be stable, since most of recent changes are very localised and without big impact to whole application.
Not sure if this would be applicable to 1.1.0 previews when I'll start a big refactoring to provide "feed to listbox" functionality - it'll bring a lot of changes to codebase.

User avatar
darek
Posts: 179
Joined: Thu Jul 16, 2015 4:50 pm
Location: Warsaw, Poland
Contact:

Re: Cursor positioning after deleting files [FIXED]

Post by darek » Wed Aug 26, 2015 6:40 am

Oh, sure thing, bugs are unavoidable. It's only a matter of making sure you do your best to filter out as much of them as possible. Experience and coding discipline take care of the biggest issues, automated tests help with smaller mistakes and regressions so I'm super happy to know that you're thinking about that :)

Mike, I also believe this is something that would be cool to include on your marketing website. Some people will be curious how trustworthy a tool like this is and including a few words with *specific* things you do to make sure it won't delete or corrupt user's files will surely help.

And backups: of course :) I'm using 3 layers myself: Dropbox, Arq and rsync to external, offsite drives.

All right then, so I'm switching to the preview build. Oh, and I'm getting excited about the changes coming in 1.1.0. Sounds like it will be a big update.

Locked