hdButton: place: 'controls' is not the default, 'both' is (undocumented change of behaviour)

[GoogleCodeExporter]

What steps will reproduce the problem?
1.http://flowplayer.org/plugins/streaming/brselect.html#button-examples
2. http://flowplayer.org/demos/plugins/streaming/hdtoggle.html
displays button in controls and dock

What is the expected output? What do you see instead?
Expected: hdButton only in controls
Instead: hdButton in both controls and dock

Not a doc mistake - unless we decide to _intentionally_ change the default 
behaviour. That's why there's separate demo for docking the hdButton which 
clearly assmumes 'controls' as the default place.

1. decision on whether to
   a. change behaviour intentionally
   b. revert to old behaviour
2. in case of:
   a. change (or even remove demo): @blacktrash
   b. @devel

Original issue reported on code.google.com by blacktrashproduct on 25 May 2012 at 7:38

[GoogleCodeExporter]

What was the previous behaviour exactly, it went through many changes before 
the release, its been like this for a while. 

place: 'both'

to place in controls and dock, 

place: 'dock' to place in the dock only

place: 'controls' to place in controls only

Original comment by dani...@electroteque.org on 25 May 2012 at 8:55

[GoogleCodeExporter]

I see that the default behaviour has changed, and I know how to configure it.

What I am talking about is that our site reflects exactly what effect this has 
for customers: not only is 'controls' still documented as default, but the 
_structure_ of the bitrateselect demo section still reflect this, i.e. an 
_extra_ demo to show how to put the button in the doc. Adapting this means 
quite a lot of work in the explanatory texts and possibly a removal of a demo. 
Now imagine that you _paid_ for the software, and suddenly discover that the 
behaviour changed.

Not even I know whether this change of default behaviour is intended or just 
"happened".

The professional way of introducing such a change is a) to ask yourself whether 
it's needed b) document it in the release notes c) check how our own docs must 
be changed

I will now work on the docs. This would be much easier if a) I was informed of 
such changes b) the reason for such changes (assuming there was a reason) - the 
latter makes it less time and effort consuming to document.

Original comment by blacktrashproduct on 26 May 2012 at 8:28

[GoogleCodeExporter]

https://github.com/flowplayer/site/issues/493

Original comment by blacktrashproduct on 26 May 2012 at 8:33

[GoogleCodeExporter]

It went through a massive refactor seperating from the bwcheck plugin,  this is 
a brand new plugin so of course its different. Im still unsure what exactly is 
different please specify. 

Original comment by dani...@electroteque.org on 26 May 2012 at 7:51

[GoogleCodeExporter]

It went through a massive refactor seperating from the bwcheck plugin,  this is 
a brand new plugin so of course its different. Im still unsure what exactly is 
different please specify. 

Original comment by dani...@electroteque.org on 26 May 2012 at 7:51

[GoogleCodeExporter]

just had a look at the docs it states the default is set to both, don't know 
exactly what the issue here is exactly. because the bitrateselect plugin is new 
, its own plugin, documentation seems correct i dont see a problem here. 

Original comment by dani...@electroteque.org on 26 May 2012 at 8:35

[GoogleCodeExporter]

just noticed the default was documented as  controls, dont know how that 
happened. , so confirming docs are updated and ok to close this  

Original comment by dani...@electroteque.org on 26 May 2012 at 9:04

[GoogleCodeExporter]

The default setting for hdButton.place changed from 'controls' to 'place'. This 
means not only changing it in properties table (which I have now done), but 
also a change of concept for
http://flowplayer.org/demos/plugins/streaming/hdtoggle.html
http://flowplayer.org/demos/plugins/streaming/dock.html

The main reason for the latter is in its title: "Docking the HD selection 
button". In principle the demo is now basically obsolete because of the changed 
default.

We are not communicating change of behaviour, we do not say why we changed it, 
we document it months later. I sort of stumble over it, and can understand 
users who are either annoyed or turn away silently.

Anyway, closing this as I'm working on the doc and demo changes and fixes.

Original comment by blacktrashproduct on 26 May 2012 at 11:07

• Changed state: WontFix

[GoogleCodeExporter]

And, yes, I made the changes to the tables _today_.

Original comment by blacktrashproduct on 26 May 2012 at 11:20