A few things got mixed up in documenting some DVD Maker stuff, so I thought I'd like to the information out there and provide the information that hasn't quite made it out yet.
First of all, if you are looking at adding custom transitions, buttons, and menu styles to DVD Maker, there is an SDK for that. I didn't work on that section of DVD Maker, so I don't know exactly how it works, but I would not be surprised to find out that it takes a fair bit of effort to author a DVD maker style.
If you are wanting pass information into DVD maker on startup and/or use it for unattended burning, here's what you need to know...
Command Line Options:
This is how you pass a project file to DVD Maker. You can use the .msdvd extension if you want happy things to happen around the file (ie clicking on it in explorer launches DVD Maker), but DVD Maker doesn't care what the extension is.
You can use this to start up DVD Maker and have it look at a specific burner, but you should probably just set the drive in the project file instead. This is here so that AutoPlay can do the right thing.
dvdmaker -clickonce <filename>
If you have captured a tape on Vista, you probably ran what we call the capture wizard. In this wizard, you have the option of burning a dvd directly after capturing. Capture wizard does that launching DVD Maker with the clickonce flag (yes, it should probably really be named "clickeighttimesandthenputablankdvdinthedrive"). This is precisely equivalent to starting DVD Maker without this flag, pressing "Next" to get to the hub page, and then pressing "Burn".
Project File Format
It's fairly easy to understand the project file format by simply saving a project file and looking at it, but here's a bit more information:
Windows DVD Maker uses a simple XML-based project file format.
<Font Name="" Color="0xFF00FF00" Bold="1" Italic="0"/>
<Button Play="Play" Scenes="Scenes" Notes="Notes"/>
<SlideShow Transition="Cross fade" PanZoom="0" MatchMusic="0" Length="75.000000"/>
Denotes the content block. Only <ContentFile> elements are allowed inside.
A file to add to DVD Maker. A file in the content block is treated exactly the same way it would be if it were added through the “Add Items” dialog. Video files end up in the main list, still images are put in a slideshow folder, and audio is added to the slideshow.
The title of the disc
Drive letter of the DVD burner to use
Name of the style to use. If blank, uses the default.
Defines the name and color of the font, and whether it is bold or italic. For the color value, the first two characters must be “FF”, and the values for the red, green, and blue components are defined by two character hexadecimal values. For example, “0xFF00FF00” is bright green, and “0xFF0000FF” is blue.
Sets the names of the buttons used on the main DVD menu
The text that shows up on the notes page. The maximum number of characters supported is 256.
The setting of the “Foreground video” editbox on the Customize page
The setting of the “Background video” editbox on the Customize page
The setting of the “Menu audio” editbox on the Customize page
The name of the scene button style set on the Customize page
Settings for the slide show. Transition sets the name of the transition to use, length is the amount of time each slide will be on the screen, and PanZoom and MatchMusic are used to set the “use pan and zoom effects for pictures” and “Change slide show length to match music length” settings.
We've released an SDK that lets you extend the Vista versions of movie maker and DVD maker, though I should probably note that it's not a terribly simple thing to do.
Here's the blurb from the download page:
This SDK is helps you create and add your own custom special effects and transitions to Windows Movie Maker in Windows Vista, and your own custom transitions, buttons, and menu styles to Windows DVD Maker in Windows Vista.
I've been doing a bit of prototyping work with the aforementioned products, and thought that since Blend has an RC1 release, it was a good time to share a few thoughts...
The short story is that both VS and blend are pretty good tools for building in WPF, but together, they're very impressive.
Visual studio has its usual strengths - intellisense is great, refactoring support is great, all that stuff. And, once you get over the hurdles of how it works (which I'm presuming are less for a designer than a developer), it's very simple to get the UI exactly the way that I want it.
Which is a bit of work. WPF has a layout system that does a whole lot for you, but it does up the the object count a fair bit, especially since you compose controls to get what you want (Button doesn't support images and text - instead you do layout of other objects that are hosted within a button).
In the old world, I might have a window with 3 buttons in it. In the WPF world, I have a StackPanel that has 3 buttons in it, and then each button has as its content another StackPanel that has a rectangle (for the button part) and a text label).
Ordering and grouping those is nicely done in blend.
It's also very easy to do things like control styles, so that the look of controls can be controlled through a style rather than by modifying the properties on the control.
The only place where I think Blend falls short is when dealing with animations. The way in which they're entered and represented is a big hard to grok, though I think it's mostly just that it's hard to represent something that evolves over time. So I've been doing animations in code rather than in blend.
I also don't like having the event hookup done in blend. I'm invariably going to hook up to non-graphical events, and I like to be able to know what's going on in code rather than having to look two places.
I'm happy that I don't have to mention any problems with the two playing together. I have the same project open in VS and blend - they both monitor the project and pick up changes made by the other one.
Okay, not quite, but John W. Backus, the developer of FORTRAN has died.
He brought us do loops, assignment statements, the much-debated goto, intrinsic data types, and started the software developer's obsession with code formatting (1). FORTRAN is the root of the Computer language family tree, and he started it back in 1954.
He was also the inventor of the Backus-Naur notation.
1) For you younger pups out there, FORTRAN is a line-oriented language obsessed with column positioning. Columns 1-5 are used for numeric labels, column 6 is used to indicate continuation from the previous line, and columns 7-72 are used for statements. Columns higher than 72 are ignored.
Which led to many programmers - as they were called in those times - carrying around little rulers that you could put on top of a code printout - assuming you have a code printout and note a punched-card deck - to check that the columns were right.
Though I understand that they wimped out and relaxed these in later versions of the language.
I learned FORTRAN (my second, or perhaps third language) on a 300 baud modem connected to a DECWriter, back in the fall of 1979.
But you tell kids these days that, and they won't believe you.
Over the past month or so, I've been getting a number of requests for back columns that I wrote. If, for example, you do a web search on my dated and somewhat misleading and inaccurate column on app domains and dynamic loading, you will end up at an MSDN page that redirects you another MSDN page that doesn't exist.
I've been trying to get this fixed for a number of weeks but it's still broken. If they aren't fixed in the next couple weeks, I'm going to route around the problem and put them up on the blog. Please bear with me/us for the time being.
Actually, now that I think about it, it might be interesting to walk through them and update them. Hmm...
When you get to be my age, you sometimes wonder whether you can still do what you could do when you were younger. Do you still have your old moves, have you lost your edge, do you still have that elusive "IT"?
And frankly, with all the young pups I work with, some days I'm not sure...
But a couple of days ago, when I was getting ready for work, my wife came into the bathroom and picked up the Sonicare electric toothbrush right when I wanted to use it, but without a pause, I grabbed my emergency backup acoustic toothbrush, and found that yeah, I can still rock it "old school".
If you are doing storyboard-based animation, the animation is hooked up to a specific element through a unique id. You write code something like this:
element.Name = "Fred";window.RegisterName(element.Name, element);
The second call establishes the relationship between the name and the object.
If you're writing cod where there are multiple elements, you need to create unique names. So, something like:
element.Name = "Fred_" + m_id.ToString();m_id++;
works great. However, if you use:
element.Name = "Fred:" + m_id.ToString();m_id++;
You'll get a not-very-helpful exception...
Software is always built on other software - your dependencies - and the dependencies that you choose have a considerable influence on your success. Choose the existing technology that you know, and you have good predictability, but you might not produce a great product, or it might take too long to finish. Choose a hot new technology, and it's harder to predict what will happen. Maybe the benefits will be great and you'll finish faster (ASP.NET vs old ASP...). Maybe things won't be as good as promised (insert the name of a technology that you were "disappointed with" in the past).
Or maybe it's not finished when you need it. Welcome to the wonderful world of co-development, where you are depending on features that aren't implemented yet. How do you reduce the risk of features/APIs not showing up, or being substantially different than you expected?
Well, the first (and best) way to reduce this risk is simply not to do it. If you only depend on features and APIs that are currently available, you know they are there.
If you can't wait a full release cycling, then perhaps you can take some sort of incremental approach, where you plan to use feature <X> but don't *commit* to using it until its actually there. My preference would be an agile approach (such as Scrum), so that when feature <X> shows up, it's actually finished and working.
That's really just the same thing I said first - don't take on the dependency until something is done.
But what do you do if you really need that feature - if your plans would be derailed unless the other team finishes the feature? I have four things in mind that can help:
Accept the Risk
First, you have to accept that you are taking on risk. Software scheduling beyond a period of a month or two is not only an unsolved problem, I believe it isn't a tractable problem. Decades of project slippage have demonstrated that, and we should just embrace the uncertainty involved rather than trying to "do better".
Note that while there are teams out there that can give good estimates for tasks in the next month (and perhaps up to two months), you can't assume that you are dealing with such a team. There are many teams who are essentially unpredictable even in short timeframes.
Understand the Risk
Second, you need to understand the risk. This will require you to work with the team that's building whatever you are needing. You need to understand where your feature ranks in the things that they are doing. It might be a feature that they absolutely have to have to ship, or it might be a "nice to have" feature. You need to understand this. It's closely related to how close your requested feature is to their main charter. You do not want to be the outlier group amongst all their clients, the customer they don't want to have.
You also need to understand when they're building the feature. If it's very early in the cycle, then it's likely to get done. If it's late in the cycle, it's less likely to get done.
If they don't think of features in this way and/or are working on features in parallel, it's more risky.
It would also help to understand what development methodology they use, and their history of being done when they guess they will be done.
Plan for Mitigation
What are you going to do if things don't work out, if the feature is late or is cut? Even in the best organizations, people get married, are out for months on medical leave, have accidents, or leave to form their own companies.
What is your group going to do when this happens?
Track the Risk
In an ideal world, the group you depend on would give you regular updates about the feature you're waiting for. And some groups do do this, but it's your risk, and you're going to need to stay on top of it. The details of that depend on the groups involved.
Accept the Outcome
If things work, great. But if the feature doesn't show up, remember that you were the one who accepted the risk in the first place.
What do you do if you need to move a 200 ton, 9.8 m diameter spectrometer 400 km between two german towns, but the roads are too small?
Well, you send it 9000 km through the mediterranean sea, and then through Romania, Hungary, and Vienna.
All part of an experiment to measure the mass of the electron neutrino.
There's a nice page with pictures of the transport, and a video (download it first as it's slow to fetch) that shows the journey through German towns.
Oh, and I want a set of those motorized dollies they use for transport. I have no use for them, and I'm sure they cost millions, but I still want them.
from Improbable Research
I was trying to keep my intentions hidden, but Dan has disclosed them.
I've been trying to look like Willem Defoe...
Another dev center launches...
Beginning Developer Learning Center