The Media Center Sandbox

Hi There,
    I'm just feeling my way around media centre and have started to look at MCMLookalike. I couldn't seem to get it to install 'out the box', but I did have a look at the Controls.mcml, which helped heaps. There is however something funny going on, I find in McmlPad and Media Centre, when you use the mouse, and move it over the srcolling list at the top, then back to the lower list, and repeat this (without clicking), both menus slowly fade away to oblivion? It looks more like a repetitive application of a fade more than an alpha blend decrease, but I'm a bit lost as to why it does that.

Has anyone else had this problem?

TIA,

Matt

Just a glitch in MCMLookalike. I'm going to fix this shortly :)

Try http://www.thedigitallifestyle.com/cs/blogs/developer/default.aspx for my worked example of building an MCML application, running from the MCMLookalike base (but not using many of the components - it shows you how to build your own).

---

100 downloads a day for Yougle Vista - goin' allright!

Check out http://www.thedigitallifestyle.com/cs/Blogs/developer/default.aspx and http://www.push-a-button.com.au/products/mce

Steven, I'm probably feeling a little dense tonight but I've been scratching my head about the uses for MCMLookalike.  Under what circumstances would I use MCMLookalike, and not just work with the Media Center SDK itself?

Is it intended for use on non-Media Center systems?  Does it add classes/objects that aren't available in the Media Center MCML development environment?  Are you trying to replicate MCML functionality to be able to show that it can be done?

I'm not trying to be snide (though some might say that just comes naturally), but I haven't been able to find a manifesto for MCMLookalike.  What's the deal?

It's was supposed to be a set of MCML controls to make a system that looks like the normal Media Center screens.

Eg. the grid-layout you find in 'Pictures', the selection box with the flare and shadow effects, the 'pivot' selections (the bar at the top of the screen you use to change sort orders or view settings) etc.

But without anyone else contributing, I stopped playing with it. I may get back to it one day, but I made it 'Open Source' because I assumed people would help. Nobody ever did.

 

---

100 downloads a day for Yougle Vista - goin' allright!

Check out http://www.thedigitallifestyle.com/cs/Blogs/developer/default.aspx and http://www.push-a-button.com.au/products/mce

No, seems people are very, very protective about their work doesn't it :)

I've thought about contributing some of my controls actually, but I'm still 'on the fence'.

In a way I agree with Microsoft's stance on the issue of addins not looking like the rest of Media Center, whilst on the other hand I totally understand that is exactly what the users want. However, having a 'complete' control library available [to any Tom, *** and Harry] may not be the best thing - if writing plugins for VMC suddenly became as easy as dropping a control here, another one there and writing five lines of C#... Well, perhaps we're better off with a 'close-knit' community where anyone who actually does write add-ins know how stuff works rather than just drop'n'build.

---

If "Drop And Build" applications worked well enough...why not allow them?

---

100 downloads a day for Yougle Vista - goin' allright!

Check out http://www.thedigitallifestyle.com/cs/Blogs/developer/default.aspx and http://www.push-a-button.com.au/products/mce

Well, that's why I'm still on the fence :)

On the one hand you would allow existing programmers access to the current look and feel of Media Center.

On the other hand it would allow 'wannabe' programmers the same - which is what I have an issue with. Making MCML programming (almost) as easy as creating a webpage ... well, having a completely crap/spyware/insert-anything-bad-here application look and feel like the rest of VMC could/would harm the branding.

So I dunno. I'm more than happy to contribute samples of controls to anyone who asks, but to give them the complete lowdown including graphics... I'll need some convincing this is a good thing :)

---

Steven, I'm personally sorry that the community hasn't taken up the mantle and helped move this effort forward.  I believe it's a good one - especially since, having spent the weekend giving myself a crash-course on what the Vista Media Center development challenge is, and having finally figured out just how few built-in controls there are (for both you *and* Microsoft to have voiced the opinion that it'd be awesome to have a library of reusable MCML controls), I'm now sorry that there aren't more controls out there.

Maybe there'll be an opportunity to build some additional reusable controls as an outgrowth of the project I'm convincing myself to embark on...?  I'd certainly be interested in your opinion of what (if any) opportunity for building some additional reusable controls would be practical/natural to expect from this project.

