Archive

Archive for July, 2015

Taking a look at some Linux e-mail clients

July 12th, 2015 No comments

Many people now use a browser based solution, like Gmail, for all of their e-mail needs however there are still plenty of reasons why someone might want to use a local e-mail client as well. In this post I’m going to take a look at some of the graphical e-mail client options available on Linux.

Balsa

I have to admin that I hadn’t even heard of Balsa before looking up e-mail clients to include in this list. In my limited time using it Balsa seems to be a relatively simple e-mail client that still offers quite a few options (supports POP3 and IMAP as well as PGP/GPG and even includes a spell checker) while still maintaining a very low memory footprint (less than 7MiB of RAM for an empty inbox). However one thing I couldn’t seem to get working was actually sending e-mail – it’s not that it was difficult to setup, I just simply couldn’t get it to connect to my SMTP server to send the mail. It kept timing out without giving me a cause which was annoying.

Balsa

Balsa

Balsa Project Website

Claws Mail

Similar to Balsa, Claws is also a very lightweight e-mail client that offers quite a few standard features but can also be expanded upon via plugins. Interestingly I couldn’t figure out a way to compose a non-plaintext (i.e. HTML) e-mail so perhaps the developers are of the opinion that e-mail should only be sent as text?

Claws Mail

Claws Mail

Claws Mail Project Website

Evolution

Evolution is/was (depends on who you ask) the golden standard for what an e-mail client on Linux should be. You can think of it as a complete Outlook replacement as it does so much more than just e-mail (contacts, calendar, memos, etc.) all without the need for additional plugins. This does come at a bit of a price as Evolution certainly feels heavier and uses more memory than some other e-mail only clients.

Evolution

Evolution

Evolution Project Website

Geary

Geary is a relative newcomer and has been getting quite a bit of attention as it is included as the default e-mail client in elementaryOS. This application is beautiful however very, very streamlined. You won’t find things like plugins, PGP/GPG, or loads of configuration options here, instead Geary focuses on being the best user experience it can be out of the box.

Geary

Geary

Geary Project Website

GNUMail.app

GNUMail.app is quite a bit different from the other e-mail clients on this list. It is associated with the GNUstep project and runs on both Linux and Mac OS X. Unfortunately while trying to use it on Linux I found myself at a loss… I simply couldn’t figure out how to use the thing! I managed to configure my account settings but could never get it to actually download any e-mail. So without actually being able to use the application I don’t have much else to say about it.

GNUMail.app

GNUMail.app

GNUMail.app Wikipedia Page

KMail

KMail provides the e-mail duties for the Kontact Personal Information Manager collection of software. It is a fully featured e-mail client and, because of the other Kontact applications, offers a compelling pseudo-integrated alternative to something heavy like Evolution. This is especially true if you are using the KDE desktop environment where things feel even more integrated.

KMail

KMail

KMail Project Website

Slypheed

Slypheed and Claws Mail are very similar, which makes sense because they used to be the same project (one was simply a place to try new features before putting it into the “real” project). Even though they share a linage Slypheed and Claws Mail now have different code bases and development teams. That said there aren’t very many obvious differences between the two at this point.

Slypheed

Slypheed

Slypheed Project Website

Thunderbird

Thunderbird is one of the most popular free/open source e-mail clients around and for good reason. It offers a good amount of features and can make use of plugins to add even more functionality. While it may not quite match up to Evolution in terms of advanced functionality for most people, myself included, it works very well.

Thunderbird

Thunderbird

Thunderbird Project Website

Big distributions, little RAM 8

July 11th, 2015 2 comments

It’s been a while but once again here is the latest instalment of the series of posts where I install the major, full desktop, distributions into a limited hardware machine and report on how they perform. Once again, and like before, I’ve decided to re-run my previous tests this time using the following distributions:

  • Debian 8 (Cinnamon)
  • Debian 8 (GNOME)
  • Debian 8 (KDE)
  • Debian 8 (MATE)
  • Debian 8 (Xfce)
  • Elementary OS 0.3 (Freya)
  • Kubuntu 15.04 (KDE)
  • Linux Mint 17.1 (Cinnamon)
  • Linux Mint 17.1 (KDE)
  • Linux Mint 17.1 (MATE)
  • Linux Mint 17.1 (Xfce)
  • Mageia 4.1 (GNOME)
  • Mageia 4.1 (KDE)
  • OpenSUSE 13.2 (GNOME)
  • OpenSUSE 13.2 (KDE)
  • Ubuntu 15.04 (Unity)
  • Ubuntu Mate (MATE)
  • Xubuntu 15.04 (Xfce)

