Of course the Stable Diodon PPA will remain for other versions of Ubuntu and to release stable packages which have not made it into the official repository yet. And for all lovers of cutting edge software, there is still the Daily PPA for the daily snapshots of Diodon.

Additionally with version 1.0.2 comes there a Apport integration so you can simply report bugs. Just use the following command to do so:

ubuntu-bug diodon

Apport is collecting data like what version of Diodon is installed, what are the dependencies etc. and then also ask you whether you want to include your clipboard history. It then puts all this together and uploads it to Launchpad.net, where you can input a bug description. And then hopefully with all this information we will be able to find the cause of the issue quickly and provide a fix.

So therefore have fun using Diodon and do not hesitate to file any bug or annoyance you find.

Nevertheless is this new version of Diodon a special milestone and therefore I want to give it the version 1.0.0. This is mainly to its long overdue new icons set which gives it’s unique look and feel. razvi of iloveubuntu.net has summarized the significance of this change in this blog post which I want to quote here:

Usually, app icons play an important role on establishing the identity of applications, visual items that contain essential aspects of applications and/or shapes, colors, patterns, etc, designed with an easy-app-identification process in mind. [...] Diodon has just been enriched with new icons, refreshing its identity and properly expressing itself via simplistic yet interesting monochrome icons, as well as adopting colored icons.

As a celebration of this new milestone I think it is also time to start promoting Diodon even more. I therefore put a list together with possibilities for you to help out. And I am sure you will have plenty of more ideas.

• Post about Diodon on your blog
• You use another distribution then Ubuntu? Create packages for this distribution (I promise that I will soon look into making a package for the official Ubuntu repository).
• Add Diodon to your software stack on Ohloh.net by using the I Use This! button.
• Mark Diodon as “Like” on AlternativeTo and add alternatives
• Now, there is also a Diodon user group on launchpad. Join in to show your appreciation to Diodon and also optionally take part in the mailing list conversations.
• Or simply follow Diodon on Freecode
• …

I am looking forward to see Diodon getting more adapted in 2013. I herewith also wanted to take the opportunity to thanks the Diodon user community for all the valuable feedback I have received and for you loyalty . Thanks… and have a happy new year 2013…

For instance is there now a unit testing framework in place which I wrote about in a previous post.

What I want to introduce you in this post though is a start into a new Diodon era using Zeitgeist. You might ask yourself: What is Zeitgeist?

That’s a good question and I think best answered by the Zeitgeist folks themselves. So here is a quote from there website:

Zeitgeist is a service which logs the users’ activities and events, anywhere from files opened to websites visited and conversations had.

It makes this information readily available for other applications to use. It is able to establish relationships between items based on similarity and usage patterns.

As Diodon is basically keeping a history of the last users’ copy events it makes perfect sense to store those events in Zeitgeist. Therefore is there now a Zeitgeist plugin (a so called Data Source) available for Diodon. You simply have to install the package diodon-plugins and enable the plugin by going to Preferences -> Plugins.

What this plugin for now basically does is storing a description of what has been copied at a certain time plus the path to the original application content has been copied from. It also points to a clipboard id. However as items currently get deleted when a certain history size has been reached, this id can not be used to execute a copy/paste event again. There are some ideas though for the future that it might be possible to replace the current xml based storage with Zeitgeist completely. This is however only an idea so far. This Diodon Zeitgeist Plugin therefore is a playground to really see what Zeitgeist is capable of and how well it works with a clipboard manager. So if you have any feedback where we can go further from here, please let me know.

Will keep you updated about more exciting news when it comes to Diodon.

Years ago when I still was at high school we had to write an essay on a Windows related topic. At that time I did not really know much about Linux so I did not mind as much as I would probably do today. I chose to focus on the Windows settings system mainly the Registry. In addition to the essay I also developed an application which is basically an interface to many Windows global settings available. After a while I polished this application a bit and published it as Open Source under the name “Tunefish” on SourceForge. I wrote the application in Delphi which used to be quite popular at that time. I maintained it for a while. However when I completely switched over to Linux quite some time ago I lost interest and gave it up for adoption . Unfortunately up to today, there is no-one who wanted to take over this project.