"emigrating", I'm disappointed at your attitude towards non-professional developers (or at least, to the kinds of output they generate).  Being a non-professional, non-formally-trained developer myself, I always bristle at what appears to me as arrogance, condescension and a sense of elitism (like creating new and different types of software should only be done by some narrow class of self-appointed leaders, and the rest of the world should never aspire to look behind the curtain, let alone sully the "good name" of programmers by putting out something that doesn't quite live up to their self-righteously-appointed standards).

And what's this nonsense about "harming the branding"?  This sounds like it's coming directly from the mouths of the Microsofties with whom I worked for six years (until moving out of Seattle this past spring).  If you are a current/former 'softie, I think we'd all appreciate a little clarity from you on that - as would Microsoft, whose internal ethical standards I believe were pretty clear on that point.

If not, then can you please explain where your bias on this topic comes from?  I can't understand why you'd really care if a handful of folks came out with some less-than-perfect code that others decided to adopt on their Media Center PCs.  It shouldn't in any way affect the stability, quality or experience you're having with your own Media Center PC, and it doesn't sound like you'd be likely to fall victim to any pranksters/hackers/criminals who tried to masquerade "evil" software as "good" Media Center software.

Hell, I'll assert that the "crap/spyware/anything-bad-here" security implication is a red herring - I can't seriously believe that the risk of malware, written in MCML (which can only run properly on Media Center PCs - whose market share is still vanishingly small) would ever pose a measurable threat to the stability of our prized HTPCs.  There are so many other, easier ways to build malware, that will have a much larger vulnerable population, and that will have a much higher degree of impact than any malicious MCML application out there might have.

And don't you have it backwards, saying that by making the tools easier to use, that we're supporting the degradation of the ecosystem?  In my experience, the opposite is true - keep the technology hard/obtuse/cryptic to implement, and those few brave/foolish souls who embark on development in that area will be much more likely to make bad decisions - poor code quality, low reusability, poor security, deviations from best practices/usability/consistent-look-and-feel...

Frankly I'm suspicious of what you're saying (as you can probably tell), but that doesn't in any way mean I'm not open to an open exchange of ideas.  I'm happy to find out I've missed some important aspect of the discussion...

Cheers, Mike

Here's the article I spent most of the weekend writing (as I did my research - I'm slow but not that slow).  Feedback (offline, online, mailbomb) appreciated.
http://paranoidmike.blogspot.com/2007/11/picasa-web-albums-data-api-vista-media.html

Mike

You have some excellent points Mike, and if you look through some of my older posts on the topic you'll find that I [more or less] agree with most of them.

You'll notice I said 'wannabe' programmers. My definition of a wannabe may be different from yours, so to clarify - my definition is the same as found here.

I don't have an issue with non-professional developers/hobbyists at all, I was simply pointing out that I "In a way I agree with Microsoft's stance on the issue" - meaning I can definitely see where they are coming from not providing complete samples with the look and feel of VMC.

That does not neccesarily mean I agree with it, but business wise I can see it being the smart decision (hence my comment about the MS/VMC branding). Also, because I deliver (as one of my many irons in the fire) complete HTPC systems myself (running VMC) any negative PR Media Center gets (due to aforementioned 'crap' add-ins) could have a detrimental effect on my bottom line - and like always, it's all about the money :)

"And don't you have it backwards" - Well, I'm not talking about the tools to develop these applications, they are available for anyone to use - Heck, Microsoft is giving [some of] these away for free (Express editions). I was talking about Microsoft not giving away the 'brand' (ie. look, feel and behaviour) of Media Center.

Comparing this with web development in its infancy (yes, I was around then :p) - I really do believe that the people who took the time to understand what it is they were doing are the same people who ended up with great looking sites. Those that simply copied and pasted code from tutorials (or even worse, other peoples code) ended up with the complete opposite.

So, whilst I am happy to give away sample code (like I did here for a Spinner control), I'm still not convinced allowing everyone access to a 'master-template' is the way to go.

I should also point out that starting out with MCML a few months ago I wanted exactly that - a re-usable control library where I could create a (standard looking VMC) button simply by throwing a <controls:Button.../> into a file. Now, a few months down the road, my point of view has definitely changed.