I also attempted to try and install Fedora 21 and Linux Mint 17.2 (KDE) but it just wouldn’t go.

All of the tests were done within VirtualBox on ‘machines’ with the following specifications:

  • Total RAM: 512MB
  • Hard drive: 8GB
  • CPU type: x86 with PAE/NX
  • Graphics: 3D Acceleration enabled

The tests were all done using VirtualBox 4.3.30, and I did not install VirtualBox tools (although some distributions may have shipped with them). I also left the screen resolution at the default (whatever the distribution chose) and accepted the installation defaults. All tests were run prior to June 2015 so your results may not be identical.

Results

Just as before I have compiled a series of bar graphs to show you how each installation stacks up against one another. Measurements were taken using the free -m command for memory and the df -h command for disk usage.

Like before I have provided the results file as a download so you can see exactly what the numbers were or create your own custom comparisons (see below for link).

Things to know before looking at the graphs

First off if your distribution of choice didn’t appear in the list above its probably not reasonably possible to be installed (i.e. I don’t have hours to compile Gentoo) or I didn’t feel it was mainstream enough (pretty much anything with LXDE). As always feel free to run your own tests and link them in the comments for everyone to see.

First boot memory (RAM) usage

This test was measured on the first startup after finishing a fresh install.

First_Boot_AllMemory (RAM) usage after updates

This test was performed after all updates were installed and a reboot was performed.

After_Updates_AllMemory (RAM) usage change after updates

The net growth or decline in RAM usage after applying all of the updates.

Usage_Changes_AllInstall size after updates

The hard drive space used by the distribution after applying all of the updates.

Install_SizeConclusion

Once again I will leave the conclusions to you. Source data provided below.

Source Data

CoreGTK now supports GTK+ 3 and is built from GObject Introspection

July 1st, 2015 No comments

It has been quite a while since the first release of CoreGTK back in August 2014 and in that time I’ve received a lot of very good feedback about the project, what people liked and didn’t like, as well as their wishlists for new features. While life has been very busy since then I’ve managed to find a little bit of time here and there to implement many of the changes that people were hoping for. As mentioned in my previous post here are the highlighted changes for this new version of CoreGTK:

Move from GTK+ 2 to GTK+ 3

GTK+ 3 is now the current supported widget toolkit and has been since February 2011. Now that GTK+ 3 is supported on all platforms (Windows, Mac and Linux) it makes sense to move over and take advantage of the updated features.

Additionally this allows for a natural break in compatibility with the previous release of CoreGTK. What that means for the end user is that I currently don’t have any plans on going back and applying any of these new ideas/changes to the old GTK+ 2 version of the code base, instead focusing my time and effort on GTK+ 3.

Prefer the use of glib data types over boxed OpenStep/Cocoa objects (i.e. gint vs NSNumber)

When originally designing CoreGTK I decided to put a stake in the ground and simply always favour OpenStep/Cocoa objects where possible. The hope was that this would allow for easier integration with existing Objective-C code bases. Unfortunately good intentions don’t always work out in the best way. One of the major pieces of feedback I got was to take a less strict approach on this and drop the use of some classes where it makes sense. Specifically keep using NSString instead of C strings but stop using NSNumber in place of primitives like gint (which itself is really just a C int). The net result of this change is far less boilerplate code and faster performance.

So instead of writing this:

/* Sets the default size of the window */
[window setDefaultSizeWithWidth: [NSNumber numberWithInt:400] andHeight: [NSNumber numberWithInt:300]];

you can now simply write this:

/* Sets the default size of the window */
[window setDefaultSizeWithWidth: 400 andHeight: 300];

Base code generation on GObject Introspection instead of a mix of automated source parsing and manual correction