A few days ago when I was crawling through my current projects it occurred to me that not very often, but occasionally people still seem to download Tunefish. However, as it gives you access to many basic Windows settings and has not been tested since Windows XP SP2 it most likely will do more harm then anything else. So I have decided that I delete the project with all its files and executables altogether.

However as there might still be some valuable knowledge in the source code and its thorough documentation the Subversion repository remains for now. So please feel free to have a look at it and use it under the term of the GPLv2 or higher. If someone still wants to take over the hole project please have a look here. That would be awesome. If there is any issue with the current terms the code is licensed under, please talk to me. I am sure we find a solution.

For all former users of Tunefish I just wanted to point out that there are plenty of alternatives out there which do a similar job Tunefish used to do. If you have any other alternatives you use I am sure people would appreciate if you share them as comment on this post.

So Goodbye Tunefish. Let’s head for new shores…

When I started my research on different vala unit test framework I found quite a few. Amongst them were vala-gtest-module and valadate.

Those frameworks looked all quite promising. Unfortunately, all do not seem to be maintained anymore and are not available as official package in any distribution repository (Note: It seems that Yorba has adopted valadate. So there is still hope… ).
Those issues make it very difficult to use these frameworks, as it would mean to run tests, the test framework library needs to be built from source as well. And as the code base of such is quite old, it might happen that it does not even build with the current vala version.

So I had to look for another solution. Doing so I came across GTest which is included in glib. This has the great advantage that I would not even need another dependency to get my vala code tested. And luckily the developers behind libgee created a very useful TestCase class based on GTest so to use the GTest api is not as cumbersome.

Let’s take a look at this class and see how we can use it (note that the class is licensed under LGPL and written by Julien Peeters, see original source code):

public abstract class Gee.TestCase : Object {
 
	private GLib.TestSuite suite;
	private Adaptor[] adaptors = new Adaptor[0];
 
	public delegate void TestMethod ();
 
	public TestCase (string name) {
		this.suite = new GLib.TestSuite (name);
	}
 
	public void add_test (string name, owned TestMethod test) {
		var adaptor = new Adaptor (name, (owned)test, this);
		this.adaptors += adaptor;
 
		this.suite.add (new GLib.TestCase (adaptor.name,
		                                   adaptor.set_up,
		                                   adaptor.run,
		                                   adaptor.tear_down ));
	}
 
	public virtual void set_up () {
	}
 
	public virtual void tear_down () {
	}
 
	public GLib.TestSuite get_suite () {
		return this.suite;
	}
 
	private class Adaptor {
 
		public string name { get; private set; }
		private TestMethod test;
		private TestCase test_case;
 
		public Adaptor (string name,
		                owned TestMethod test,
		                TestCase test_case) {
			this.name = name;
			this.test = (owned)test;
			this.test_case = test_case;
		}
 
		public void set_up (void* fixture) {
			this.test_case.set_up ();
		}
 
		public void run (void* fixture) {
			this.test ();
		}
 
		public void tear_down (void* fixture) {
			this.test_case.tear_down ();
		}
	}
}

What we can do now is to implement a test case class like the following:

class TestExample : TestCase {
 
  public TestExample() {
    // assign a name for this class
    base("TestExample");
    // add test methods
    add_test("test_example", test_example);
   }
 
   public override void set_up () {
     // setup your test
   }
 
   public void test_example() {
     // add your expressions
     // assert(expression);
   }
 
   public override void tear_down () {
     // tear down your test
   }
}

There are no naming convention here, how a test class and its test methods are called. However I prefer to name a test class the same as the class its testing + Test as prefix. For example the class above TestExample tests the functionality of the class Example. I do the same for test methods. So this means that the method test_example above tests the method example on the class Example.

This just as a note. Let’s go back to setting up our testing environment. So to be able to run the test we have just created, we need to compile all test classes into one executable with the following main method:

public static int main(string[] args) {
  Test.init (ref args);
  // add any of your test cases here
  TestSuite.get_root().add_suite(new TestExample().get_suite());
  return Test.run ();
}

