Docky Update – Bug fixes and future plansJanuary 29, 2009
Docky is getting almost all of my programming attention these days. I figure now is a good time to give a general update about what is going on and what my plans for the future of Docky are. I figure the easiest way to break up this post is to internal changes and user facing changes. This way we can keep the interest of those who wish to write plugins and allow those who just want to see the shinies to skip ahead.
Docky is going through a little bit of a rewrite internally. I am trying to clean up some of the architecture of Docky that evolved in a less than desirable manner. First though, a tiny bit of background on the design of Docky.
Docky started off as a project for a GUI programming class I was taking here at Western Michigan University (I am but a student after all) and kinda fell into what it is now. As such, some of its initial design decisions were good, some of them were really bad. I did get an A however. The good things include Docky’s decision to do all of its drawing in a single Gtk.DrawingArea (big performance win here) and do all of its rendering based off of timestamps instead of relying on GLib Timeouts to give good accuracy. This means that Docky animates in a constant time across all systems, and the only performance indicator is the number of FPS the user sees. This is different from every other dock I have used (I am not sure about Cairo Dock here) and turned out to be a good decision. Really I was just guessing.
However, in the original design there was very little separation between the Summon mode of Docky and the Dock mode that they were essentially inseparable. One could hardly exist without the other and the rendering code for all of that was custom done to accommodate this. Essentially, Docky was impossible to extend and add new modes to without custom casing in each new mode. This is not what I desire. Additionally, much of the classes had become muddled together, each containing references to their parent class and passing that on to sub classes and so on. This became a big problem for debugging and made it very difficult to make serious changes to Docky without breaking things.
The New Hotness:
So I fixed things, or am fixing things. In my polish/breakage branch things are in a much different state than they are in trunk. The primary drawing area has no concept of what Summon mode is, this is all handled through a service that allows arbitrary plugins to register as painters for the Dock. There are services to provide functionality within Docky, a service to interact with Do, a service to do Text rendering (very important even though it sounds simple, but this helps keep things consistent), and a service for interacting with and adding items to the main Dock interface. This way applets, when the API is finalized, will be able to do all these things without having to have crazy implementations or initializers or anything like that.
In general, the status of this looks a lot like:
- Drawing Service – 50% implemented
- Items Service – 80% implemented
- Painter Service – 99% implemented
- DoInterop Service – ??
A common request for Docky is applets. It is coming! Let me give an example of how code looks for them right now. The simplest applet imaginable (just an icon and text) is done like this.
public class MyApplet : BaseDockItem
const string MyIcon = “some-icon”;
SetText (“It’s an applet!”);
protected override Pixbuf GetSurfacePixbuf ()
return IconProvider.PixbufFromIconName (MyIcon, DockPreferences.FullIconSize);
Easy huh? There are of course methods you can override to provide additional functionality. You can override methods for click events, drop events, (soon) scroll events, as well there are easy ways to request your icon be re-rendered should you desire that. You can also implement things like a dock overlay renderer (no example code here) that will let you do things like a “Summon Mode” to display whatever information you need to display in a nice format. This could be especially nice for plugins to handle things like intercepting system messages, or doing a system tray (fun), or god knows what. I thought a nice sample that does a weather applet will be my example for this when the time comes.
Applets will be installed in the same way all Do plugins are, by simply dragging the DLL right onto the preferences window. This will make it nice and easy to install and remove applets from Docky. Implementing custom right click menus is also just a couple lines of code. It’s just an additional interface you implement on top of BaseDockItem to add a right click menu. Takes 2 minutes tops.
Docky User Facing Changes:
Some new things are going in to Docky after the 0.8 release that users may find interesting.
- The drag and drop system has been revamped to give better feedback.
- The fisheye algorithm has been worked and changed to use double’s instead of int’s so it is smoother now and less “jittery”. In fact I dare say there is no jitter at all anymore.
- Rendering speeds are improved so that netbooks should have a better experience. I doubt I can get it liquid on them, but I am aiming for it anyhow. Maybe once I switch to glitz?
- Positing continues to improve.
- Better fonts that match your system theme instead of just being whatever pango picked
- Docky blows up and dies horribly when I do xyz with my windows
- Extreme CPU consumption when not doing anything (rare)
- Autohide more consistent
- Resize can leave icons looking “funny”
- Dragging icons can result in crashing
- A series of index out of range errors
- Removed useless Copy To Clipboard action from right click menus
- Sorting is awkward
Oh yeah, there is one more change. A results list! People have been requesting this pretty much since the start of Docky, and it’s going to happen at long last. I will post screenshots sometime when I get less lazy.