Additional Tagging & Reporting Tools

[boroda]

new version available. i've done all i could to improve skinning support. i consider this version to be beta because i have tested it with a few skins only (functionality has not changed at all except for the new function $Lg(number)):

https://www.mediafire.com/file/h2t08o9562efboi/mb_TagTools_latest.zip/file

[hiccup]

new version available. i've done all i could to improve skinning support. i consider this version to be beta because i have tested it with a few skins only

Thanks for all your troubles with this.
It's a shame that this is something that is so difficult to do.
Couldn't Steven help out with some tips, or maybe improvements?

It's a little bit better, but still not great.


1. is now black and almost unreadable (was light and readable before)

2. is probably using some low contrast 'disabled' element? Also very difficult to read.
    But that has also always been an issue with most dark skins in MusicBee.
    When creating bitmap skins there is an element available that can boost the contrast so that things look good.
    But something like that is probably not available for these kind of plugin skinning?

3. and the active buttons: still good

(functionality has not changed at all except for the new function $Lg(number)):

Great, thank you!

[boroda]

thanks for the comments. The plugin now generates all colors itself (of course, they are derived from skin colors anyway).

1. i'll compare old and new code to see what has changed. maybe it's just a mistake.

2. it's disabled text. Earlier, this color was dim and dark, now it's light dim and light (it's for dark skins). how do you think disabled text must look? some mockup?

3. this hasn't been changed at all. because "and the active buttons: still good" (but this is not a button, it's label).

[hiccup]

2. it's disabled text. Earlier, this color was dim and dark, now it's light dim and light (it's for dark skins). how do you think disabled text must look? some mockup?

See the difference between the two 'disabled' lines in the skin, and the 'disabled' elements in the plugin:





But as I said, it could be because the skin is using the 'contrastboost' element to improve on the contrast of these elements.

Just as a general comment on the concept of 'disabled':
I think there are (should be) two versions of it.
1. for elements/functions that are currently disabled, but you may want to enable. So you will need to be able to read that text.
2. for elements that are currently not functioning, but also provide no useful information. Such as 'back' and 'forward' arrows in navigation panels.
    These arrows (such functions) may be completely invisible when they can not be pressed.

But this is more of a general observation.
While I think there are a few locations in MusicBee where this distinction could have been useful, I think you can ignore the consideration for your plugin, since probably every disabled text or button will provide some useful information.

[boroda]

for 1: it's just enabled text (both in the plugin and in MB, and in any app i'm aware of). of course, checked and unchecked check boxes/radio buttons look different anyway, but this doesn't concern text labels for them.

for 2: dim texts in the screenshot in your previous post are the labels for inaccessible controls, which can't be used at the moment. i've just checked how label for disabled controls look in mb: yes, it's somewhat lighter (for dark skins) than in plugin. i've tried to fix it:

https://www.mediafire.com/file/h2t08o9562efboi/mb_TagTools_latest.zip/file

[hiccup]

That's looking a lot better.
The 'disabled' text is still somewhat darker in the plugin than in MusicBee, but it's not that much.

Another factor that I think makes the text more difficult to read in the plugin is the fact that the letters are rendered closer together:



So besides the lower brightness, that additionally make the text less sharp and more difficult to read.
But I can imagine it would be some nightmare to make adjustments to that in your carefully designed panels.

[boroda]

mb API doesn't provide colors for disabled controls (also, don't confuse disabled (without quotes) controls with, e.g. unchecked check boxes. "disabled" is standard term), so i can only try to generate these colors from colors of enabled controls and background color  

as for the font, the plugin uses the .net default font. i don't know what font is used by mb. i can change font used by plugin, but it must be some font included in most (better in all) Windows versions. Alternatively, I can use the same bold font. or slightly larger font.

[hiccup]

as for the font, the plugin uses the .net default font. i don't know what font is used by mb. i can change font used by plugin, but it must be some font included in most (better in all) Windows versions. Alternatively, I can use the same bold font. or slightly larger font.

I am pretty certain MusicBee and the plugin are both using Segoe UI
The difference is that MusicBee uses some wider spacing (tracking) between the letters than the plugin.
Testing in Photoshop, MusicBee uses -40 for the tracking value, the plugin -80.

[boroda]

numerous bugs have been fixed, which STA PVS-Studio has found. UI is improved. all plugin windows are now using the Segoe UI 10 pt font (the default font for Windows 10 and 11) instead of Microsoft Sans Serif 8 pt (used earlier). i think MB is using Segoe UI 10 pt too.

https://www.mediafire.com/file/h2t08o9562efboi/mb_TagTools_latest.zip/file

[hiccup]

all plugin windows are now using the Segoe UI 10 pt font (the default font for Windows 10 and 11) instead of Microsoft Sans Serif 8 pt (used earlier). i think MB is using Segoe UI 10 pt too.

MusicBee's default font is Segoe UI 9pt, not 10pt.



If that turns out narrower in your plugin, it will be the result of narrower tracking between the individual characters.

[Mayibongwe]

all plugin windows are now using the Segoe UI 10 pt font (the default font for Windows 10 and 11)

I'm sure you've thought about it before...
but I was wondering if it wouldn't be best to just derive the MB font that the user has specified in hiccup's screenshot above? (Setting_GetDefaultFont)

[Dizza17]

numerous bugs have been fixed, which STA PVS-Studio has found. UI is improved. all plugin windows are now using the Segoe UI 10 pt font (the default font for Windows 10 and 11) instead of Microsoft Sans Serif 8 pt (used earlier). i think MB is using Segoe UI 10 pt too.

https://www.mediafire.com/file/h2t08o9562efboi/mb_TagTools_latest.zip/file

Hi Baroda,
I'm using the latest version of the plugin and have noticed a small bug with the preview & proceed buttons. on the initial click they are labelled as normal. but when it finishes either loading the preview or completing changing tags, both buttons continue to display stop even after the task has been completed.

 

[Bee-liever]

Hi Baroda,
I seem to have something weird going on with the new LR screen.
When I run the 'Preview' on a preset it shows dates in the column:


but if I run the preset from ASR I get the correct results:

[boroda]

I'm sure you've thought about it before...
but I was wondering if it wouldn't be best to just derive the MB font that the user has specified in hiccup's screenshot above? (Setting_GetDefaultFont)

winforms app windows are scaled very badly when the app window font and especially the screen dpi are changed. i'll better stick with a fixed font.

[boroda]

Hi Baroda,
I'm using the latest version of the plugin and have noticed a small bug with the preview & proceed buttons. on the initial click they are labelled as normal. but when it finishes either loading the preview or completing changing tags, both buttons continue to display stop even after the task has been completed.

i can't reproduce this bug using my latest code, but there is another related bug now: using the current plugin version (not yet publicly available), this button is always labeled "proceed" and never "stop". i'll take a look at this issue.