The LogonSwitcher format supports a few elements about the logon. You can add a version, a copyright year, and an URL (both target and text to show). There is also optional support for a author logo.

Here you can see that I corrected the URL part. It was showing wrong on the last version. Turns out you have to have a textblock inside an url inside another textblock for binding to work. Otherwise, it doesn’t work right. Go figure !

I took the time to add custom selection and mouseover overlay on the logons. It’s very subtle, but I think it looks great

Not a lot of background work. Background replacement works, but not other UI elements yet. Crappy restriction on resource updating when linked with mui resources files.

 After playing with BitmapEffects a bit, it turns out it’s deadly slow when moving elements with effects applied. The panel I was using was animated on resizing and it slows down the app to a crawl every time it moves…

For WPF version 1, Microsoft hasn’t made BitmapEffects hardware accelerated, so every elements with effects applied goes back to software rendering. Not an option with animated controls, I tell you !

So the animated panel is gone, and I’m now using a simple UniformGrid. It looks so much better with a white glow for text and a dark glow for the background.

You can see that I added UI elements to the logon preview. It doesn’t look exactly like the real thing because some of the bitmaps are actually stretched and I’m not supporting that right now. The search box is now correctly aligned on the right.

On the backend size, I updated the class responsible for extracting default logon UI elements. I’m now duping almost every UI elements shown on the screen (plus a few misc. things such as the startup sound).

After almost a week of work, it’s starting to look a bit better. I didn’t work a lot on the UI so it’s still kind of messy. It’s still using an animated control as the panel to host logons, but I’m probably going to get rid of it for performance reasons (more on that in next post).

I worked on the backend for most of the week. I now have a nice plugin interface that allow FileSupport dlls to be added to support new file formats. I have rudimentary support for logonvista files, as well as it’s own file format.

Although the LogonSwitcher file format support much more than logonvista at the moment (backgrounds as well as others UI elements), it actually took a lot less time to build thank to XML serialization

I tried to make things as flexible as possible, so that I can add new UI elements without having to update every class. Hopefully it will work without too much special cases

Note: I know the logonvista is copyrighted by Stardock and they don’t allow other people to use it. I made the FileSupport dll for my one use and I don’t intend to ever distribute it.

Last week, I started working on a new application to lean WPF. Learning XAML proved to be slightly harder than I imagined. Mainly because there is no “right” way to do things. So I’ve been rewriting it almost every day, every time a little bit better than before

Here is what it looked liked after a few hours:

A little bit of customization later:

There is still a lot of work to do. I’m just starting to work on the backend. Hopefully I’ll be able to reuse some of the things I did two years ago when working on my .Net SDK for ObjectDock.

ObjectDock Docklets are DLL programmed in C or C++ that exports a few callbacks functions. These functions are called when a user manipulate the docklet. Building a docklet in .Net directly is impossible as ObjectDock doesn’t support managed code docklets. Thus, you need some kind of “proxy” that knows about .Net docklets and will be able to interact with them, relaying info to ObjectDock as needed.

Here is a picture that summarize the interactions between the different parts (I know, I could have made an UML Class diagram, but hey, it’s Christmas and I wanted a nice looking picture )

The Interop Docklet is just a normal docklet that exports all of the possible callbacks functions. Whenever a callback function is called by ObjectDock, the Interop Docklet transmits it to the currently loaded .Net Docklet. The only problem is that you cannot call managed code from unmanaged code directly, you have to use COM to access managed dlls.

Each .Net Docklet should implement the interface IDockletInterface (basically identical to the native docklet callbacks). The Interop docklet knows the GUID of the interface and can create an instance of the .Net Docklet using CoCreateInstance. However, for the call to succeed, the .net docklets have to be registered as COM objects. Asking the user to manually register each plugin with regasm was obviously not an option.

As there is no way (AFAIK) to programmatically register managed COM objects from unmanaged code, the Interop Docklet contains hardcoded info about the DotNetHelper DLL. When the docklet is called for the first time, it write that info in the registry. Then, when a CoCreateInstance call fails, it calls the RegisterDocklets function in DotNetHelper DLL that will walks through the different .Net docklets and try to register them. Problem solved (well almost, but I’ll keep that for another article )