Of course, you can create this executable by using your preferred build tool. In this post I just wanted to show you how this can be done with waf which I am currently using to build diodon.

So a wscript_build of a tests folder where all test cases are located could look like this:

prog = bld.new_task_gen (
  features = 'c cprogram test',
  target = 'example-test',
  source = bld.path.ant_glob (incl='**/*.vala'))

You probably noted that there is a feature test configured. This is a feature to run tests while building the executable with waf. I will come back to this later.

Let’s just make the assumption that this is not configured. This way we would now have an executable example-test which we could simply run in a terminal.

The output could look like this:

/TestExample/test_example: OK

Running a test executable would now always run all test cases. However this might take quite a while considering you wrote thousands of tests . For this reason, there is a tool called gtester included in glib which has some nice features such as running only a specific test case.

So let’s say we only want to run the test TestExample, we could use the following command:

gtester --verbose -p /TestExample example-test

gtester has many more options. Best take a look at its documentation.

It’s all great that we can now run our written tests manually to see whether our changes broke anything. However, it would be even better if such would be run every time we built our source code. And when a test fails that the build will fail as well (of course there should always be an option to disable running tests). This has the advantage when someone builds or packages your vala code on a different system with different dependencies, that errors the user might have with your code, already occur while building respectively running the tests.

So to do this with waf I want to come back to the test feature I have mentioned above. Beside configuring this feature we have to adjust the main wscript which could look like the following:

...
def options(opt):
  ...
  opt.add_option('--skiptests', action='store_true', default=False,
    dest='skiptests', help='Skip unit tests')
  ...
 
def build(ctx):
  ...
  if not Options.options.skiptests:
        ctx.add_subdirs('tests')
  ...
  ctx.add_post_fun(post)
 
  # to execute all tests:
  # $ waf --alltests
  # to set this behaviour permanenly:    
  ctx.options.all_tests = True
 
def post(ctx):
  waf_unit_test.summary(ctx)
 
  # Tests have to pass
  lst = getattr(ctx, 'utest_results', [])
  if lst:
    tfail = len([x for x in lst if x[1]])
    if tfail:
      ctx.fatal("Some test failed.")

When ./waf build is now called, the tests will be run as well. It is also possible to skip tests by simply using ./waf build –skiptests.

You can find a full fledge sample in the diodon source code.

If you use automake I would recommend you take a look at the libgee source code which have implemented a similar approach with automake.

This is it. Hope this was helpful. And do not forget: Test more!!! .

If you are an Arch Linux user this is now a great opportunity to check out Diodon on your system. However note that the package is still in an early stage. So expect that the build won’t go as smooth. It also depends on libindicator3 and libappindicator3 which are also not official packages.

Even more do those packages need testing. Although I can say that I was able to build diodon on my test arch installation and that it runs smoothly.

So let’s start with the instruction how to go about getting Diodon up and running on Arch. As diodon is only available in the Arch User Repository and also depends on other AUR packages, an easy way to go about this is to use yaourt. If you haven’t installed it yet you can follow these instruction.

As soon as you have yaourt installed, you can simply run following command:

yaourt -Sy diodon


and follow the instructions. If this step has been successful you can then simply run the command diodon.

Note: If one of the package fails to compile/install, best comment directly on the package itself on AUR. When you find bugs when Diodon could start smoothly, please report those on Launchpad. There is already one bug reported specific for arch linux. If you suffer from this bug as well, please add some comments.

It is exciting to see Diodon running on other Linux distributions. So which will be the next one?

Well, here it is . This new release of Diodon, however, does not bring many new feature but is a polish of the application you are (hopefully) already used to. Changes have been done so it compiles smoothly in Ubuntu Precise with its new Unity Lens api. And now you should be able to use python plugins without any hassle as well.

But there is one small change which might interest you much more, if you often use Diodon on your laptop running on battery…

You might now ask yourself, what does Diodon have to do with my battery? Let me dive into this a bit deeper by explaining how Diodon works.

So to be able to create a history of clipboard items Diodon has to tell the clipboard that it has to call Diodon when there is any new content. Diodon will than add such to its history.

