Archive for January, 2009

h1

GNOME Do 0.8 released! Rock Out With Your Dock Out

January 29, 2009

The Developers of GNOME Do are proud to release:

GNOME Do 0.8.0: Rock Out With Your Dock Out

See what others have to say! y en español!

Digg It!

Since my big contribution this time has been in the UI area I figured why not do a full walkthrough of the new Docky.  56k people beware, the images are full desktop shots to provide a real perspective on how Docky will look on your system.

What is Docky?

Docky does docks right

Docky does docks right

Docky is a dock of sorts.  It has a fisheye zoom similar to what is Cairo Dock, launchers, window tracking, standard features of almost any dock worth its salt.  However Docky is more, and we will get into that later.  What is important about Docky is not so much what it does but how it does it.  Docky was inspired partly out of the need for a class project (college student) and partly because I felt every dock on Linux did one thing or another wrong.

Dock Fundamentals, Doing It Right:

From the start I felt Docky had a chance to do a lot right where things had been done wrong with Docks in the past.  So I decided to focus on a couple key points.

  • Make a dock so simple a 5 year old can use it.
  • Drag and drop for everything.  Add/remove launchers, rearrange, trash bin, drop files into folders, everything.
  • No configuration UI.  If there is a need for a separate UI to configure Docky, it is probably not needed as an option.
  • Dead simple resizing, just grab the handle and drag.
  • Flawless automatic hiding.
  • Extreme simplicity and easy of use. Be intuitive.
  • Launchers are applications, not windows.
  • Stay out of the way. A polite, one time request, is all that is needed.
  • Do something new!

Most of these goals are acheived, and for a first release I am pretty happy with it.  Docky sports every basic feature I have been missing in my docks and then some.  There are obviously still interactions that need to be worked out, otherwise there would be no point of working on Docky.  However, I feel at the core of it, Docky is ready for prime time, and I am proud to ship it!  Consider this a 1.0 release of Docky.

What Makes Docky Different?

Well it is but a dock after all, if not the newest player on an already too large field of Docks on linux.  However from the start, it was clear that with my background in GNOME Do, and my desire to make it part of Do, that Docky could be a lot more than just a dock.  There are probably hundreds of Docks for every OS out there by now, some of them more animated than others, but they all work in a pretty similar way.

  1. Take icon from menu | nautilus | konqueror and drag onto dock.
  2. Click icon on dock at later time, has the same effect as clicking it in whatever source you dragged it from.
  3. Icon now acts as “base” for windows of that application.
  4. Return to step 1.
Bye Bye Rythmbox

Bye Bye Rythmbox

There are things like applets, and sometimes really shiny things like stacks, but the idea does not really change at all.  There is nothing new being done with the concept, just logical extensions to it.  So when as a team we looked at this set of actions it became clear that steps 1 and 4 leave a lot of room for improvement.  Why do I have to drag things onto the Dock?  I mean I launch everything from there, it knows of all the applications I use, it should be able to put two and two together and figure out what to put on the Dock.  Additionally, doing this repetatively is kind of annoying to set it up.

If Do can, so can Docky

If Do can, so can Docky

So there was a tiny ah-ha moment, and it became clear that GNOME Do already knows what applications you use most.  Not only does it know what applications you use most, but it knows what music you listen to, what people you talk to, what bookmarks you use the most.  Why not let GNOME Do add some of these to the Dock?  Obviously we wont remove the ability to manually add and remove things from the dock (you can even manually remove these automatically found items from the dock in the same way), we just augement that with the ability to have a Dock that is more adaptive to who you are.

Making Docky a First Class Interface for GNOME Do.

Docky is GNOME Do, really!

Docky is GNOME Do, really!

Docky needed to be part of Do to make it work, so we had to make it summonable.  Summoning and working with Do is no different than any other interface for GNOME Do (oh and there are a lot now). Further, when in “Summon Mode” as it is called, Docky can add any item to the dock provided the dock supports hosting it.  That means, for the most part, no actions as they make little sense on the dock.  In fact there are many ways to add items to Docky.

  • Simply use the item enough in Do, Docky will add it automatically (unless you have removed it in the past, so you dont get items constantly reappearing)
  • Drag and drop from the GNOME Menus
  • Drag and drop from Nautilus
  • Drag the left and right edges of the dock outward to add more items from Do’s statistical guesses.
  • Clicking the “+” button when in summon mode.

Any of these will result in Docky adding an item to the dock that functions as expected.  By being a first class citizen of GNOME Do, we can do things that no other dock can, and we can do a lot of things other docks do better.

The Future

There is always a lot of fuss about these things.  Some people insist we do not need another dock for Linux, but I think what they mean is that we do not need another half finished dock.  With that in mind, Docky will continue to progress and improve, bugs will be found and quashed, and the experience and simplicity will improve.  We will be done when there is nothing left in Docky to take away, when every feature has been scrutinized and reviewed intensively.

Coming Features:

  • Orientation
  • Full dock plugins
  • Applets

Known Bugs:

  • Docky does not use system font in tooltips. (fixed in bzr)
  • Docky has some odd interactions with summon mode when zoomed really small.
  • Docky can get in the way of drag and drop when not autohidden.
  • Icon zoom has a bit of a jitter on some systems (fixed in bzr)
h1

Docky Update – Bug fixes and future plans

January 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 Internals:

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 – ??

Applets:

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”;
public TrashDockItem()
{
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.

New Features:

  • 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

Bug Fixes:

  • 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.

h1

Docky : Work In Progress

January 20, 2009

So i have not blogged about Docky at all. Partly because I didn’t want to, partly because I couldn’t. I guess this blogging thing isn’t exactly what I like to do. As it happens, I do have something to share though, however I don’t have much to say about it. So in short, here it is.

Docky sits at the top of the screen too

Docky sits at the top of the screen too

Everything is pretty self explanitory. Docky can sit at the top of the screen too. It will be able to sit at the sides if anyone can present me a mockup of summon mode on the left or right side. Everything I come up with is too ugly to ship.