Spending time writing my own controls (which look and feel exactly like the standard VMC buttons, down to the animations and sounds), whilst painstakingly slow (and had it not been for this forum, I may very well have given up), actually learned me a lot of very valuable lessons.

Finally, having spent the time to create my own personal control-library, I now have everything I initially asked for and I can now build a completely new application simply by throwing a bunch of controls into my .mcml file, write a bit of C# and hit compile. But now, if my button does not work as expected I can easily change it - if a pre-fab button didn't work as expected for a MCML newbie (someone who tried running before they could walk), they would have no idea what to change or even where to look.

---

Yes, you too make some great points - I'm glad I didn't put you off entirely.

The web development infancy was one of those times where I thought "this can't be that hard", and yet because the tools and the pre-built libraries of "controls" (or whatever you'd like to call that early Wild West mess that was psuedo-standards HTML) were so piss-poor, I aborted any hope of getting any more proficient than < hr > < br > < h1 > etc.  There went a promising career, and thus I fell into systems admin...

While I'd love for everyone to "understand" what it is they're doing, that's very similar to the instinct I see in most of my info security colleagues to "expect everyone to appreciate why they need to make something more secure".  You'll see promising results with the early adopters, and hellishly diminishing returns for the bow wave of followers, and no amount of effort with the non-inclined will change their bias for "let me just get the job done" expediency over elegance/security/whatever.

Am I a bit cynical?  You bet.  I spent my entire tenure at Microsoft continuing to strive for the highest-quality output, and looking back on it, there's a ton of stuff I wish I'd gotten into the hands of colleagues/customers/strangers, instead of trying to perfect it [and never seeing the light of day once I left].  Now, I'm very much more about "display it as I'm doing it", "get something done and build on it next time" and honouring the majority's need for something that works, not something that's "right".

NOTE: I'm not setting out to convince you to join this "dark side", but rather to help frame where I'm coming from (for greater understanding or at least context).

I can well appreciate trying to keep too much poison out of the well where your livelihood is concerned, and I'm frankly stymied at this juncture - I don't have any direct experience with developing in MCML, so I can only go on my best guesses and the reported experiences and conclusions from folks like you, IgnoranceIsBliss and others.  [Heck, my particular opinions on MCML are pretty fresh, since I only dug beneath the surface starting on Saturday.  Ask me again in a week, and I'll bet it'll change again.]

I'm willing to go along with your line of reasoning except for two points that keep sticking in my craw:

1. "I'm still not convinced allowing everyone access to a 'master-template' is the way to go."  Why are you even discussing this in terms of "allowing"?  Do you honestly believe you have some power to control the development of/access to reusable code (in this or any other space)?  You certainly have the choice (within applicable open source licensing requirements, I suppose) to hide the source code you've developed under a basket [though I'm glad you haven't completely gone that way].  I'd selfishly prefer you shared what you've already figured out, 'cause I really don't relish spending months having to recreate what you've already developed.  In any case, I suggest that the control you have over the code that's been developed by others is indirect [despite any desire you may have otherwise], and I'd have some trouble encouraging this sort of behaviour just to potentially protect an income stream from what I believe is a very low-probability, low-impact threat [i.e. from really crappy developers creating stuff that many people want to install and whose stability impact on the overall platform would be blamed on the platform and not the add-in].
   
2. "Spending time writing my own controls..., whilst painstakingly slow..., actually learned me a lot of very valuable lessons."  I'm not sure, but I'm wondering whether these lessons are MCML/VMC specific, or if they're actually valuable for general development prowess as well. A lot of what you (and a couple of others) seem to be saying about what they've had to fight so hard to learn, sounds like lessons on how to understand and interpret the intricacies (aka the poorly-documented, or worse, poorly-designed, aspects) of MCML/VMC development.  I'm all for "learning to code better", but if withholding the product of lessons learned really only benefits followers' ability to learn how to develop in MCML/VMC, then I'm vehemently against such "school of hard knocks" lessons.  I feel like there's little to be gained from learning some vendor-specific/proprietary development approach, especially if it was poorly designed and horribly documented, when that "apply forehead to brick wall" time could be much better spent learning something equally as obtuse but much more generally applicable such as XSLT/XPath. :) [Don't get me started on that ridiculous universe...]
   

As before, I hope I'm not insulting you or completely missing your intent.

Thanks again, Mike

ParanoidCanuck:

"I'm still not convinced allowing everyone access to a 'master-template' is the way to go."  Why are you even discussing this in terms of "allowing"?  Do you honestly believe you have some power to control the development of/access to reusable code (in this or any other space)?  You certainly have the choice (within applicable open source licensing requirements, I suppose) to hide the source code you've developed under a basket [though I'm glad you haven't completely gone that way].  I'd selfishly prefer you shared what you've already figured out, 'cause I really don't relish spending months having to recreate what you've already developed.  In any case, I suggest that the control you have over the code that's been developed by others is indirect [despite any desire you may have otherwise], and I'd have some trouble encouraging this sort of behaviour just to potentially protect an income stream from what I believe is a very low-probability, low-impact threat [i.e. from really crappy developers creating stuff that many people want to install and whose stability impact on the overall platform would be blamed on the platform and not the add-in].

Let me rephrase that: "I'm still not convinced giving everyone easy access to a 'master-template' is the way to go." :)

