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

use list of libraries as a starting point #127

Closed

Conversation

yedpodtrzitko
Copy link
Collaborator

@yedpodtrzitko yedpodtrzitko commented May 3, 2024

This changes the behaviour when opening the application - instead of opening the last library (settings.last_library), it shows a list of all previously opened libraries:
Screenshot 2024-05-03 at 12 44 09

plus the setting to make it optional (default false)

Screenshot 2024-05-09 at 23 21 46

@yedpodtrzitko yedpodtrzitko marked this pull request as draft May 3, 2024 04:46
@yedpodtrzitko yedpodtrzitko force-pushed the yed/library-select branch 2 times, most recently from a7cba98 to a5441ab Compare May 3, 2024 05:22
@Loran425
Copy link
Collaborator

Loran425 commented May 4, 2024

I like the conceptual idea of recent libraries, but this is a fairly large departure from the current user experience.
A sub menu from an open recent would be what I'd expect from software like this (at least from most of the windows programs I've seen), but we're in alpha so worth discussing.

@yedpodtrzitko
Copy link
Collaborator Author

but this is a fairly large departure from the current user experience.

the current state is that when I open the app, it starts dozen of threads crunching thumbnails. The chance I really want to do it is (1 / number_of_libraries). With this change I can avoid doing that until I explicitly select the library I want to work with. Menu with list of recent libraries doesnt solve this issue.
If we're talking UX, the UX of given menu is generally horrible. Selecting library is something I do very often, so having such action available within a single click cant really be compared with a tiny nested menu a few clicks away.

@yedpodtrzitko yedpodtrzitko force-pushed the yed/library-select branch 2 times, most recently from d0cf0fb to dd106bc Compare May 4, 2024 11:17
@yedpodtrzitko yedpodtrzitko changed the title WIP: use list of libraries as a starting point use list of libraries as a starting point May 4, 2024
@yedpodtrzitko yedpodtrzitko marked this pull request as ready for review May 4, 2024 11:22
@Loran425
Copy link
Collaborator

Loran425 commented May 4, 2024

the current state is that when I open the app, it starts dozen of threads crunching thumbnails. The chance I really want to do it is (1 / number_of_libraries). With this change I can avoid doing that until I explicitly select the library I want to work with. Menu with list of recent libraries doesnt solve this issue.

Ahhh I see the difference in what you're looking for, looking to avoid the threading spool up just for a library that might be closed shortly after starting the program.

I know the open last library is intended to be a temporary option where the user would be allowed to have a preference of where they could select the starting behavior similar to how browsers do it.

  • Open last library
  • Open default library
  • Start Empty

Could add a preference for a library picker, I think one of the design decisions that's still up in the air is allowing multiple directories to feed a single library

If we're talking UX, the UX of given menu is generally horrible. Selecting library is something I do very often, so having such action available within a single click cant really be compared with a tiny nested menu a few clicks away.

Not sure I'd call it horrible, if someone is using a single library this is directly adding a step between starting the program and using the program. That's why I'm thinking it should be an option but not the only option, because I know I'd be annoyed by another click every time I start the program to test something or use it in my singular library, but I can see that opening the last library only to immediately open another library is causing frustration with the program on your end.

@Loran425 Loran425 added the UI/UX User interface and/or user experience label May 4, 2024
@yedpodtrzitko
Copy link
Collaborator Author

Thanks for feedback. Choice what should happen when app is opened sounds reasonable.

@yedpodtrzitko yedpodtrzitko force-pushed the yed/library-select branch 2 times, most recently from 9e3f736 to 2d2ea1b Compare May 9, 2024 15:19
@yedpodtrzitko
Copy link
Collaborator Author

PR updated to make this list optional

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
UI/UX User interface and/or user experience
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants