Archive

Posts Tagged ‘CoreGTK’

CoreGTK 3.10.2 Released!

February 19th, 2016 No comments

The next version of CoreGTK, version 3.10.2, has been tagged for release today.

Highlights for this release:

  • This is a bug fix release.
  • Corrected issue with compiling CoreGTK on OS X.

CoreGTK is an Objective-C language binding for the GTK+ widget toolkit. Like other “core” Objective-C libraries, CoreGTK is designed to be a thin wrapper. CoreGTK is free software, licensed under the GNU LGPL.

You can find more information about the project here and the release itself here.

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Linux Mint 18.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Let’s write a very simple text editor in CoreGTK

December 5th, 2015 No comments

In this post I’ll quickly show how you can write a very simple text editor using CoreGTK. This example is purposely very basic, has no real error handling and few features but it does show how to use CoreGTK in various ways.

To start with I quickly threw something together in GLADE (which if you aren’t aware is an excellent drag and drop GUI editor for GTK+).

coregtk_glade

Very basic shell in GLADE

Next I created a SimpleTextEditor class that will house the majority of my logic and stubbed out my callbacks and methods.

@interface SimpleTextEditor : NSObject
{
    CGTKTextView *txtView;
    CGTKWidget *window;
}

-(void)show;

// Callbacks
-(void)winMain_Destroy;
-(void)btnNew_Clicked;
-(void)btnOpen_Clicked;
-(void)btnSave_Clicked;

// Helper methods to deal with the text view
-(NSString *)getText;
-(void)setText:(NSString *)text;

@end

Now the fun part begins: filling in the implementation of the methods. First create the init and dealloc methods:

-(id)init
{
    self = [super init];
    
    if(self)
    {
        CGTKBuilder *builder = [[CGTKBuilder alloc] init];
        if(![builder addFromFileWithFilename:@"gui.glade" andErr:NULL])
        {
            NSLog(@"Error loading GUI file");
            return nil;
        }
        
        NSDictionary *dic = [[NSDictionary alloc] initWithObjectsAndKeys:
            [CGTKCallbackData withObject:self andSEL:@selector(winMain_Destroy)], @"winMain_Destroy",
            [CGTKCallbackData withObject:self andSEL:@selector(btnNew_Clicked)], @"btnNew_Clicked",
            [CGTKCallbackData withObject:self andSEL:@selector(btnOpen_Clicked)], @"btnOpen_Clicked",
            [CGTKCallbackData withObject:self andSEL:@selector(btnSave_Clicked)], @"btnSave_Clicked",
            nil];
        
        [CGTKBaseBuilder connectSignalsToObjectsWithBuilder:builder andSignalDictionary:dic];
        
        // Get a reference to the window
        window = [CGTKBaseBuilder getWidgetFromBuilder:builder withName:@"winMain"];
        
        // Get a reference to the text view
        txtView = [[CGTKTextView alloc] initWithGObject:[[CGTKBaseBuilder getWidgetFromBuilder:builder withName:@"txtView"] WIDGET]];
        
        [builder release];
    }
    
    return self;
}
-(void)dealloc
{
    [txtView release];
    [window release];
    [super dealloc];
}

OK let’s break down what we’ve done so far.

CGTKBuilder *builder = [[CGTKBuilder alloc] init];
if(![builder addFromFileWithFilename:@"gui.glade" andErr:NULL])
{
    NSLog(@"Error loading GUI file");
    return nil;
}

First thing is to parse the GLADE file which is what this code does. Next we need to connect the signals we defined for the different events in GLADE to the callback methods we defined in our code:

NSDictionary *dic = [[NSDictionary alloc] initWithObjectsAndKeys:
    [CGTKCallbackData withObject:self andSEL:@selector(winMain_Destroy)], @"winMain_Destroy",
    [CGTKCallbackData withObject:self andSEL:@selector(btnNew_Clicked)], @"btnNew_Clicked",
    [CGTKCallbackData withObject:self andSEL:@selector(btnOpen_Clicked)], @"btnOpen_Clicked",
    [CGTKCallbackData withObject:self andSEL:@selector(btnSave_Clicked)], @"btnSave_Clicked",
    nil];

