• ell1e@leminal.space
    link
    fedilink
    English
    arrow-up
    4
    ·
    5 hours ago

    A simple sync would show you when it actually finishes. However, it has system-wide effects. Perhaps KDE could lobby for a similar action to become available that is limited to e.g. a specific process id?

    • folekaule@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      3 hours ago

      I would settle for checked-by-default “sync and wait” option. That way I can choose whether to cause a sync or not.

      • vinnymac@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        2 hours ago

        Often this is the correct pragmatic power user solution in UX design. Trying to solve it by default for everyone is much harder and will ultimately alienate some user.

        But when people get bothered by an experience it is much easier for them to find the hidden setting that makes them happy again. It also preserves the existing experience, while allowing for greater customization in the long term.

        Once a decent compromise is identified, that’s when it’s time to flip which setting gets to be the default.

        • folekaule@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          1 hour ago

          My motivation for calling for it to be the default was that it’s safer (in terms of data).

          Another UX principle is that of least surprise. I think it’s reasonable to assume that most users will expect the copy to be fully complete when the dialog closes, and that they will be surprised when their files are corrupted. Changing the behavior in the desktop to delay closing the dialog until any copying to removable media is complete should not be a controversial change.

          We’re seeing an influx of novice users to Linux. I don’t think we need a bunch “Linux ate my files” incidents if it can be avoided by a simple change, which itself can be easily reversed if you didn’t like it.