This works great for the normal clipboard which you use with Ctrl + C. Unfortunately the clipboard is not able to tell Diodon, when a primary selection has changed (an area on the screen which is selected by the mouse). To get around this, Diodon has to check in a regular interval whether the primary selection has changed. This works quite well on desktop machines and plugged in laptops.
However, imagine when your CPU wants to go to sleep and just before it wants to the interval is over and will check whether the primary selection has changed. This of course will wake up the CPU again. As this happens over and over again it will discharge your battery faster than it would be really necessary.

There is now good news to this. In Diodon version prior to 0.8.0 there was no way to stop this timer but closing Diodon. In this new version, however, you can simple go the preferences and uncheck “Use primary selection”. This way you can still use Diodon (of course whit the restriction that the primary selection is not added to the history) but not uselessly waking up the CPU and therefore saving power.

Here you can find the new version to be installed for Ubuntu Precise. Let me know what you think.

There are also a bunch of ideas for different plugins. And I hope Diodon will finally get its own icon. (when you are a designer and would be willing to help us out here, please contact us).

We will see what of these things can be accomplished this year. However what I can assure you is that Diodon 0.7.0 will be released today.

It introduces a new key combination so the diodon history menu can be accessed just with one hand on the keyboard. You can read more about it here. Furthermore does this Diodon version also work together with Java applications. This has been a naughty bug and I am sure that quite a few people are happy to see this fixed.

You can install the new version with following commands:

sudo add-apt-repository ppa:diodon-team/stable
sudo apt-get update
sudo apt-get install diodon

Happy Diodon new year .

The idea for this has come from fatlp. Thanks a lot for this. You can find all details about it on this blueprint.

Up to today, when you wanted to access the indicator with your keyboard, you pressed and released <Ctrl><Alt>V and then used the arrows up and down following with Enter to choose a clipboard item.
This will still work in future releases. However in the new release (which is currently available in the daily ppa for testing) you can do the following:
Press <Ctrl><Alt>V. While you keep pressing <Ctrl><Alt> you can browse through the different clipboard items by pressing V multiple times until you have selected the item you want to paste. Now release <Ctrl><Alt> and the selected item will be copied to your clipboard and pasted (when enabled).
This of course also works with your customized key. The rule is that you keep pressing the modifiers and with the key you can browse through your history.

After I have been using this new key combination a couple of times I’ve already started to love. I hope you do as well .

I’m happy to hear your comments.

However here is a quick overview what has changed and what needs to be taken care of:

Release notes:

• Diodon has been updated to gtk+-3.0 and therefore runs only on Oneiric (or all other distributions supporting gtk+-3.0).
• gconf has been replaced with GSettings/dconf. All settings (except the history) will be lost after installing this version and need to be set again
• Unity Lens is not installed per default anymore. Install the package diodon-plugins and activate it in the preferences plugins tab. When building from source use ./waf configure –enable-unitylens-plugin to enable it.
• The Application Indicator is now also a plugin which is enabled by default. The plugin can be disabled in the preferences however.

Changelog:

• Implement plugin system using libpeas (LP: #826422)
• Unity Lens now runs on Oneiric (LP: #830001)
• Using libunique so only one instance can be started (LP: #870774)
• Update to gtk+-3.0 (LP: #794637)
• Fixed issues with gtk+-3.0 applications (LP: #879256, #875708)
• switching to GSettings/dconf (LP: #689462)

You can install Diodon with the following commands

sudo add-apt-repository ppa:diodon-team/stable
sudo apt-get update
sudo apt-get install diodon

This release also brought about changes which should make it easier to build Diodon on your preferred distribution. It used to be the case that Diodon required packages for the Application Indicators which are unfortunately not available on all other distribution.
When Diodon is built from source just running ./waf configure such packages will still be needed. However you can disable it with ./waf configure --disable-indicator-plugin.
Please notice when building Diodon with this option you can only use it with the Hotkey (<Ctrl><Alt>V per default).

I would love to see packages of Diodon for other distribution as well. So go for it .
When you struggle building Diodon please contact us.