[CGTKBaseBuilder connectSignalsToObjectsWithBuilder:builder andSignalDictionary:dic]

Finally extract and store references to the window and the text view for later:

// Get a reference to the window
window = [CGTKBaseBuilder getWidgetFromBuilder:builder withName:@"winMain"];

// Get a reference to the text view
txtView = [[CGTKTextView alloc] initWithGObject:[[CGTKBaseBuilder getWidgetFromBuilder:builder withName:@"txtView"] WIDGET]];

Before we can test anything out we need to fill in a few more basic methods to show the window on command and to exit the GTK+ loop when we close the window:

-(void)show
{
    [window showAll];
}

-(void)winMain_Destroy
{
    [CGTK mainQuit];
}

Now we can actually use our SimpleTextEditor so let’s write a main method to create it:

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 and display editor
    SimpleTextEditor *editor = [[SimpleTextEditor alloc] init];
    
    // Check for error
    if(editor == nil)
    {
        return 1;
    }
    
    // Show the window    
    [editor show];
    
    // Start GTK+ loop
    [CGTK main];

    // Release allocated memory
    [editor release];
    [pool release];

    // Return success
    return 0;
}

Compile and run this and you’ll be presented with a cool Simple Text Editor window!

Our very... err... simple text editor

Our very… err… simple text editor

So far so good. Let’s keep filling in our stubbed in methods starting with our helper methods that will allow us to manipulate the underlying text buffer:

-(NSString *)getText
{
    gchar *gText = NULL;
    GtkTextBuffer *buf = NULL;
    GtkTextIter start, end;
    NSString *nsText = nil;
    
    // Grab reference to text buffer
    buf = [txtView getBuffer];
    
    // Determine the bounds of the buffer
    gtk_text_buffer_get_bounds (buf, &start, &end);
    
    // Get the gchar text from the buffer
    gText = gtk_text_buffer_get_text(buf, &start, &end, FALSE);
    
    // Convert it to an NSString
    nsText = [NSString stringWithUTF8String:gText];
    
    // Free the allocated gchar string
    g_free(gText);

    // Return the text
    return nsText;
}

-(void)setText:(NSString *)text
{
    // Get reference to text buffer
    GtkTextBuffer *buf = [txtView getBuffer];
    
    // Set contents of text buffer
    gtk_text_buffer_set_text(buf, [text UTF8String], -1);
}

At this point we have everything we need to implement our New button click callback method:

-(void)btnNew_Clicked
{
    [self setText:@""];
}

Like I said this is a pretty basic example so in a real world application I would hope you would prompt the user before blowing away all of their text!

All that’s left to do at this point is to implement the Open and Save callback methods. For these I’m going to create a new class, MultiDialog, to show how you can still really dig into the GTK+ C code when you need to.

@interface MultiDialog : NSObject
{
}

+(NSString *)presentOpenDialog;
+(NSString *)presentSaveDialog;

@end

And here is the implementation:

@implementation MultiDialog

+(NSString *)presentOpenDialog
{
    // Variables
    CGTKFileChooserDialog *dialog = nil;
    gchar *gText = NULL;
    gint result;
    NSString *filename = nil;

    // Create the dialog itself
    dialog = [[CGTKFileChooserDialog alloc] initWithTitle:@"Open File" andParent:nil andAction:GTK_FILE_CHOOSER_ACTION_OPEN];
    
    // Add cancel and open buttons
    gtk_dialog_add_button ([dialog DIALOG],
                   "_Cancel",
                   GTK_RESPONSE_CANCEL);
    gtk_dialog_add_button ([dialog DIALOG],
                   "_Open",
                   GTK_RESPONSE_ACCEPT);
    
    // Run the dialog
    result = gtk_dialog_run (GTK_DIALOG ([dialog WIDGET]));

    // If the user clicked Open
    if(result == GTK_RESPONSE_ACCEPT)
    {
        // Extract the filename and convert it to an NSString
        gText = gtk_file_chooser_get_filename ([dialog FILECHOOSERDIALOG]);
        filename = [NSString stringWithUTF8String:gText];
    }

    // Cleanup
    g_free(gText);
    gtk_widget_destroy ([dialog WIDGET]);
    [dialog release];
    
    return filename;
}

