Query about playlist bitmamp
 

I'm in the process of updating the windowshade button for my jtfe plugin (and a few more windows but that's for later ;) ). Anyway, i've noticed when testing different skins that a number don't appear to align the playlist winshade button when i copy the image source onto the gen window frame (as i'm doing).

From what i can see, i've got the right co-ordinates for the base classic skin, it's the user-selected ones where the problem appears arise (with some aligning fine whilst others have the colour of the invalid parts of the image file showing).

So the question is, what's the definitive co-ordinates for the playlist editor minimise button (in all states) for a non-base classic skin so i can at least say if people moan why it's showing a pink band to the left, etc on certain skins (as i'm sure some people will comment on when the code goes live).

tia
-daz

well, there is a bug in that bitmap. From the skinner atlas readme "The 'back to normal' button has the same bug the winshade button has: it's one pixel to the right." Is that causing your problem?

yup that looks like what i thought it was.

in the code i'm using to copy the image i correct the final placement of the image to be one to the left to counteract that (i assume that's the right thing to work around this). if that's so then i'll leave things as is since for skins like fusion amp and gearamp it all aligns correctly with that adjustment. (skinning is such a pain at times it seems :/ )

-daz

You know, I had an idea for a plugin, but I'm not a good enough coder (yet, I'm still learning ;) ) to make it. Here is roughly what I had in mind. Would there be some way to fix that bug along with a few other various skin bugs in winamp by having a plugin put the sections of the skin bitmaps where they are supposed to go? Bitmaps like titlebar.bmp would be a pain because everything below the shared line bug would have to be accounted for. But, you could have some 4*4 pixel symbol in the fixed bitmaps that the plugin checks for to see wheter to make the adjustments. That way, it wouldn't break old skins. I dunno just some thoughts I had the other night while I couldn't sleep and was frustrated by this same bug.

Do you really need the windowshade button from the playlist? :confused: It's a shame they didn't just put an optional winshade button in the gen.bmp... I tried the explorer playlist, and for almost every one of my skins, that winshade button looks wrong simply because I don't design the gen window and the playlist window to be particularly identical. Oh well, can't be helped, I suppose...

k_rock923: yeah, i think something like that could be done. the main thing is to know what the exact bugs are, how they need to be adjusted, which files are affected and a lot of fun fun hacking to ensure that the affected windows are re-drawn over correctly for each of the different states.

if i can get time to work on the skin-previewer plugin again (which i want to do :) ) then i could look into doing it then since i need to re-create the other windows as well for later builds of it so if i can re-produce the bugs in the skin format and then add in an alternative handler that uses the 'real' values ;)

LuigiHann: when i was making the code initially for jtfe and basing things off the classic base skin, using those parts of the playlist editor were the best compromise i could make. i am debating on whether to add in support for an extra bmp file for the modified parts of the frame (left/right edges and the buttons) or to add them as unofficial mods to the gen bmp with some sort of maker like k_rock923 possibly suggested for a skin work around plugin to determine if that bitmap has those values or not

seeing as i'm not a skinner, some sort of feedback on the ideas may be useful for the windowshade code (since i've got the code at a state whereby it'll add a winshade button to any created gen window frame - at last the ml can windowshade :) ) and just need to really finalise the handling of things

-daz

Hmm, I didn't realize you had written the jump to file skin plugin thingy. Actually, I have a question: why is there even a winshade button? As near as I can tell, it doesn't do anything in winshade mode with any usefulness (I mean, I can still jump to a song after typing the name, but I can't even see what I've typed). And there's no winshade mode when you're using a modern skin, so it can't be that important.

aye, that plugin is mine. why implement it? because sometimes i like to keep the windows open but not close it (for quicker access really). also i basically did it bacause i could since i'd seen some people ask for a winshade on the ml window and it was an initial test version to see if it could even be done (which i've now done globally in 0.3.1.1a of the explorer playlist plugin).

as for no winshade in modern skins, i find that really annoying since as i said, i tend to winshade windows were possible (i even do it on normal Windows windows where possible with a program i wrote ages ago).

i guess it's just a quirky thing i like ;)

-daz

i've had a play around with the gen.bmp as it stands and came up with something like the potential mod to the file for placement of the image parts based on the parts i currently override at the moment from gen.bmp and pledit.bmp and the description below shows what/where they are.

code:
gen window frame left		(active)		158x0 -> 11x20

gen window frame right		(active)		170x0 -> 11x20



gen window frame left		(inactive)	158x21 -> 11x20

gen window frame right		(inactive)	170x21 -> 11x20



normal window with winshade button pressed		182x0 -> 9x9

winshade window with winshade button pressed		182x10 -> 9x9



winshade button in winshade	(active)			182x20 -> 9x9

winshade button in winshade	(inactive)		182x30 -> 9x9



winshade button normal window	(active)		182x40 -> 9x9

winshade button normal window	(inactive)	182x50 -> 9x9

before i even try to implement handling for this (since as flatmatt asks, why even do it when modern doesn't and nothing else is added though people also seem to want it with the DL plugin as well so the demand appears to be there) some ideas on this mock up would be good. or is it just better to make a new bitmap and have done with it. or i just ignore the whole idea and just keep using the skins i know which work for me :)

-daz

As far as making an entire new bitmap, that might be simpler, or harder. Simpler in that you don't have to worry about screwing around with the existisng bitmaps and you can do with it as you want. But harder in that you'd have to get the bitmap into the .wsz. What happens if you program those modifications and there is an old gen.bmp in the .wsz

if there wasn't the support in the gen.bmp/however/if it's done, then it would fall back to the existing code that's there since i'd include a marker in say the modified bitmap or it would know that there was the additional file present. doing those checks are pretty easy to do. the hard bit is ensuring the image changes i make keep skinners happy :)

-daz