Dear Christian, Personally I wouldn't remove the tree widget altogether for various reasons:
1- Tree allows many people to contextualize where they are looking at. I know where my backups are, and I personally want to go there quickly or have a fallback if the auto-search fails for some reason or takes too long, because...
2- My backups may not be on a fast SSD, or on a USB hard drive at all, but somewhere I mount via FUSE or somewhere over network. We can't guarantee the size of these volumes. My last desktop had more than 25TB of storage on board. Spinning three disks up and searching all of them will take minutes in the best case. Having a tree in my view and quickly navigating there will always be faster.
3- A well groomed and old BiT backup can grow up to a couple of terabytes depending on what you are storing for how long. Again a tree can be faster.
If there is a need to simplify things UX wise, there are some options. - Hide the tree widget behind something collapsible, and keep it hidden.- If the search takes more than 30 seconds, inform user that there's a tree widget available if they want to navigate faster. - If you really want to remove the tree widget, it can be replaced with an "Open..." button which spawns a folder selection dialog, which is a self-contained widget which might reduce the code maintenance a bit.
As a general believer in "Magic Software", I found out that having no advanced controls make things very hard for users if the happy path fails somehow.
Hope this helps, Cheers, Hakan On 7/22/25 11:04 AM, c.bu...@posteo.jp wrote:
Hello Folks,I am interested in your opinions. Maybe I simplify this topic to much and miss something.A fresh installed and not configured BIT will ask if you want to restore an existing configuration (from a backup somewhere else). The dialog [1] [2] to select backup folder containing the config that should be restored is the topic here.The dialog shows a directory tree to encourage the user to select the folder containing the config file.I wonder if this dir tree widget is even useful in this context.The dialog runs an extra thread in background search the file system for config files. That thread updates the related tree entries, so that the QLabel below that tree widget can display information of profiles found [1] or if nothing was found [2].So why not throw away that tree widget and just present the search result of the thread running in the background? The user just need to wait some seconds in the beginning until the search for config files is finished.Maybe add an extra button with a DirSelectDialog behind.It would simplify the code. It would remove the threading logic and tree-model-filterproxy-logic of the tree widget.Any suggestions and thoughts about it? Regards, Christian[1] -- <https://translate.codeberg.org/media/screenshots/ bit_dlg_import_config_found.png> [2] -- <https://translate.codeberg.org/media/screenshots/ bit_dlg_import_config.png>_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-le...@python.org https://mail.python.org/mailman3//lists/bit-dev.python.org Member address: ha...@bayindir.org
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-le...@python.org https://mail.python.org/mailman3//lists/bit-dev.python.org Member address: arch...@mail-archive.com
