0x5066 / winamp3x Goto Github PK

width is widely different for the main window and any generically skinned window, as we dont have maximize support included for them, causing the maximize button to not exist, this makes the title bar text uncentered whereas it's (probably) correct for the windows that do have the "maximize" button

• Application Workspace (Where can we use this? Edit: Nowhere, probably)
• Window Background (The same color group from Windows 9x and onward)
• Window Text (Is the same as the "Window-text" group)
• Menu Bar
• Menu Text (In theory yes, it just needs the handling to be implemented)
• Active Title Bar (still includes a gradient for 2 colors)
• Inactive Title Bar (still includes a gradient for 2 colors)
• Active Title Bar Text
• Inactive Title Bar Text
• Active Border
• Inactive Border
• Window Frame
• Scroll Bars
• Button Face (can inherit values from "3D Objects", "Button Face" apparently means not just buttons)
• Button Shadow (that's just silly)
• Button Text
• Button Highlight (that's just silly)
• Disabled Text (wasabi/gen_ff will set the alpha of the disabled text to be opaque, instead of relying on a color)
• Highlight (needs to be renamed from "Selected Items" to "Highlight")
• Highlighted Text (needs to be renamed from "Selected Items-Text" to "Highlighted Text")

The current state of the present menus (Playlist Editor, relying on images to still being able to access the PL specific actions, Media Library, using wasabi provided menu functions to access Media Library specific options) are leftovers from the eventual release of Nullsoft Winamp 2000 SP4 v1.4 which need to be replaced with ones emulating Windows 3.x.

• Study how menus work under Windows 3.x.

• Windows 3.x menus consist of 4 components.

1. The menu bar itself, which is colored using the Screen Element named "Menu Bar".
2. The selected/pressed down bar surrounding the menu text, colored using the Screen Element named "Highlight".
3. The menu text, depicting which action will be performed, colored using the Screen Element named "Menu Text".
4. The highlighted menu text that switched its color state from "Menu Text" to "Highlighted Text".

• Create new graphics based on what has been discovered. (Find out how Winamp Modern implements its own menus)

• Figure out how to cleanly switch images out based on left clicking them.

• This most likely involves Maki scripting to keep track of both the onLeftButtonDown and onLeftButtonUp state. (Is it possible to keep onLeftButtonDown active while a Winamp/WACUP menu is active and then switch back when it's not in use?)

• Lots of testing.

Describe the bug
A clear and concise description of what the bug is.

skin causes a crash with a certain playlist

To Reproduce
Steps to reproduce the behavior:

1. have something preloaded in your playlist
2. open the offending playlist file
3. crash

Expected behavior
A clear and concise description of what you expected to happen.

should not crash

WACUP (please complete the following information):

• Client Version: preview and beta 1.0.18.6800
• Skin Version: commit 2beeadc

Additional context
Add any other context about the problem here.

normally, you'd see winamp reporting where the balance bar is in the songticker, this is broken since i threw the volume and balance bar into their own group

Should we actually go into the effort of figuring out how to enable the maximized state for skinned windows (excluding EQ and Main Window) or hunt down a win3.x program that has a disabled maximize button?

Describe the bug
EQ light indicator improperly reads and sets the value for ON/OFF and Auto, it's a bug in WCM itself

To Reproduce
Steps to reproduce the behavior:

1. make sure the EQ is either on or off in any WCM based skin
2. switch to another skin (modern or classic)
3. enable/disable EQ
4. switch back
5. the EQ light will be in its incorrect state

Expected behavior
the light indicator should be set according to what winamp says, not from a stored value

Screenshots

WACUP:

• Client Version: Preview/Beta 6840
• Skin Version: commit da50a8e