I don't have a problem sharing my findings or even specific code (I've started, and I'll most likely continue with a few more examples once I get v1.0 out the door). I just think it's better to do it as a fully-explained (I tried, although I explain things a lot better in person than in writing) and commented bit of text rather than providing a few controls and saying, "you can use this control like so, injecting properties for this that and the other - it will then automagically display a checkbox on screen".

The problem here is this; If you rely on a prefab library you won't know some of the internal workings of MCML, for example;

You want to display a bunch of buttons on-screen, clicking any one of them should bring up a dialogbox on said screen. To do this you'll have to share some sort of property between the Parent UI, the Button UI and your DialogBox UI. This makes complete sense to me [now], but looking at some of the questions we get on this forum it doesn't for a lot of people.

Creating a ... let's say Spinner ... you'll need to employ some of the very same principles to get it working. So in order to create a working spinner you need to know these things. Now, if the spinner was simply provided for you and all you had to do to use it was <controls:Spinner Choice="[App.MySpinChoice]" DisplayLabel="true" Size="251,51"/> you would possibly not have a clue about why your dialogbox didn't appear on screen when the spinner was clicked. So you end up sitting there "Well, I provided all the [mandatory] properties to the spinner... why the ¤#"! doesn't it work?".

Of course, that's just my personal opinion. So whilst I understand that [end-]users want a fully integrated experience (ie. look and feel like the rest of VMC) I can still understand (from a purely business point of view) Microsoft's reluctance to provide this in the SDK - they already provide some controls in the MCML Sampler and Z/Q applications. These provide the basics for a Button, Spinner, Checkbox, EditBox etc and will allow you to build your application. Then when you have a basic application up and running you can start to tweak the controls you already have to look like the rest of VMC, i.e. by adding graphics, animations, sounds and so on.

ParanoidCanuck:

...I'm not sure, but I'm wondering whether these lessons are MCML/VMC specific, or if they're actually valuable for general development prowess as well. A lot of what you (and a couple of others) seem to be saying about what they've had to fight so hard to learn, sounds like lessons on how to understand and interpret the intricacies (aka the poorly-documented, or worse, poorly-designed, aspects) of MCML/VMC development.  I'm all for "learning to code better", but if withholding the product of lessons learned really only benefits followers' ability to learn how to develop in MCML/VMC, then I'm vehemently against such "school of hard knocks" lessons.  I feel like there's little to be gained from learning some vendor-specific/proprietary development approach, especially if it was poorly designed and horribly documented...

Good point. I've personally found it to be MCML/VMC specific (obviously, some people have come here as complete newbies to programming in general and would have a different outlook though) and yes, the SDK could do with a major overhaul in places.

In a way I guess most of the people here are withholding their 'products', but that being said you'll find that anyone who can [help] does so. It's just, instead of saying "Here's a complete Button control" we are saying "You need to do this, this and this to build a usable button".

---

I've got to say that having the $(#*% trouble of building your own control libraries DOES have the effect of forcing you to really understand what is going on in the MCML system. Without all this time bashing my head against a brick wall, I'd have far less of a knowledge of the possibilities (and limitations) of the system. I'd also have fewer mental scars, but that's a different problem.

