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

[WIP] crates widget #1656

Closed

Conversation

poelzi
Copy link
Contributor

@poelzi poelzi commented May 2, 2018

Adds a new widget that shows the crates the selected tracks are in.
The new library redesign makes it impossible to see the crates the
selection is in. Even the old design had problems with many crates.

Known Bugs:

  • Only LateNight and Deer skin. Needs more styling.
  • The Splitter wrongfully hides on some states of Cover Art and Crates List
  • The Crates that are not in all selected tracks should be displayed differently, but current solution seems not to work as expected.

@poelzi poelzi changed the title [WIP] Feature/createwidget2 [WIP] creates widget May 2, 2018
@Be-ing Be-ing changed the title [WIP] creates widget [WIP] crates widget May 2, 2018
@Be-ing
Copy link
Contributor

Be-ing commented May 2, 2018

Could you post a screenshot?

poelzi added 2 commits May 2, 2018 08:46
Adds a new widget that shows the crates the selected tracks are in.
The new library redesign makes it impossible to see the crates the
selection is in. Even the old design had problems with many crates.

Known Bugs:
- Only LateNight and Deer skin. Needs more styling.
- The Crates that are not in all selected tracks should be displayed differently, but current solution seems not to work as expected.
@poelzi
Copy link
Contributor Author

poelzi commented May 2, 2018

crates + coverart
crates

There are still some things todo. The crates list is the combined list of all selected tracks, I would like that crates that do not contain all tracks are slightly different styled, cursive maybe. Unfortunately, everything I tried did not work yet with QListView, even using separate subclasses for both types. Any ideas ?

@Be-ing
Copy link
Contributor

Be-ing commented May 2, 2018

Eh, I'm not sure this is the best way to present this information. I was thinking that list of crates a track is in could be shown in a new track table column. Thoughts?

@daschuer
Copy link
Member

daschuer commented May 2, 2018

I like the idea, to add a kind of track ID card next to the cover art. Later we may add other Infos as well.

A library coloumn solution, will only work well if a track is only in one crate. Additional crates might be hidden, and the crates path of nesting crates can be long. We have discussed similar issues with the location coloumn.
A coloumn is also handy to sort by crates. But this also works only if a track is only in one crate.

@poelzi
Copy link
Contributor Author

poelzi commented May 2, 2018

I use crates like tags and quite often I have tracks in 4-5 crates.
I thought about a column before but the space is just to limited.
Most of the time I'm not using the crates while playing but complex search filters.
Then I want to see in which crates the tracks are in, so I can avoid prelistening unuseful tags or use the tracks with useful tags first.
The feature is implemented so nobody has to use it, I want it like this and at least I can't imaging another way to do it. It has to scale to many crates while the space is already quite packed.

@Be-ing
Copy link
Contributor

Be-ing commented May 3, 2018

Okay, so a column in the track table wouldn't work very well. But still this feels odd because it is redundant with the tree in the Crates feature...

@daschuer
Copy link
Member

daschuer commented May 3, 2018

For me, this would be megeable if we make it a part of an general ID card widget.
It should be somehow responsive to make the best, of the available space. It should be possible to add additional metadata that also do not fit to a library column.
We can even consider to put the coverart into this new widget. For a first version only crates is OK for me.

This PR has an other issue, the tight coupling between, GUI and database access. I think I should be decoupled using the coverart feature as a template.

Maybe @uklotzde can give some hints that it matches also to his future library ideas.

@poelzi
Copy link
Contributor Author

poelzi commented May 3, 2018

@Be-ing in the library rewrite the old functionality is basically unusable. if you change the tab to crates, you can't access the tracks anymore. Apart from usability problems of the old design, the new one is totally broken in this aspect.

what I would like to show as well are the last n playlists the track is in. If you try to avoid playing the same track that often, it's hard to see when the track was in a set.

@Be-ing
Copy link
Contributor

Be-ing commented May 3, 2018

@Be-ing in the library rewrite the old functionality is basically unusable. if you change the tab to crates, you can't access the tracks anymore. Apart from usability problems of the old design, the new one is totally broken in this aspect.

Couldn't we make it so when a track is selected in the track table and the Crates feature is open on the other side, the crates that track is in get highlighted in the Crates feature's tree? Would that be desirable or would it be distracting or confusing?

It should be somehow responsive to make the best, of the available space. It should be possible to add additional metadata that also do not fit to a library column.

Interesting idea...

@Be-ing
Copy link
Contributor

Be-ing commented May 3, 2018

The strageness of this widget is highlighted when using the Crates feature. Also, it takes up quite a bit of vertical space, which there is not very much of:
screenshot from 2018-05-03 07-40-39

@Be-ing
Copy link
Contributor

Be-ing commented May 3, 2018

(To clarify, I do want to see this information displayed somewhere, but I am doubtful this widget is the best way to show it.)

@poelzi
Copy link
Contributor Author

poelzi commented May 3, 2018

@Be-ing the large vertical space is a known bug. I have problems that the splitter behaves correctly and putting the crates list into a widgetgroup causes the minimum sizes to be ignored. Any ideas ?

The strangeness is only if you have a few crates, if you have 40, you will not see all crates without scrolling

@Be-ing
Copy link
Contributor

Be-ing commented May 3, 2018

The strangeness is only if you have a few crates, if you have 40, you will not see all crates without scrolling

It would still be strange to see the crates listed twice right next to each other.

@daschuer
Copy link
Member

daschuer commented May 3, 2018

It would still be strange to see the crates listed twice right next to each other.

This dos not matter, if we treat the widget as kind of Track ID Card tough. In this case other infos like BPM, Location or what ever might be interesting.

I like the proposed place. If we can effort the space for the cover, we can also effort the space for the additional metadata. I just had a look into Clementine and it has the same layout, but with the metadata on top of the cover with a semitransparent background. Spotify has it right of the cover or below, depending on the cover size.

@gramanas
Copy link
Contributor

gramanas commented May 7, 2018

Shouldn't this be on top of NestedCrates?

@daschuer
Copy link
Member

daschuer commented May 9, 2018

Shouldn't this be on top of NestedCrates?

Yes, than it is obvious, that a tree widget will suite best.

@gramanas gramanas mentioned this pull request May 11, 2018
13 tasks
@poelzi
Copy link
Contributor Author

poelzi commented Oct 14, 2020

I new design is underway.

@poelzi poelzi mentioned this pull request Dec 6, 2020
@poelzi
Copy link
Contributor Author

poelzi commented Dec 13, 2020

continued as infobar

@poelzi poelzi closed this Dec 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants