Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Synchronicity between Selection viewers, Buttons and hotkeys (Read 2189 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Synchronicity between Selection viewers, Buttons and hotkeys

(Remark: Some of the following i already mentioned in a few thread. So if you feel that i am repeating myself, so please apologize. However, i never mentioned the following in the context of the interplay of different parts of the program, so yes: it contains some new things.  )

Before i come to the benefit of synchronizity let me explain what i mean:
  • 1. You already can create different types hotkeys: main menu, context menu, context menu (playlist), context menu (now playing)
  • 2. On the other side the "customize button" window lets you only use main menu and context menu. The first step to synchronizity would be to also be able to use context menu (playlist) and context menu (now playing)
  • 3. Using all that 4 types for selection viewers would be over the top and wouldn't offer real benefit: selection and playing track is enough. In this case synchronicity would mean to be able to set "playing track" or "selection" as source rather in context menu of each selection viewer uielement seperately than as central setting in preferences.

The benefit of this changes would be that we can create more senseful layouts. To illustrate what i mean wit "senseful" here some examples:
  • Mixing selection viewers with different sources in one layout
    I prefer as source the "selection". However, i setted foo_textdiplay to show always info about playing track. Now i would like to be able to show artwork of playing track in same container of foo_textdisplay.
  • Consistency of containers source and toolbar
    Take the little example from above: foo_textdisplay and album art viewer in one container. Now we could add a toolbar to this container wich contain commands that are applied on playing track. Means: Both viewers and the toolbar are from same type (now playing). Or another example: we could add a toolbar to the bottom of the playlist view - the buttons from type "context menu (playlist)" are applied just on selection of playlist.
  • Different layouts with different sources for selection viewers
    In my main layout i prefer selection as source for selection viewers, but i have an layout for mini mode: Just playlist view in a tab container and would like to place some selection viewers in other tabs that only show info about playing track.

I know that these things are not essential an i would/will find a way to live without it without starting to whine. But i think the benefit is worth to make this "little" changes as they also do not add complexity or confusion.

(Edit: Sorry, i made a mistake in the topic title - can someone cut the text that follows after "hotkeys")

Synchronicity between Selection viewers, Buttons and hotkeys

Reply #1 –
Moderation: Moved here from [a href='index.php?act=findpost&pid=668899']How to use the new internal cover art patterns[/a].[/size]

@ The Link:
Thank you! I didn't see that change...

@ q-stankovic:
Do you really consider to change that global option into an option working for each element separately? Global options are fine but look at the global option for "Library viewer Selection Playlist": "Facets" has its own option and ignores the global setting. I also like the idea of having a small album art element that changes while browsing through the library viewer while another (bigger) album art element shows the playing song.
 

Synchronicity between Selection viewers, Buttons and hotkeys

Reply #2 –
@start78

I am not against global options per se - i even think that in most cases they absolutely make sense. Facets doesn't support the library viewer playlist because facets wasn't updated since lv-playlist was introduced.
However, i tried to find some reasons why in this case of selection viewers  it is better to have seperate options. Here i placed my request of seperate options in a higher context.

(As the last posts of this thread doesn't really belong to the topic anymore, it may make sense to split it and to merge with my thread here)