Emigrating is right - the lessons you learn the hard way by going through MCML from scratch ARE specific to MCML, because there's really no other system (apart from perhaps the WPF) that is anything like this. The lessons don't translate to C# or other languages (although you really MUST be at least reasonably famillar with C# before you start an addin).

 

 

On the other hand though, I do believe that you SHOULD be able to 'throw together' an application without having to go back to the basics. Why do you think the Microsoft Foundation Classes (and later, some of the higher level .NET classes) exist?

MS don't expect me to have to re-write my own HTTP methods based on the simple Socket class - they provide it to me. Otherwise, I'd be so daunted by having to write a correct HTTP class that handled all of the possible outcomes, I'd never start my application at all. The same would be true if I had to manually draw every button in my .NET applications.

And it's the same for Media Center Markup Language projects. Having to learn how to draw each and every visual element on the screen and learn the ins and outs of what is basically an entirely new model of user interface development is a very big ask for someone who wants to make an application that simply has two buttons and a checkbox to fulfill a simple task.

 

Of course, once you HAVE these controls made, you can reuse and recycle components from them. Developing an application does become a more 'throw together' experience (I can now write a new MCML page surprisingly fast - well, it at least surprises me). But the work taken to GET to that stage...wow.

---

100 downloads a day for Yougle Vista - goin' allright!

Check out http://www.thedigitallifestyle.com/cs/Blogs/developer/default.aspx and http://www.push-a-button.com.au/products/mce

Man, this gets more and more daunting by the day.  After 12 years as an "infrastructure-only" computer nerd, who'd tried (and failed) many times to force myself to learn how to write code, I *finally* found something (i.e. VS2005 + .NET 2.0) that gave me a reasonable balance between "learn before doing" and "never getting any gratificaiton before throwing up my hands in frustration and chucking it for another year".

After plugging away in my spare time (I'm still mostly an infrastructure goon by day) for over a year, I'm starting to feel comfortable enough with managed code development that I'm willing to branch out into related areas.  I've tackled a couple of VSTO projects (with fair-to-middling success), I've plugged away at XSLT 1.0 templates (but not without vowing never to touch such an ill-thought-out programming construct MANY times), and I'm now contemplating writing myself a life-enhancing add-on for VMC (so that I can possibly increase the likelihood of sharing the Photos that I'm currently accumulating - and rarely reviewing - on my VMC system).

I can appreciate the gratification that you've achieved in conquering something so f'n convoluted and intentionally-more-difficult-than-it-needs-to-be.  [I warn you that the first time I'm able to actually render a customized report using a from-scratch XSLT template, I'll be dancing naked through the streets!  Don't come anywhere near Portland during that time unless you're the type of person who looks closely at carnage & gore while passing a car wreck. ;)]

However, this smells of Stockholm syndrome to me - not the kind of thing most people would willingly subject themselves to, but the after-the-fact positive associations that are in part a subconscious defense mechanism to rationalize the inordinate agony they've been through.

If you had it to do all over again - and had the choice between two equally rich, flexible and powerful programming models, the only difference being one is standards-oriented (e.g. pure .NET + XAML, assuming XAML is truly bigger than just Microsoft) and the other is proprietary to that application (e.g. .NET + MCML, or even .NET + XBAP/XAML) - would you still choose to subject yourself to the proprietary solution?  [I guess that's a rhetorical, or at least a leading, question - don't bother.]

The idea that I have to teach myself a complicated, hard-to-understand, only-good-for-VMC-apps "framework", and that I'll only be able to leverage that learning if I happen to continue to develop further for the VMC [platform]/product, doesn't feel all that encouraging to me.  If I could tell myself that I'm learning something that's reusable across the Microsoft family of platforms (such as XAML at least hinted at), or that it really was just a temporary oversight that Microsoft was scrambling to resolve, then I'd feel much more enthusiastic.

However, after the past five days of research into this, I'm left with the feeling that I'm in for a miserable experience, that I'll be able to commiserate with a very small handful of helpful souls like yourselves, and that perhaps someday down the road, some poor soul will be able to leverage my hard-won but sadly small amount of reusable code.

Man, maybe I need a drink/some sleep/a stronger SSRI ;)   ... or maybe I need to go back to XSLT to remind myself of how much worse it can be...