The previous version of CoreGTK was, shall we say, hand crafted. I had written some code to parse header files and generate a basic structure for the Objective-C output but there was still quite a bit of manual work (days/weeks/months) involved to clean up this output and make it what it was. Other than the significant investment in time required to make this happen it was also prone to errors and would require starting back at square one with every new release of GTK+.

This time around the output is generated using GObject Introspection, specifically by parsing the generated GIR file for that library with the new utility CoreGTKGen. The proccess of generating new CoreGTK bindings using CoreGTKGen now takes just a couple of seconds and produces very clean and simple source code files. This is also really just the start as I’m sure there are plenty of improvements that can be made to CoreGTKGen to make it even better! Perhaps equally exciting is that once this process is perfected it should be relatively easy to adapt it to support other GObject Introspection supported libraries like Pango, Gdk, GStreamer, etc.

Let’s have an example shall we?

While there are a couple of good examples over at the Getting Started page of the Wiki and even within the CoreGTK repo itself I figured I would show something different here. It has always been my goal with this project to make it as easy as possible for existing Objective-C users to port their applications to GTK+. Perhaps you were previously using a widget toolkit like Cocoa on the Mac and now you want to release your application on more platforms. What better way than to keep your existing business logic and swap out the GUI (you do practice good MVC right? :P).

So going with this idea here is a tutorial of porting the “Start Developing Mac Apps Today” example from Apple’s developer website here. This application is incredibly simplistic but basically lets you set a “volume” value either by typing in a number in the text box at the top, moving the slider up and down, or pressing the Mute button. Regardless of which action you take the rest of the GUI is updated to match.

Step 1) Setup the GUI

For this I will be using GLADE as a replacement for the Xcode Interface Builder but you could always program your GUI by hand as well.

From the Apple website we are trying to re-create something that looks like this:

apple_exampleThankfully in GLADE this is relatively easy and I was able to do a quick and dirty mock up resulting in this:

glade_mockup

 

Step 2) Configure GUI signals (i.e. events)

GLADE also makes this easy, simply click on the widget, flip over to the Signals tab and type in your handler name.

textEntrySignal

Here are the ones I created:

  • window (GtkWindow)
    • Signal: destroy
    • Handler: endGtkLoop
  • entry (GtkEntry)
    • Signal: changed
    • Handler: takeValueForVolume
  • scale (GtkScale)
    • Signal: value-changed
    • Handler: sliderValueChanged
  • mute_button (GtkButton)
    • Signal: clicked
    • Handler: muteButtonClicked

Step 3) Create classes

Even though Cocoa and GTK+ don’t map exactly the same I decided to follow Apple’s conventions where it made sense just for consistency.

AppDelegate.h

#import "CoreGTK/CGTKEntry.h"
#import "CoreGTK/CGTKScale.h"

#import "Track.h"

@interface AppDelegate : NSObject
{
    CGTKEntry *textField;
    CGTKScale *slider;
    Track *track;
    BOOL updateInProgress;
}

@property (nonatomic, retain) CGTKEntry *textField;
@property (nonatomic, retain) CGTKScale *slider;
@property (nonatomic, retain) Track *track;

/* Callbacks */
-(void)mute;
-(void)sliderChanged;
-(void)takeValueForVolume;

/* Methods */
-(void)updateUserInterface;

-(void)dealloc;

@end

AppDelegate.m

#import "AppDelegate.h"

@implementation AppDelegate

@synthesize textField;
@synthesize slider;
@synthesize track;

/* Callbacks */
-(void)mute
{
    if(!updateInProgress)
    {
        updateInProgress = YES;
        
        [self.track setVolume:0.0];
    
        [self updateUserInterface];
        
        updateInProgress = NO;
    }
}

-(void)sliderChanged
{
    if(!updateInProgress)
    {
        updateInProgress = YES;
        
        [self.track setVolume:[self.slider getValue]];
    
        [self updateUserInterface];
        
        updateInProgress = NO;
    }
}

-(void)takeValueForVolume
{
    NSString *text = [self.textField getText];
    if([text length] == 0)
    {
        return;
    }
    
    if(!updateInProgress)
    {
        updateInProgress = YES;
        
        double newValue = [[self.textField getText] doubleValue];
    
        [self.track setVolume:newValue];
    
        [self updateUserInterface];
        
        updateInProgress = NO;
    }
}