+(NSString *)presentSaveDialog
{
    // Variables
    CGTKFileChooserDialog *dialog = nil;
    gchar *gText = NULL;
    gint result;
    NSString *filename = nil;

    // Create the dialog itself
    dialog = [[CGTKFileChooserDialog alloc] initWithTitle:@"Save File" andParent:nil andAction:GTK_FILE_CHOOSER_ACTION_SAVE];
    
    // Add cancel and save buttons
    gtk_dialog_add_button ([dialog DIALOG],
                   "_Cancel",
                   GTK_RESPONSE_CANCEL);
    gtk_dialog_add_button ([dialog DIALOG],
                   "_Save",
                   GTK_RESPONSE_ACCEPT);

    // Set settings
    gtk_file_chooser_set_do_overwrite_confirmation ([dialog FILECHOOSERDIALOG], TRUE);
    gtk_file_chooser_set_current_name([dialog FILECHOOSERDIALOG], "Untitled document");
    
    // Run the dialog
    result = gtk_dialog_run (GTK_DIALOG ([dialog WIDGET]));

    // If the user clicked Save
    if(result == GTK_RESPONSE_ACCEPT)
    {
        // Extract the filename and convert it to an NSString
        gText = gtk_file_chooser_get_filename ([dialog FILECHOOSERDIALOG]);
        filename = [NSString stringWithUTF8String:gText];
    }

    // Cleanup
    g_free(gText);
    gtk_widget_destroy ([dialog WIDGET]);
    [dialog release];
    
    return filename;
}

@end

There is quite a bit of code there but hopefully the comments make it pretty easy to follow. Now that we have our MultiDialog class we can use it in our SimpleTextEditor methods:

-(void)btnOpen_Clicked
{
    NSString *text = [NSString stringWithContentsOfFile:[MultiDialog presentOpenDialog]];    
    [self setText:text];
}

-(void)btnSave_Clicked
{
    NSString *filename = [MultiDialog presentSaveDialog];
    NSString *text = [self getText];
        
    NSError *error;
    BOOL succeed = [text writeToFile:filename atomically:YES encoding:NSUTF8StringEncoding error:&error];

    if(!succeed)
    {
        NSLog(@"%@:%s Error saving: %@", [self class], _cmd, [error localizedDescription]);
    }
}

And there you have it a very simple text editor that lets you open text file and save them. You can find the full source for this application under the examples directory of the CoreGTK github repository.

 

This post originally appeared on my website here.




I am currently running a variety of distributions, primarily Linux Mint 18.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Categories: Open Source Software, Tyler B Tags:

CoreGTK 3.10.1 Released!

September 8th, 2015 No comments

The next version of CoreGTK, version 3.10.1, has been tagged for release today.

Highlights for this release:

  • Added some missing (varargs) GTK+ functions. This makes it easier to create widgets like the FileChooserDialog.

CoreGTK is an Objective-C language binding for the GTK+ widget toolkit. Like other “core” Objective-C libraries, CoreGTK is designed to be a thin wrapper. CoreGTK is free software, licensed under the GNU LGPL.

You can find more information about the project here and the release itself here.

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Linux Mint 18.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

CoreGTK 3.10.0 Released!

August 20th, 2015 No comments

The next version of CoreGTK, version 3.10.0, has been tagged for release today.

Highlights for this release:

  • Move from GTK+ 2 to GTK+ 3
  • Prefer the use of glib data types over boxed OpenStep/Cocoa objects (i.e. gint vs NSNumber)
  • Base code generation on GObject Introspection instead of a mix of automated source parsing and manual correction
  • Support for GTK+ 3.10

CoreGTK is an Objective-C language binding for the GTK+ widget toolkit. Like other “core” Objective-C libraries, CoreGTK is designed to be a thin wrapper. CoreGTK is free software, licensed under the GNU LGPL.

