ProperTree: [BUG] Unsaved changes on double click

Steps to reproduce the bug

  1. Open a .plist file
  2. Double click on any text field but DO NOT change the content
  3. ProperTree reports unsaved changes

Expected behaviour

ProperTree shouldn’t report unsaved changes if there’s no change (everyone would agree on that 😄)

Any possible fix?

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 25 (13 by maintainers)

Most upvoted comments

I just checked but still presents the same issue. Actually it seems that only with DATA type fields it creates the problem. Just for the sake of ease, I compared the SHA-1 hashes BEFORE and AFTER the - Edited in the ProperTree window title, but the hashes are still the same. At this point wouldn’t it be easier to display - Edited only if the hash of the file changes?

Just as a side note on this - it’s possible, but would require serializing the plist, then gathering a checksum every time something may or may not be changed - which could end up being very slow on larger plists, slower hardware, or with users that make quick edits (or even just enter then esc a ton). I’m hoping to be able to just catch any changes the user might make, apply some simple-ish checks to see if we actually changed anything - then apply the - Edited as needed.

YES IT WORKS!!! Sadly I can only test on macOS. Have you checked that the issue seems fixed also in Win and Linux?

Perfect! As for Windows and Linux - I’ve not even been able to reproduce the double-click/drag-oriented issue locally, so I’ve just been going off your debugging, and I don’t personally use Linux so that will have to be checked by other users I suppose.

The changes are pushed though - and I’ll leave this issue open for awhile in case anyone else runs into it - but if it goes a couple weeks without additions, I’ll consider it closed.

Thanks for testing, glad we got it ironed out. Let me know if you run into other oddities!

-CorpNewt

That making the code work doesn’t really make sense though - as it’s immediately evaluated in the next line if the function didn’t return:

        # We moved it - make sure it shows as edited
        if not self.edited:
            self.edited = True
            self.title(self.title()+" - Edited")

And if we turn off the self.edited, but the file had already been edited, the title would become - Edited - Edited - which just adds another bug. I’ll see if I can reorder when the drag locks are applied to avoid any sort of race conditions.

Yeah no worries, I changed it with from. Let me test it and report you back the values

Huh, that super weird. There shouldn’t be any difference in the code when double clicking those two dicts but I’ve likely missed something. I’ll look after work and see. Thanks!