I had the " W.T.F " skin on XMPlay yesterday at a reunion in my house with my co-workers all night. They loved it!  

Noice! ~humbled~

That did the trick.
Thanks!

Welcome.

The skin is pretty... nice work!!!

Thank you.

*edit ... sorted ... attachment removed .. .. combination is/was...

NoPause panels -> single non-orange pause symbol(button) -> (not flashing)

@Jimmy

*original panels -> multi-2 ((orange)pause symbol & normal play arrow) -> not flashing .. that sound right?

I don't stream personally, but from your description, it does seem to be displaying the various button states correctly.
If I were to guess, *it seems like the buffer delay/timeout is causing a hiccup in the instructions to the button display.
Would have to ask Ian about that.

*With that thot, if you don't want to see the dual play/pause ever, the NoPause panels and the single (orange)pause symbol should do the trick.

Oh, and that last update for the large version, the (jagged shading) from the edges of the output panel got removed and the volume knob background got matched to it's placement. You may still notice a bit of a darker line following the orange when hovering and adjusting it because of the way it lights up when hovered.

*edit

..thud..

.. first post was updated slightly earlier with an update of the large version, along with the addition of a medium version, and now again with an update of the medium version already, and an update of the original version. Here's to hoping nothing's borked.

Two people storming Castle Luck with a torch, but forgetting their pitchforks .

Didn't forget my pitchfork, as was pointed out by the people who took offense to my expressions of frustration and disappointment.

Well, now that one can make a flashing multi-state pause button, I'd like to see one in action. Will you adapt W.T.F. with this button?

That would defeat all of my own points. If it were default for both button types you could just turn on or off NoFlashPause ..
(the suggestion again)

.. there's also no adaptation needed, there's already several 'button_pause.bmp' variations included in the zips ..

.. and apparently it's also supposed to be easy enuff for the user to do ..

Regarding the user being forced to use the skin as the author intended, if the user wants to change the skin settings, they can do so either by modifying the source skinconfig file or overriding it with a "blahblah.xmpskin.skinconfig" file.

... I have no problems with it if you the user would like to add that setting to your skin config file.

.. as much as I tried to be clear, decent and reasonable and what.. ? .. I'm not allowed to state my disappointment and reason for it?

I've seen a suggestion I'd made implemented. I've made other suggestions that haven't been addressed, of which I'm not particularly worried about. I've thanked Ian for his excellent work ...
The 'flashing' thing seemed like it 'should' have be blatantly obvious .. but apparently not .. and apparently I don't express myself well enuff for others tastes .. so I shall stop participating and continue to use the excellent program that is XMPlay, by the skilled programmer Ian Luck, in silence.

.. what's done is done, return to first sentence.

For when flashing is wanted with a multi-state pause bitmap, here's an update that adds a "pos_flashpause" skinconfig option for that...

.. ANOTHER option in an even less user friendly place for something that would have only required making flashing default for both button types and letting NoFlashPause do it's job ... thanks for nothing ... sorry ... thanks for the new useless setting I can now have in my INI and extra searching I have to do to figure out how to turn off the flashing the skin author forced on me.

@Jimmy .. you must have one heck of a high contrast monitor ...

