I must agree 100% with Frans: While giants are busy fighting on the Desktop Search front, WinFS gets delayed, which should have been the real front. People here at Xceed know what I think about WinFS. While others here were all excited about Avalon and Indigo, I was the first to tell them the real innovation and revolution was WinFS. I'm sorry MS, but WinFS should have been the main Pillar of Longhorn! Instead, WinFS topics on MSDN all start with this remark:

UPDATE: In spite of what may be stated in this content, WinFS is not a feature that will come with the Longhorn Operating System. However, WinFS will be available on the Windows platform at some future date, which is why this content continues to be provided for your information.

Sure, desktop search tools help make my life easier. But it's a temporary solution... And temporary solutions tend to become permanent too easily...

On my TODO list: Post about the WinFS model and its implications on archives like zip files, which are not ready to store data, relationships, and metadata.

I admit, I'm working in zip file compression, and I'm not even using something home made for unzipping zip files I run into. I'm using WinZip's context menu.

Well, I should talk to the past. I've made a man of myself and implemented my own "Unzip Here" context menu, which is using Xceed Zip ActiveX 5.x. Why reinvent the wheel when it works fine? Because it didn't work that fine for me.

How many times have I right-clicked on a zip file, went to the WinZip menu, stared at Extract to here and Extract to d:\someplace\somewhere\zipfilename just to find asking myself: "Does that zip file already contain paths?". If it does, I don't need to create a "zipfilename" subfolder, thus I should select the first menu item. But if it doesn't, I sure don't want all unzipped files to end up in the current folder, thus I want to select the second menu item. I end up opening the zip file just to view file paths.

That's what I just implemented. You right-click on a zip file, you click on Unzip Here, and it will automatically detect if it needs to create a subfolder (using the zip filename) or not, then unzip everything.

I won't go into the full details of how to create a Windows Shell Extension component, the sample is pretty self-explanatory, and the web is filled with tutorials. In short, you:

• Create a new ATL COM AppWizard project (VC++ 6).
• Add a new Simple Object with default names and attributes (make sure not to select "Free Threaded").
• Remove references to the newly created interface, you don't need it. (I left the IDL in there instead of copying the CLSID somewhere else... I'm lazy).
• Remove the type library from the resources and RGS file, you don't need it.
• Implement IShellExtInit and IContextMenu interfaces (see UnzipHereExtension.cpp).
• Add the required registry keys (see "DllRegisterServer" in UnzipHere.cpp).

The heart of the extension resides in IContextMenu::InvokeCommand. Don't forget more than one file can be selected when your context menu gets called.

While debugging, you'll often need to restart the explorer.exe in order to release usage of your DLL. Use the Task Manager's run menu to reload it. If you don't like ending a task via the Task Manager, try this: Start Menu -> Shutdown, press Ctrl-Alt-Shift and click Cancel. The explorer.exe process will end.

On my TODO list:

• Support zip files not ending with the ZIP extension (like self-extracting zip files).
• Implement a "Zip This" menu.
• Add a "File already exists. Do you want to overwrite?" prompt.
• Hide the "aborted" error on non-zip files.

Comments welcomed! Have fun!

When applications like KeyHole will become defacto cartographic applications, someone, somewhere will have the bright idea of putting huge ads on their building' roof.

How about ads on highways? They will have a T form, displaying their contents in front and above!

I can't wait to see the first guy to ask his girlfriend in marriage via KeyHole, spelling "Martha, will you marry me?" on some park's ground...

I've been playing with KeyHole for a few days, and though such tools or web sites have been out there for years, I must admit KeyHole is simply amasing. Its smooth transitions, road map display abilities, sharp and precise images and placeholder sharing possibilities are incredible.

For example, once you have KeyHole installed, I can give you a link to my home, like this one:

Home.kml (.72 KB)

As you can see, both my neighbours have a pool (grin). And then, you could travel up to Xceed's headquarters by clicking on this:

Xceed.kml (.75 KB)

A very neet residential area, surrounded by two golf courses and a huge park, right in the middle of Longueuil. I often compare Longueuil to a mini-Redmond. And finally, how about a higher view of the greater Montreal's south shore:

HighView.kml (2.26 KB)

The next step is building KML files for your clients or invitees that smoothly shows them step by step instructions on how to get from the airport or their house, to your business headquarters or your open house party!

For those playing with the newly released Avalon CTP and Chris Anderson's XamlPad application, and are using other Visual Styles than Windows XP (TGTSoft's StyleXP or patched UXTheme.dll), you can follow these instructions:

• Go in folder "C:\WINDOWS\Resources\Themes\Luna"
• Copy file "PresentationFramework.Luna.NormalColor.FxStyles"
• Go back one folder, then into your current theme's folder
• Paste the copied file
• Rename the file as follows:
• Replace "Luna" with the name of the "msstyles" file
• Replace "NormalColor" with the name of the folder under "Shell" which matches the active color scheme.

For example, I'm running with the CodeOpus theme with the Dusk color scheme:

Within "C:\WINDOWS\Resources\Themes", I copied "Luna\PresentationFramework.Luna.NormalColor.FxStyles" to "CodeOpus\PresentationFramework.CodeOpus.Dusk22.FxStyles". Notice that the color scheme part matches the subfolder name, not the color scheme name ("CodeOpus\Shell\Dusk22" in my case).

BTW, XamlPad's ClickOnce does not work within FireFox. Simply launch it from IE.

So the WinAmp adventure is over? Pfffe! That won't stop me from using WinAmp for listening to di.fm while working! Though I feel WMP10 and the WMA format does a better job at ripping my CDs (quality/size ratio), I've always had a better experience with WinAmp for listening to streamed audio.

Lluis Sanchez Gual, of the Mono project, created a class library for generating IL in a higher level form than System.Reflexion.Emit. It's kinda CodeDom for IL!

As you may expect it, I installed Konfabulator today. Though the installation process it smooth, the look is great, and the working experience is very interesting, I must admit seeing this in my Task Manager is somewhat of a turn down:

One process per widget, and an extra one for the tray icon and menu... is it worst it? Though CPU usage seems reasonable (compared with Desktop Sidebar for example), and the sum of memory usage averages what Outlook is using by itself, I'm left with the impression that this Windows version was made out of a hack, and no real "Windows integration" effort was made. On a developer's machine, I'm doomed to miss that memory one day.

Seeing that UnixUtils folder under Konfabulator also gives me similar impressions:

Oh well, I'll give it a real try... but I'm afraid it will end up just like Desktop Sidebar... uninstalled!