Development

Giggle: A Git GUI

In the roughly five years that the Git distributed version control system has been around, it has gained quite a following. But at its core, Git is command-line oriented, which doesn't necessarily suit all of its users. Along the way, various GUI interfaces to Git have been created, including two Tcl/Tk-based tools that come with Git. Giggle is a GUI front-end for Git that is based on GTK+, which released a 0.5 version in late April.

The two tools that come with Git are oriented for two separate jobs: gitk is for browsing the repository, while git-gui provides a way to change the repository by committing files, merging, creating branches, and so on. The combination provides fairly full-featured access to Git but, because of its Tcl/Tk-based UI, lacks much in the way of eye appeal. In addition, those tools don't integrate well with a GNOME desktop, visually or functionally, which is what Giggle (and others) are trying to do.

Giggle combines both the repository browsing and changing functions into one program, but the feature set for the latter still lags git-gui. There are two modes in Giggle: "Browse" for looking through the source tree and "History" for looking at the commits in the repository.

Browse mode has a three-panel view, with the source tree on the left, any currently selected file's contents at the top right, and a log and graph of the revision history of the file at the bottom right. Clicking on earlier revisions in the history section changes the file pane to show that revision as one might expect. In addition, hovering over lines in the file pane brings up a pop-up with the commit information when that line was added, so you are essentially always seeing the equivalent of git blame.

Other operations, like editing or committing a file, creating a branch or patch, etc. are also available in browse mode. Double-clicking on a file name brings up an editor, though how it chooses which editor is a bit of a puzzle. For the Linux kernel repository, it decided that Emacs was a good choice, but for the LWN site code, KWrite was deemed the proper choice. Presumably the latter comes from some default editor choice down in the guts of the KDE preferences, but it's unclear where Emacs came from—perhaps the different implementation languages (Python vs. C) played a role.

That points to one of the areas that makes Giggle somewhat difficult to use: lack of any documentation. It's easy enough to click around and figure most things out, but a small users' manual would not be out of place either. In addition, the "click around" method of figuring out Giggle runs afoul of its other main deficiency: performance.

The performance of Giggle is rather poor, especially considering that the underlying tool has a definite focus on speed. Starting up Giggle in a Linux kernel repository takes 15-20 seconds of 99% CPU usage before there is a usable interface. That might be understandable for a large repository with many files and revisions, like the Linux kernel, but the performance was much the same on a much smaller repository.

It's not just startup that is slow, either. Switching from browsing to history mode can sometimes take up to ten seconds. When scrolling through history, Giggle will just pause and eat CPU for a while. Overall, it is a fairly painful experience, especially when compared with gitk, which seems quite snappy. Giggle also suffered from a few crashes and hangs in an hour's worth of using it.

History mode has the git log output in the top panel, along with the commit graph. Once a commit is chosen, the files affected are shown in the lower left. Each file can then be selected to show the diff output from each change made to that file in the lower right pane. There is no side-by-side comparison of old vs. new versions that other tools have, which might make a nice addition.

The project has been around since it was created in a January 2007 hackathon, and has slowly added more features. Development releases have been fairly frequent of late, more-or-less monthly since January, but before then things seem to have stagnated for almost a year. It is unclear what the plans are for 0.6 and beyond, though the list of open issues gives some ideas of the kinds of bugs and features that will likely be addressed.

There are other fairly active Git GUI programs available including git-cola, a Python/Qt4-based program, and gitg, which also based on GTK+. The latter is meant to track Git clients on Windows and MacOS to try to provide a consistent interface to Git on all three platforms. In particular, it closely tracks the GitX interface for MacOS X.

Other than purely visual attractiveness issues (and Tk definitely has a fairly clunky look and feel), it doesn't seem that Giggle and the other Git GUIs really provide very much beyond what gitk and git-gui do. That may explain the fairly slow pace of development for those tools as anyone who really wants a GUI interface to Git already has one at hand. It's also likely that standalone GUI interfaces are less interesting to those who are used to integrated development environments (IDEs) like Eclipse.

In the end, a GUI is supposed to make a tool easier to use, but Giggle does very little to make Git more approachable. The user still needs to understand a fair amount about Git in order to use the tool effectively. Once they do, using the command line may not be that much of a burden.

Comments (48 posted)

Brief items

Quotes of the week

-- David Parnas [PDF]

-- Jim Gettys

Comments (1 posted)

Ardour 2.8.8 released

Version 2.8.8 of the Ardour audio editor is out. "Although this is primarily a bug-fix release, some of the 'bugs' fixed are so pervasive and significant that they could almost count as new features. In particular, automation editing has finally arrived at a place that people with experience on other DAWs may consider actually usable."

Full Story (comments: none)

GCC begins move to C++

It's now official: the GCC compiler is moving to a C++ implementation. "I am pleased to report that the GCC Steering Committee and the FSF have approved the use of C++ in GCC itself. Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake." The next step is the bashing out of a set of C++ coding standards limiting the set of C++ language features which can be used.

Full Story (comments: 107)

gst123-0.1.0 released

gst123 is a command-line media player based on GStreamer; the 0.1.0 release is available now. "Since gst123-0.1.0 support for watching videos has been added; however gst123 should run fine in situations where no X11 display is available; videos can be played without X11 display, too (-x, --novideo); in this case, only the audio stream will be played."

Full Story (comments: none)

