Skin- and visual errors related to, and skinning requests for MusicBee v3

[hiccup]

By control box do you mean the border images?

I believe your images are at 72dpi, while they should be at 96dpi.

[psychoadept]

By control box do you mean the border images?

I believe your images are at 72dpi, while they should be at 96dpi.

That's probably it.  I'll fiddle with them later, thanks.

[psychoadept]

In the configuration screen for album and tracks (if it matters, I'm running at 125% scaling):

[hiccup]

From a skinning perspective, I always assumed 'filterpanel' was the same as the 'column browser panel', since the settings made there were reflected in the column browser.
Looking at some new elements I now understand there is actually also a panel named 'filter panel'.

I'm probably in a Homer Simpson state of mind, but where do I find this filter panel?

[hiccup]

for scrollbars i have added support for lowlighting inactive scrollbar sliders ie. the lowlight colours will show unless you click on the slider and drag it

With all due respect, testing this out, I don't see a big use for this in the current state.
The lowlight color determines the visibility of the scrollbar and where you can 'grab' it.
Only after you 'managed' that, the color changes to highlight. I honestly don't see a big advantage in that.

An idea coming up, is that this could be a lot more useful if the state would go from lowlight to highlight, as soon as your mouse enters the corresponding pane.
Then by default the scrollbars could be unobtrusive lowlight (or theoretically even invisible), and become clearly visible and grabbable at hover-over.

[Steven]

the scrollbars are done in the way iTunes does. Personally i cant stand the way windows flashes the scrollbars when you mouse over and much prefer the iTunes approach.
Even if you dont agree with that, the lowlight in combnation with the new scrollbar ScrollBarLowlightNarrowOnly setting is still useful if you only want to blend scrollbars more into the panel when configured using narrow scrollbars

[hiccup]

the scrollbars are done in the way iTunes does. Personally i cant stand the way windows flashes the scrollbars when you mouse over and much prefer the iTunes approach.

I believe I am familiar with neither of those.
When installing Windows, one of the very first things I always do is disabling almost all 'visual effects'.

I was honestly wondering what the possible benefit was of having the scrollbar lit up, after you had already grabbed it.
No discussion here. Different folks, different strokes.

[Steven]

when the scrollbar is dimmed and blended into the background then restoring it to a stronger colour while dragging is helpful for positioning

[Bee-liever]

unless you provide an override with the id="FilterPanel. elements,
the Thumbnail browser still uses the panel background colours for the scrollbar background
rather than
<element id="Panel.ScrollBarBackground.Default" bg="xxx,xxx,xxx" bg2="xxx,xxx,xxx"/>

[Steven]

unless you provide an override with the id="FilterPanel. elements,
the Thumbnail browser still uses the panel background colours for the scrollbar background
rather than
<element id="Panel.ScrollBarBackground.Default" bg="xxx,xxx,xxx" bg2="xxx,xxx,xxx"/>

while i agree the logic is flawed, can you give me a skin which behaves differently to that for v2.5 so i can check what is going on?

[Bee-liever]

while i agree the logic is flawed, can you give me a skin which behaves differently to that for v2.5 so i can check what is going on?

Have a look at AeroBee
in 2.5 the thumbnail browser [TB] can only be placed in the main panel, and uses the same scrollbar background as the rest of the panels scrollbars

in 3.0 the TB can be in the left sidebar or left main panel.
in both cases, the TB uses the bg colour from
<element id="Content[TrackDetail].ListAlternating.Default" bg="45,68,91" fg="255,255,255" />
as the scrollbar bg

[Steven]

yep, seems i still didnt have it quite right. It should be working consistently with v2.5 for the next update

[Steven]

A request for an element for these 'disabled' texts:

these are the standard text box colours
Controls.InputControl.Default
Controls.InputControl.Disabled

i would rather not create exceptions unless there is a very good reason

[Steven]

A request for an element for these arrows showing in the Album auto-tagger panel:

this is now supported for enabled arrows. However when disabled, its coloured gray by windows

Controls.Arrow.Default fg=XXXX

[hiccup]

A request for an element for these 'disabled' texts:

these are the standard text box colours
Controls.InputControl.Default
Controls.InputControl.Disabled

i would rather not create exceptions unless there is a very good reason

In that case there is something wrong there. I tried several skins, both under v2 and v3, and all display these fields in "109,109,109". The elements you mention don't seem to have control over this.