You can find more information about the project here and the release itself here.

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Linux Mint 18.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

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.




I am currently running a variety of distributions, primarily Linux Mint 18.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

Adding GTK+ 3 support and building CoreGTK using GObject Introspection

May 3rd, 2015 No comments

It has been a while since I made any mention of my side project CoreGTK. I’m sure many people can relate that with life generally being very busy it is often hard to find time to work on hobby projects like this. Thankfully while that certainly has slowed the pace of development it hasn’t stopped it outright and now I am just about ready to show off the next update for CoreGTK.

First off thank you to everyone who took a look at the previous release. I received quite a few nice comments as well as some excellent feedback and hope to address quite a bit of that here. The feedback plus my own ideas of where I wanted to take the project defined the goal for the next release that I am currently working toward.

Goals for this release:

  • Move from GTK+ 2 to GTK+ 3
  • Prefer the use of glib data types over boxed OpenStep/Cocoa objects (i.e. gint vs NSNumber)
  • Base code generation on GObject Introspection instead of a mix of automated source parsing and manual correction

In order to explain the rationale behind these goals I figured I would address each point in more detail.

Move from GTK+ 2 to GTK+ 3

This one was pretty much a no-brainer. GTK+ 3 is now the current supported widget toolkit and has been since February 2011. Previously my choice to use GTK+ 2 was simply due to the fact that I wanted to make it as cross-platform as possible and at the time of release GTK+ 3 was not supported on Windows. Now that this has changed it only makes sense to continue forward using the current standard.

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 border width of the window */
[window setBorderWidth: [NSNumber numberWithInt:10]];

you can now simply write this:

/* Sets the border width of the window */
[window setBorderWidth: 10];

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 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. Currently, and I must stress that there is still quite a bit of room for improvement, this allows me to generate CoreGTK bindings from scratch within an hour or so. With some of the final touches I have in mind the time required for this should hopefully be down to minutes (the auto-generation itself only takes seconds but it isn’t 100% yet). Better still 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.

So where is this new release?

I am getting closer to showing off this new code but first I have to do a bit of cleanup on it. This hopefully won’t take too much longer and to show you how close I am here is a screenshot of CoreGTK running using GTK+ 3.

coregtk-3

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Linux Mint 18.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

CoreGTK 2.24.0 Released!

August 4th, 2014 No comments

The initial version of CoreGTK, version 2.24.0, has been tagged for release today.

Features include:

  • Targets GTK+ 2.24
  • Support for GtkBuilder
  • Can be used on Linux, Mac and Windows

CoreGTK is an Objective-C language binding for the GTK+ widget toolkit. Like other “core” Objective-C libraries, CoreGTK is designed to be a thin wrapper. CoreGTK is free software, licensed under the GNU LGPL.

You can find more information about the project here and the release itself here.

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Linux Mint 18.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).

CoreGTK

January 28th, 2014 2 comments

A while back I made it my goal to put together an open source project as my way of contributing back to the community. Well fast forward a couple of months and my hobby project is finally ready to be shown the light of day. I give you… CoreGTK

CoreGTK is an Objective-C binding for the GTK+ library which wraps all objects descending from GtkWidget (plus a few others here and there). Like other “core” Objective-C libraries it is designed to be a very thin wrapper, so that anyone familiar with the C version of GTK+ should be able to pick it up easily.

However the real goal of CoreGTK is not to replace the C implementation for every day use but instead to allow developers to more easily code GTK+ interfaces using Objective-C. This could be especially useful if a developer already has a program, say one they are developing for the Mac, and they want to port it to Linux or Windows. With a little bit of MVC a savvy developer would only need to re-write the GUI portion of their application in CoreGTK.

So what does a CoreGTK application look like? Pretty much like a normal Objective-C program:

/*
 * Objective-C imports
 */
#import <Foundation/Foundation.h>
#import "CGTK.h"
#import "CGTKButton.h"
#import "CGTKSignalConnector.h"
#import "CGTKWindow.h"

/*
 * C imports
 */
#import <gtk/gtk.h>

@interface HelloWorld : NSObject
/* This is a callback function. The data arguments are ignored
 * in this example. More callbacks below. */