KDE Software Compilation 4.5 Beta1 Released

KDE has announced the first beta of KDE SC 4.5.0. Some of the improvements in KDE SC 4.5 include a reworked notification area and KWin-Tiling. "KDE is now firmly in beta mode, meaning that the primary focus is on fixing bugs and preparing the stable release of the software compilation this summer."

Comments (4 posted)

KOffice 2.2 released

The KOffice 2.2 release is out. "This release should be much more stable and full-featured than 2.1. Version 2.2 has received many enhancements to the layout engine, the libraries and the filters. There are still areas in the user interface that we want to work on before stating that KOffice is fit for the general public. We are, however, at a stage where we think that KOffice can be used for real work by some users." Changes include the return of the Kexi data management application, working spell checking, better MS Office compatibility, and more.

Comments (none posted)

MPlayer 1.0rc3 released

The MPlayer 1.0rc3 release is out. It includes lots of new codecs, a long list of code improvements, and more. What it does not appear to be is an actual release candidate: "Since it is designed to be compatible with the FFmpeg 0.5 branch, it will be useful to distros and other users still tracking said branch. Thus we are now publishing it even though it is outdated even before the day of its release. For general usage current Subversion snapshots should be a better fit, as many bug fixes and new features are available." It's hard to say when a real 1.0 might come out; 1.0rc2 was announced in October, 2007. (Thanks to Martin Jeppesen).

Comments (3 posted)

Pylons 1.0 released

Version 1.0 of the Pylons web framework has been released. "Pylons 1.0 finally drops all the legacy handlers from the 0.9 series, reducing the codebase from ~1300 lines of code, to 1080. Not many frameworks actually shed code between releases, and I'd like to be able to keep Pylons this small going forward as we've shrunk the code-base for almost every release of Pylons since the 0.8 series."

Comments (none posted)

Thunderbird 3.1 Release Candidate 1 is Here

Mozilla has announced the first release candidate of Thunderbird 3.1. "Thunderbird 3.1 Release Candidate 1 is our latest development milestone. While this release is considered to be stable, it is intended for developers and members of our testing community to use for early evaluation and feedback. Users of this latest released version of Thunderbird should not expect all of their add-ons to work properly with this milestone."

Comments (40 posted)

The WikiReader development kit

The first release of "wrdk," otherwise known as the WikiReader development kit, is available. "wrdk is a pre-built toolchain, libraries, set of examples, and simple serial loader that makes developing applications for the Openmoko WikiReader a little bit easier. Included is fairly high level access to most of the hardware including the file system, LCD, buttons, and touch screen."

Full Story (comments: none)

Newsletters and articles

Development newsletters from the last week

• Caml Weekly News (June 1)
• PostgreSQL Weekly News (May 31)
• Tcl-URL! (May 28)

Comments (1 posted)

Danjou: Thoughts and rambling on the X protocol

Julien Danjou shares some thoughts about X, XCB and X11. "Two years ago, while working on awesome, I joined the Freedesktop initiative to work on XCB. I had to learn the arcane of the X11 protocol and all the mysterious and old world that goes with it. Now that I've swum all this months in this mud, I just feel like I need to share my thoughts about what become a mess over the decades." (Thanks to Paul Wise)

Comments (108 posted)

Humphrey: Experiments with audio, part X

On his blog, David Humphrey writes about exposing audio data from HTML 5 video and audio elements to JavaScript. The folks working on this stuff are pushing the envelope of what can be done with JavaScript. "Along with the suggestion to use typed arrays also came a less welcome suggestion: remove the FFT calculation from C++ and do it all in JavaScript. When I suggested this in our #audio irc channel, a lot of people were upset, saying that this was a bad idea, that we’d never be fast enough, etc. However, I pulled it out anyway in order to force them to try. Corban responded by rewriting his dsp.js library to use Float32Array, which can now do 1000 FFTs on a 2 channel * 2048 sample buffer in 490ms, or 0.49ms per fft (js arrays take 2.577ms per fft, so a lot faster!)." (Thanks to Peter Wason.)

Comments (43 posted)

Algorithmic Music Composition With Linux, Part 1 (Linux Journal)

Dave Phillips begins a tour of three Linux software packages designed for making music by the numbers. "Common Music/Grace is a software system designed to assist composers working in music styles that employ chance, random, fractal, and other stochastic methods of generating values for their musical materials. Common Music is a music programming language that includes a variety of functions and routines particularly important to algorithmic composition. Grace is the Graphic Realtime Algorithmic Composition Environment, a JUCE-based GUI for Common Music that includes code editors for the Sal and Scheme language dialects, a set of predefined instruments, an interactive plotter with playback and various display options, a variety of output targets, and access to the host system's audio and MIDI I/O services."

Comments (none posted)

Popov: Exposure Blending with digiKam

On his blog, Dmitri Popov writes about using digiKam to do exposure blending. When taking photographs of high-contrast scenes, it can be difficult to get the right exposure throughout the image, but exposure blending can help. "While exposure blending sounds simple in theory, achieving usable results can be a rather laborious and time-consuming process. Fortunately, digiKam can do the donkey job for you thanks to an exposure blending tool bundled with the Kipi plugins. The exposure blending tool relies on the hugin application for processing and fusing photos, so you must install it on your machine beforehand."

Comments (none posted)

Page editor: Jonathan Corbet
Next page: Announcements>>