The Future of KDocker

Let me start of by saying that KDocker is not dead and I’m not abandoning it. The past few releases have had minimal changes. This is mainly because I believe KDocker is pretty must feature complete at this point. It docks apps and does a pretty good job doing so. The past few releases have been small (very small) maintenance releases.

For a while I was worried about the relevancy of an application like KDocker. Gnome 3 and Unity attempted to drastically change the desktop metaphor. When both projects were announced and initially released it looked like an application to dock other applications was no longer necessary. This doesn’t seem to be the case in Unity at least. KDE appears to be sicking to the classic desktop metaphor and it doesn’t look like any other desktop environments are following in Gnome 3 and Unity’s foot steps. So KDocker looks like it will be useful for years to come.

One of the biggest problems of developing an open source project is knowing who is using it and how it’s being used. Any small change can potentially have a drastic and unforeseen impact. This hasn’t stopped me from making changes in the past but I at least want to state my intentions to give people a chance to comment. There are two major (somewhat) changes I’ve been thinking about making for quite some time now.

Currently KDocker uses the QtSingleApplication solution to ensure only one instance of KDocker is running. The solution handles checking if KDocker is running and if it is the solution messages the running instance to preform whatever action the user requested. I’ve been thinking about replacing the solution with DBus. The drawback are KDocker would depend on DBus and possibily some type of security issue. KDocker can be used to launch other applications so I would need to look into this further. The advantages of DBus are: it would reduce complexity, it should fix a race condition that can cause two instance of KDocker to be running, and it would allow other applications to message KDocker. The big question is how many people are using KDocker that do not have DBus installed. Any KDE, Gnome, or Unity users will have DBus but the same cannot be said about some other environments.

The other big change is related to how window title matching happens. The current method is substring matching. I’ve been thinking about supporting regular expressions (regex) as part of the name matching. Qt has a regex engine as part of the API. It is not a Perl compatible regular expression engine (PCRE) but it would be good enough in this case. The disadvantage is increased complexity in name matching. The user would need to worry about using a regex instead of a simple substring. This could be mitigated by doing substring matching then regex matching if substring matching doesn’t find a match. However, this could cause false positives. The advantage is there should be less instances of users having trouble docking certain applications. Especially in cases where there is no common substring in the window title.

2 thoughts on “The Future of KDocker

    1. Indeed it will and I’m looking forward to it. Sadly Qt5 isn’t out yet so we’re stuck with what Qt4 comes with for the time being.

      Like

Comments are closed.