/* Methods */
-(void)updateUserInterface
{
    double volume = [self.track volume];
    
    [self.textField setText:[NSString stringWithFormat:@"%1.0f", volume]];
    
    [self.slider setValue:volume];
}

-(void)dealloc
{
    [textField release];
    [slider release];
    [track release];
    [super dealloc];
}

@end

Track.h

/*
 * Objective-C imports
 */
#import <Foundation/Foundation.h>

@interface Track : NSObject
{
    double volume;
}

@property (assign) double volume;

@end

Track.m

#import "Track.h"

@implementation Track

@synthesize volume;

@end

Step 4) Wire everything up

In order to make everything work, load the GUI from the .glade file, connect the signals to the AppDelegate class, etc. we need some glue code. I’ve placed this all in the main.m file.

main.m

int main(int argc, char *argv[])
{    
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    
    /* This is called in all GTK applications. Arguments are parsed
    * from the command line and are returned to the application. */
    [CGTK autoInitWithArgc:argc andArgv:argv];
        
    /* Create a builder to load GLADE file */
    CGTKBuilder *builder = [[CGTKBuilder alloc] init];
    
    if([builder addFromFileWithFilename:@"mac_app.glade" andErr:NULL] == 0)
    {
        NSLog(@"Error loading GUI file");
        return 1;
    }
    
    /* Create an AppDelegate to link to the GUI */
    AppDelegate *appDelegate = [[AppDelegate alloc] init];
    
    /* Get text field, wrapping returned Widget in new CGTKEntry */
    appDelegate.textField = [[[CGTKEntry alloc] initWithGObject:(GObject*)[[CGTKBaseBuilder 
        getWidgetFromBuilder:builder withName:@"entry"] WIDGET]] autorelease];
    
    /* Get slider, wrapping returned Widget in new CGTKScale */
    appDelegate.slider = [[[CGTKScale alloc] initWithGObject:(GObject*)[[CGTKBaseBuilder 
        getWidgetFromBuilder:builder withName:@"scale"] WIDGET]] autorelease];
    
    /* Create track class for AppDelegate */
    Track *track = [[Track alloc] init];
    appDelegate.track = [track autorelease];
    
    /* Pre-synchronize the GUI */
    [appDelegate updateUserInterface];
    
    /* Use signal dictionary to connect GLADE signals to Objective-C code */
    NSDictionary *dic = [[NSDictionary alloc] initWithObjectsAndKeys:
                     [CGTKCallbackData withObject:[CGTK class] 
                         andSEL:@selector(mainQuit)], @"endGtkLoop",
                         
                     [CGTKCallbackData withObject:appDelegate 
                         andSEL:@selector(mute)], @"muteButtonClicked",
                         
                     [CGTKCallbackData withObject:appDelegate 
                         andSEL:@selector(sliderChanged)], @"sliderValueChanged",
                         
                     [CGTKCallbackData withObject:appDelegate 
                         andSEL:@selector(takeValueForVolume)], @"takeValueForVolume",
                     nil];

    /* CGTKBaseBuilder is a helper class to maps GLADE signals to Objective-C code */
    [CGTKBaseBuilder connectSignalsToObjectsWithBuilder:builder andSignalDictionary:dic];
    
    /* Show the GUI */
    [[CGTKBaseBuilder getWidgetFromBuilder:builder withName:@"window"] showAll];
    
    /*
     * Release allocated memory
     */
    [builder release];
            
    /* All GTK applications must have a [CGTK main] call. Control ends here
     * and waits for an event to occur (like a key press or
     * mouse event). */
    [CGTK main];
    
    /*
     * Release allocated memory
     */    
    [appDelegate release];
    [pool release];
    
    // Return success
    return 0;
}

 

Step 5) Compile and run

coregtk_result

So while this is a very basic, quick and dirty example it does prove the point. As for CoreGTK this release is still under development as I try and flush out any remaining bugs but please give it a shot, submit issues or pitch in to help if you’re interested! You can find the CoreGTK project at http://coregtk.org.

Example Source Code
File name: mac_port_example.zip
File hashes: Download Here
License: (LGPL) View Here
File size: 5.3KB
File download: Download Here

This post originally appeared on my personal website here.