+(void)hello;

/* Another callback */
+(void)destroy;
@end

@implementation HelloWorld
int main(int argc, char *argv[])
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    /* We could use also CGTKWidget here instead */
    CGTKWindow *window;
    CGTKButton *button;

    /* 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 new window */
    window = [[CGTKWindow alloc] initWithGtkWindowType:GTK_WINDOW_TOPLEVEL];

    /* Here we connect the "destroy" event to a signal handler in 
     * the HelloWorld class */
    [CGTKSignalConnector connectGpointer:[window WIDGET] 
        withSignal:@"destroy" toTarget:[HelloWorld class] 
        withSelector:@selector(destroy) andData:NULL];

    /* Sets the border width of the window */
    [window setBorderWidth: [NSNumber numberWithInt:10]];

    /* Creates a new button with the label "Hello World" */
    button = [[CGTKButton alloc] initWithLabel:@"Hello World"];

    /* When the button receives the "clicked" signal, it will call the
     * function hello() in the HelloWorld class (below) */
    [CGTKSignalConnector connectGpointer:[button WIDGET] 
        withSignal:@"clicked" toTarget:[HelloWorld class] 
        withSelector:@selector(hello) andData:NULL];

    /* This packs the button into the window (a gtk container) */
    [window add:button];

    /* The final step is to display this newly created widget */
    [button show];

    /* and the window */
    [window show];

    /* 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];

    [pool release];

    return 0;
}

+(void)hello
{
    NSLog(@"Hello World");
}

+(void)destroy
{
    [CGTK mainQuit];
}
@end
Hello World in action

Hello World in action

And because Objective-C is completely compatible with regular old C code there is nothing stopping you from simply extracting the GTK+ objects and using them like normal.

// Use it as an Objective-C CoreGTK object!
CGTKWindow *cWindow = [[CGTKWindow alloc] 
    initWithGtkWindowType:GTK_WINDOW_TOPLEVEL];

// Or as a C GTK+ window!
GtkWindow *gWindow = [cWindow WINDOW];

// Or even as a C GtkWidget!
GtkWidget *gWidget = [cWindow WIDGET];

// This...
[cWindow show];

// ...is the same as this:
gtk_widget_show([cWindow WIDGET]);

You can even use a UI builder like GLADE, import the XML and wire up the signals to Objective-C instance and class methods.

CGTKBuilder *builder = [[CGTKBuilder alloc] init];
if(![builder addFromFile:@"test.glade"])
{
    NSLog(@"Error loading GUI file");
    return 1;
}

[CGTKBuilder setDebug:YES];

NSDictionary *dic = [[NSDictionary alloc] initWithObjectsAndKeys:
                 [CGTKCallbackData withObject:[CGTK class] 
                     andSEL:@selector(mainQuit)], @"endMainLoop",
                 [CGTKCallbackData withObject:[HelloWorld class] 
                     andSEL:@selector(hello)], @"on_button2_clicked",
                 [CGTKCallbackData withObject:[HelloWorld class] 
                     andSEL:@selector(hello)], @"on_button1_activate",
                 nil];

[builder connectSignalsToObjects:dic];

CGTKWidget *w = [builder getWidgetWithName:@"window1"];
if(w != nil)
{
    [w showAll];
}

[builder release];

So there you have it that’s CoreGTK in a nutshell.

There are a variety of ways to help me out with this project if you are so inclined to do so. The first task is probably just to get familiar with it. Download CoreGTK from the GitHub project page and play around with it. If you find a bug (very likely) please create an issue for it.

Another easy way to get familiar with CoreGTK is to help write/fix documentation – a lot of which is written in the source code itself. Sadly most of the current documentation simply states which underlying GTK+ function is called and so it could be cleaned up quite a bit.

At the moment there really isn’t anything more formal than that in place but of course code contributions would also be welcome!

Update: added some pictures of the same program running on all three operating systems.

Hello World on Windows

Hello World on Windows

Hello World on Mac

Hello World on Mac

Hello World on Linux

Hello World on Linux

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Linux Mint 18.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).