The NetDockletHelper DLL also provides the Docklet class that encapsulate SDK functions and keeps the static data associated with each docklet (such as the docklet handle and the different folder paths). Docklet programmer can also use the LOG function from the Util class for debugging purposes.

I’m looking for people to help me test .Net Support for ObjectDock.

What you will have to do is simply try to build a docklet using the sdk and send me suggestions & bug reports (or not, if you feel evil ). The more of the SDK you use, the better, of course, but building a simple docklet will work too.

Here is an explanation of the way I build it and how it works:

Last week, I started working on a way to build ObjectDock docklets in C#. Currently ObjectDock only allows you to build docklet using C/C++. As I have no access to ObjectDock internals, the only way to have docklets using managed code is to build a “proxy” docklet and call into managed code using COM.

The following picture shows the interaction between the different parts. When building a .Net Docklet, the only thing you have to care about is the docklet code itself (the Interop & helper dll are supplied and do not need to be modified).

The API is similar to the native SDK API. Each .Net Docklet has to implement the IDockletInterface interface (basically, the exportable functions from the native API). The native SDK functions are provided through the docklet class found in the DotNetSDK dll (the docklet handle & private data are encapsulated, so it’s somewhat cleaner than the native API).

The interop docklet can be used in two different way: in standalone mode or in multi-docklet mode. In standalone mode, the programmer distributes the interop & helper dlls along with it’s .Net docklet and set the interop to autoload it’s plugin. It’s completely transparent to the user. In multi-docklet mode, you only distribute the .net docklet part (users should have the “runtime”) and users could choose from a selection of docklets the one to load.

If you want to help me test it, drop me a mail.

Merry Christmas everybody

Introduction

f In some past articles, Brad described his idea of a Todo plugin for ObjectDock. Since nobody seems to have taken on the idea, I decided to try to do build it myself.

This article is the first of a series that will describe the process of building the plugin. It will come with the source code. It will be licensed under the Creative Commons Attribution-ShareAlike License.

As I don’t know how long I will be able to work on it, I decided to limit the scope of the docklet (no drag&drop to create new task, no predefined and custom task icons, etc.).

Functional Specification

The following spec is pretty crude and in no way complete (and as always subject to change). I will describe the behavior of the plugin as the user creates a task, modify it and finally delete it.

Creation
A new task is created when the user selects the ‘TodoList Docklet’ in the ‘Add Entry’ right-click menu. The plugin is initialized with the default icon, the task name set to “Click to Edit…”, the priority set to “0 – No Priority” and no description.

Modification
The user will then modify the task to fill the different fields. This is done either by left-clicking the icon or by right-clicking and selecting ‘Edit Task’. The “TodoList Docklet Properties” Dialog is presented to the user (mockup from Visio).

The “Name” field contains the name of the task. It is shown when the user moves the mouse over the task icon.

The “Priority” is the priority of the task selected on a scale from 1 to 5. Here are the different icons quickly made by me (by now, you can probably see I’m no artist).

The different priority are:

	0. No Priority 	1. Not Urgent 	2. Not Important 	3. Normal 	4. Important 	5. Urgent

The default priority is “0 – No Priority”.

(Got better names ? Comment! )

The “Description” is a more precise description of the task, and is optional.

The default icon (a slightly modified Knotes icon from the crystal icon pack by Everaldo) can be changed by clicking the “Change Image” button (opens the standard ObjectDock “Choose Image” dialog). You can revert to the default icon by pressing the “Default Image” button.

When the user is finished with the editing, he can either ‘save’ the changes by pressing “OK” or cancel the changes (“Cancel”).

The task icon in the dock now looks like this:

The priority is shown as an overlay on the task image.

Deletion
When the task is finished or no longer relevant, the user can delete it, either by dragging it off the dock or by right-clicking the icon and choosing ‘Delete Task’.

That’s it for today. In the next article, I will describe the framework for the plugin.