I'm guessing you're using the large version ... (.. I would imagine the magnification tool doesn't do a 'super' quality re-sample as it zooms things either but .. )

The black part that follows the orange part on the volume indicator is part of the knob. I tried to make sure I'd matched all the button and knob backgrounds to their placements, but apparently I still missed some.
(I had suggested somewhere about buttons and knobs being able to make use of the transparent color, would make a lot of things quite a bit easier, but it seems to have gotten lost)

The (jagged shading) to the left of the +10 -10 should follow the entire inner edge of the 'tab' and also along the top and bottom parts of the frame. I didn't think it looked that off whack .. perhaps I should just remove it.

Will (try to) keep these in mind as I (slowly) work on this medium version here and, (if you've the patience for a week or so), will update them all when it's ready for first release as well. (details details details ... )

I certainly wouldn't mind a medium version.

I would also be interested in having a medium-size version...

In that case .. hopefully there'll be a working version within the week.

Thanks Jimmy ... I think.

You did see the part where I said I agreed with you?

That is what that was in response to.
The second sentence was to acknowledge that I read your post.
The third sentence was just clarification for anyone reading it after all my other posts.

Well, the mental block hasn't lifted completely, but I'm considering doing a medium size version, if there's any interest ..

Thanks Jimmy ... I think.

The original suggestion includes an option to try to avoid multiple skin versions. (user and author friendly)

To sum up, and end, my side of this flashing crap ... if you don't see it, don't bother, I'm done.

By the way, if I didn't understand this...

Before the multi-state pause bitmap option was introduced, a flashing button was used to indicate that playback was paused rather then stopped, ie. it was functional rather than aesthetic. Some people didn't like the flashing, so the "NoFlashPause" option was later added to disable it. Now, when a skin includes a multi-state pause bitmap, the bitmap's "paused" state is used to indicate when playback is paused, so the flashing isn't needed. .... There is no obligation for a skin to include a multi-state pause bitmap; if you or any other skin author would prefer to have the flashing button behaviour with a single state pause bitmap, that's perfectly fine ..

... I wouldn't have posted this, or this, or this, or the post above this.

.. Regarding the user being forced to use the skin as the author intended, if the user wants to change the skin settings, they can do so either by modifying the source skinconfig file or overriding it with a "blahblah.xmpskin.skinconfig" file.

The over-ride part is new to me .. still, it's not particularly user/author friendly and all it does is screw the authors original design more. It also contradicts this..

Not only is flashing not needed in that case, it could also be a hindrance, like in the "stopped"/"playing"/"paused" texts example that I gave.

.. because the user can then 'hinder' the authors intention,  .. and leads back to the first part of this.

And if you just plain don't want to do it just say so.

*edited to fix link references

So in other words... you don't understand what I'm talking about at all, .. none of this made any sense to you and you have no idea how or why this suggestion makes any sense.

SO I'll contradict myself ...

As XMPlay's author/developer, you integrate options to appeal to a wider audience, and attempt to make them as user friendly as possible, do you not? ... otherwise you may as well just tell people off.

NoFlashPause=0 .. single state button, flashing; Play, Pause, Play, Pause ... OR stopped
NoFlashPause=1 .. single state button, not flashing; play OR paused OR stopped

NoFlashPause=0 .. multi-state button, flashing; Play, Pause, Play, Pause ... OR stopped
NoFlashPause=1 .. multi-state button, not flashing; play OR paused OR stopped

... whether the buttons are text or not makes no difference. For example XMP.A.D.D
The only difference is an extra display state. For example, one of the multi-state options for 'W.T.F'

As a skin author for XMPlay, I'm asking you to restore a default, that wouldn't do anything different than what it originally did, (flash between states), which also keeps NoFlashPause as a useful feature .. and .. suggested a feature that adds a user option AND a skin author option that together would be user-friendly, AND would allow me as a skin author to appeal to a wider audience, and be 'more thrilled' about an already great program, and it's author ...

.. I never thot a concept like that would need to be explained to a developer of your calibre .. how sad.

For example, someone may want to have the button display "stopped"/"playing"/"paused" text in their skin, and flashing would prevent that from working properly. So if flashing is to be applied to a multi-state pause button, I think it would need be based on a skinconfig setting rather than the "NoFlashPause" option.

.. for example .. 'W.T.F' was originally designed with the 'FLASHING' in mind; NoFlashPause subverts that by giving the USER an OPTION... regardless of how the buttons were designed. (screw the author)

Putting that option in the skin config FORCES the USER to use the skin the way the author originally designed .. CONTRADICTING the IDEA of NoFlashPause ...and... USER OPTIONS. (screw the user)

Seriously .... ?

Please read this post again and tell me where I'm wrong.
Please read the suggestion, the whole thing, again, carefully, and tell me how it's not clear enuff.
And please read this again.

Stemming from this post ...
Perhaps multi-state buttons should be allowed to 'flash' between their alternate Play and Paused states also, with NoFlashPause using the Paused state of the button.

It was suggested specifically that way because it would be the proper way to do it. ... Is it possible? Might you be willing to do it that way? .. if not, or the reasoning needs to be spelled out .. forget it.

.. trying to keep simplicity in mind ..
Might it be possible to add a second, say, .. 'button_pause_multi.bmp' to the config? .. The thot being that ... there would then be the possibility of several extra combinations that NoFlashPause would also help allow for ... an option could be put on the Appearance page to 'Use Multi-state Play/Pause button' (if availabe) .. that could just be ignored if the corresponding button doesn't exist in the skin.

Again, specifically suggested that way for a reason using the same reasoning behind the first suggestion. Is it possible? Might you be willing to consider it? .. if not, or the first suggestion isn't an option, also, forget it.

@Chinese Sausage: Glad to know it works somewhere.

I've been trending towards darker background packages, and this skin fits right in.  Besides, it makes me look just a little radical and younger than my driver's license says, ya know?

I must be really young then

You don't have a driver's license?

No, I don't. But that's not really much of an age indicator either

I'm pretty pleased with the end result and understand the limitations we're up against.

I'm also pleased with the way this skin has been developed.

Thank you and thank you.

I've been trending towards darker background packages, and this skin fits right in.  Besides, it makes me look just a little radical and younger than my driver's license says, ya know?

I must be really young then

I noticed the track again does not flash very noticeable. I am using Ubuntu, could that be the cause? 

No idea. Using the most recent version of the skin, the track flashes plenty noticeably over here (windows xp).
Anyone else?

On a slightly different note, there's going to be some extra delay before any more work is done on this skin, (if there's any more to do). Somewhat of a mental block has settled in and motivation has died for the moment.

I got dizzy trying to switch and swap.

Yeah, sorry, that was the most efficient way I could think of to include the various combos that people had mentioned and that I thot could be useful.

I noticed that the no_pause package didn't work in the way that I expected. Where it settled is only one symbol on the control, and never lit.

It's a bit tricky. The contemplation post slightly above does cover most of the general details, tho it may require reading a couple of times

The info bubbles would show the border color better if they were wider.

I agree.
*Taking the current 'Info bubbles' ..'text size' drop-down option into consideration, a separate drop-down option box for the Tray Title bubble would make sense, with a separate skin config for color, font-weight and border width (?)

Is there any capability to skin the tray icon mouse-over?  It presently gives just an unadorned small text box.

I think that's a windows default tool-tip.

Could the info and on/off images slide to the bottom of that window, and stretch the artist-title all the way across from border to border?

The 'I' and the program close button on the main panel? ... I tried that a while before first release. It breaks the balance of the skin way too badly.
Cut offs are pretty much expected in the title, as everyones tagging and title preference is slightly different.
Also, having as much space as possible (on one line) for the extra info seems to make more sense, as it's more consistent between files, (it's generated by XMPlay), and looks (much) worse when cut off.


*edited for a little more clarity of thot