Category Archives: March 2007
Take a trip down the dancing Tango on the desktop lane. Hang on, because it’s a wild ride!
When we are talking about software, we often go into technical details and forget that a desktop is for people, not robots, and thus it should be visually appealing and consistent looking. Consistence is a matter of not only following human interfaces guidelines, but using a partucular visual style throughout desktop as well. In the UNIX world we have several major efforts to provide means for such a desktop. One of them is Tango project that gives us an icon style guideline, an icon naming specification and an icon theme based on it.
In the days of its genesis several unification projects like RedHat’s Bluecurve already existed. It was Steven Garrity who suggested to work together in his historical email to Red Hat and Novell representatives and several individual artists. It took participants almost a year to get things straight and in October 2005 on annual GNOME summit in Boston Jakub Steiner and Steve Garrity announced the Tango project.
Let’s talk to two of most active contributors to the project — Jakub Steiner and Andreas Nilsson.
Please introduce yourself and tell us about open source projects you were/are involved into with regards to design.
Jakub Steiner (further as J.S.): I’m a 31 year old graphics and interaction designer at Novell. The project I have closest relation to and you could say am passionate about is GIMP, where among other minor contributions I designed the icon set for both 2.0 and the upcoming 2.4 version. In terms of amount of work, my blood and sweat went to OpenOffice.org and GNOME. As it’s impossible to help every cool free software project I ever come across, so I pick the ones that I use every day (F-Spot, Banshee, Totem). Projects I depend on include Inkscape and Blender, but the communities around those projects are very healthy and until recently I didn’t focus on helping there much, even though I felt I ought to. But then I saw custom icon themes support coming and created a Tango styled set of icons for Blender.
At Novell I’ve been responsible for the visual side of our SLED10 product and recently the openSUSE 10.2 branding (excluding icons). I’m also member of the Product Design team responsible for functional design of things like the Beagle search tool and the main menu (SLAB) to pick a few.
I’ve also turned a father recently, which takes up more time that I have imagined. I used to get a lot done during the weekends, which is almost impossible now. On the other hand I’ve learned some useful skills 🙂
Andreas Nilsson (further as A.N.): My name is Andreas Nilsson and I’m a 24 year old dude who lives in Gothenburg, Sweden. My first involvement free software project was when I did some images for a little GNOME applet called glunarclock written by a friend of mine, Debian developer G?ran Weinholt during high school. Since then I have been working on Freecraft, Open Clipart project, Inkscape and a couple of other projects.
I’m currently making icons for the GNOME desktop, Scribus, Jokosher and a couple of commissions for some clients that is not yet announced.
There were quite a lot of complains that GNOME HIG color palette was dull and lifeless. You now seem to have successfully solved this with basic tango color palette. Do you think that HIG palette will be changed in the future?
J.S.: Dull for some, elegant for others. I consider the old GNOME palette very appealing and something pleasant to look at every day for years. However, the goal of the Tango project was to ‘fit in’ with the rest of the world. And since everybody is steering towards saturated and vibrant colors we had to do the same.
An important aspect of the Tango palette is that we keep things simple. It’s only the very basic colors we wanted to define. It’s not hard to mix colors or shift lightness to get highlights and shadows. The palette is a starting point, not something you have to index your images to.
Having HIG updated (in many areas) would be desirable. Some ‘use tango’ patches for many places are due, indeed.
How does the process of designing and polishing an icon look like for you? What tools do you use?
J.S.: In the very rare occasion when I design an icon from the ground up, I start with a paper & pencil sketch. Even if you aren’t completely confident with drawing, a quick sketch will tell you whether a metaphor will work or not. If you cannot easily tell from a pencil sketch, you rarely can make up for it digitally. Then comes up the vector editor and a lot of iteration to have the shapes look natural and smooth while keeping the icon look crisp by aligning to the pixel grid of the target resolution (more about this later). Then depending on the shape and complexity I either use the same vector artwork for the smaller resolutions, getting rid of detail, aligning to the grid or render the artwork into a bitmap and fix it up GIMP. Most of the tango artists use a vector editor all the way. I guess I’m old (-school).
A.N.: I usually sketch stuff on paper first, trying out different ideas and compositions. When I’m happy with a design I start drawing it in Inkscape, often starting with a smaller size, like 22×22, so I won’t get lost in details and don’t don’t something that is to detailed and will just look messy in 16×16. In order to make sure all lines get sharp, I often export the SVG to PNG and edit it in GIMP. During the process I bounce the work back and forth with my client (when doing work for hire) or with the other artists in #tango on IRC.
What old and new features in Inkscape and GIMP (or other tools) do you find most useful for icon design?
J.S.: I love when a tool allows me to keep my focus on the canvas. Inkscape has a nice selection tool allowing to select overlaid objects, even if they are part of a group. Right on canvas, no mouse movement marathon happening. Nice and precise keyboard control for object transformation and node editing.
I’ve been using GIMP for icon work for the past 6 years. So even if all I do is pixel paint with a semi-opaque brush all the time, it’s just a natural tool to me now. I can lower the opacity of a brush, change brushes with a mouse wheel and a modifier key. One hand on the keyboard, the other on the mouse and the eyes on canvas. Nothing fancy, just damn efficient. A 1:1 view on my LCD screen, the zoomed view on the CRT screen makes it both precise to draw while providing an overview of how the things look in the end. Drawing 16×16 pixel icons is a bit of a guess work. You click somewhere to check if the illusion of creating a detail works on the 1:1 view. A single pixel is sometimes all you need to change to get a certain detail right.
A.N.: I don’t think it’s the number of features that makes a application great, but the fact that it’s well designed and gets the job done without to much crap in the way. But if I get to name the one feature I find most useful in Inkscape I must say it was when they added the px unit a couple of versions back. Being able to produce sharp outcomes is crucial to me. I also find the palette at the bottom and the gradient-on-canvas tool quite nice.
It’s not a big surprise that desktop art for UNIX is still created using proprietary applications in some cases. If you did a switch from proprietary applications (which ones) to open source applications for design, what made you do it after all?
J.S.: With GIMP, sometime during 1998/99, it was simply not being able to afford an Adobe Photoshop license. I’ve been exposed to the magic of Photoshop at the university of Huddersfield and I wanted to find an alternative editor to create artwork for the hip thing called WWW site. I’m very happy that Adobe chose to charge so much as the search for alternatives drove me to Linux as GIMP didn’t run on the Windows platform. I learned about the free software movement and enjoyed the freedoms, mostly to run my applications on a platform I choose. And web development was so much easier on Linux that time (well I bet it still is).
I have waited a long time to be able to replace my Illustrator 9 copy with free software. Sketch, Sodipodi were projects I have followed with hope, but ultimately it was the Inkscape folks that created an artist-centered illustration package. Inkscape has an incredible feature set that make it a brilliant generic illustration package. I still lack being able to node edit multiple objects and do perspective transforms for my icons, but overall it does what I need.
The big ‘downside’ with free software tools is that there is a huge temptation to run the bleeding edge versions of software. You can run the latest bells and whistles the developers are working on. A wise person would not consider driving a prototype car to work every day, which is sadly what I’ve been doing for the past few years.
People expect the release to be stable, but that can hardly happen if there are no ‘beta’ testers. So being a test-sheep is part of my contribution to some free software projects too.
A.N.: I started out with digital graphics when I was fourteen and used Paint Shop Pro, as it was bundled with some computer magazine I read at the time and was using that for about 6-7 years or something. At design school we were trained in the Adobe Suite (Photoshop, Illustrator & InDesign). These days I use a combination of GIMP, Inkscape and Scribus and the biggest difference between those and the Adobe Suite is that Adobes applications works better together with each other and behave similar and is therefore easier to learn.
The thing that made me switch is partly because I couldn’t use those on my Linux-only computer and partly because I don’t like using non-free software. I’ve always been interested in trying out new, cool stuff with computers, so GNU/Linux looked like a nice thing to try out. However I did have a dual-boot system for a long time.
Do you think something particular could be done to make GIMP, Inkscape and Scribus be better integrated?
A.N.: Several things. One is using the same icons — an issue that I’ve been working on with the Art Libre Set. Another would be similar ways of dealing with layers. Jon Cruz told me that it wasn’t by accident that the layers window in Inkscape behaved similar to the one in GIMP. It would be great if Scribus developers did the same, unless they find it counter-productive. But it would make it easier to learn tools. The layers dialog is just a small example. For Scribus, having the Node tool behave similar as in Inkscape would benefit learning the interface a lot too. From what I know they plan to address this issue after porting to Qt4. Another cool thing with the Adobe suite is that it’s a charm importing the different formats into the different apps, like inserting Illustrator files in InDesign, Photoshop files in Illustrator etc. And as I understood, the devs of Inkscape, Scribus and GIMP are making similar efforts, and doing a fine job at it.
How did you come to idea of Tango Fridays and how far are you ready to go with it (non-GNOME applications)? How exactly do you redo “fuzzy” icons?*
A.N.: We figured we needed some day where we could devote a whole day to get together, chat to new contributors and stuff like that as we’re all pretty busy during the rest of the week and Friday sounded like a nice day. The fuzzy icon issue is about using a icon for a resolution it’s not intended for, like only having a 48×48 image, where the menu for example demands a 16×16 icon.
J.S.: Keeping people motivated all the time, especially when most of us are volunteers, is hard. Tango Friday is a semi-regular event where we hang out on IRC and ‘hack’ on icons for various free software projects. Obviously we follow the “guidelines
Fixing up fuzzy icons is nicely demonstrated in this small cookbook demo, taken directly from the style guidelines. Alternatively you scale down the artwork in Inkscape with the stroke width unaffected by the transformation, take out all the tiny details, turn on the grid and make sure the lines snap nicely to it. No artistic skill required whatsoever.
Jakub, in your recent blog entry you were talking about vector and bitmap icons again. While you say that using vector icons as is makes sense for high resolution displays only, SVG files are still provided in many icons themes (including Tango and Tango based icon themes). What could they be used for?
J.S.: Having icons assets created in vectors has many advantages to the individual artist or artist community. Vectors are much easier to modify, create derivative icons and reuse for other purposes such as printed brochures, splash screens and other marketing/promotional work.
Some people think that they also help in that they are resolution independent and a single artwork can be rendered to any size. It’s a very tempting prospect, but similar to fonts it’s problematic at small resolutions. Vector fonts solved this by adding hinting information.
Instead of creating multiple bitmap fonts, an artist designs how a curve should deform at certain resolution to provide readable and crisp bitmap. Projects like freetype managed to implement something called auto-hinting that manages to deform the curves to align to the grid automatically, without requiring the font author to design such hints.
Combined with anti-aliasing this solution gives good-enough results. I’m not aware of any similar technology for generic vector artwork though.
Even if vectors are good for high resolution, it doesn’t mean it’s more efficient to render the icons form the vector source at runtime. Some argue that the artwork is so complex that it’s both more CPU intensive and requires more memory/file space to handle than bitmaps.
A.N.: It’s not pixel-vs-vector, it’s about using pixels where it makes sense and vectors where it makes sense. The nice things about vectors is that you can blow them up as big as you feel like without getting big squares on the screen, but in a lot of cases I don’t need to blow the icon up, but I need them small and crisp in a way I can only get them with a bitmap editor (and remember that we are using pixel monitors, not vector monitors). Don’t use SVG because it’s cool, use it where it’s needed.
Sometimes, when technologies make another shift, it’s difficult to find a proper sign for an action. It’s the same problem for new notions. For actions the best example, IMO, would be a much controversial icon for “Save” button (which used to show a floppy disc before). How do you handle cases, when something new has no existing widely recognizable sign yet?
J.S.: The key thing here is that the icon should help the user to navigate in the interface, help to understand or find certain functionality faster compared to having a simple text label. There are indeed cases where an generally acceptable and obvious metaphor doesn’t exist. Many developers don’t take no for an answer, but sometimes it really is better to have no icon at all than a non-obvious one. The mac can live without menu and button icons and is believed to be closest to an ideal of a well designed usable desktop.
Inkscape is an excellent example of icons losing their primary function. Pretty much every single item in Inkscape’s menus includes an icon. Regardless of how often used function a particular item is, or whether it’s a unique in shape and communicates the functionality well, the menu is overpopulated by pretty colored pixels.
I do love creating icons for their visual appeal. They are tiny artworks. But people’s desktops is not a gallery showroom, a medium for artists, they are people’s work tool. Icons should be primarily usable.
Good icon design is about not losing the essence while stripping as much as possible. Every large project requires compromise to be made, and there are many forces playing against good icon design. Product marketing wants icons to carry branding, almost everybody wants their application to look ‘spiffy’. That’s why you get OpenOffice module icons have all a poor silhouette to make them appear coming form the same ‘family’. The branding defeats usability.
Similarly, some metaphors become recognizable for some audience simply by familiarity. As you mentioned, people aren’t using floppy disks anymore, but the ‘save’ action is still the most widely used metaphor. The case with the save icon you mention is controversial because it’s hard to tell whether the familiarity with existing icon should take precedence over a new metaphor.
The decision has been made to go with a more future proof solution for the save icons as there are actual young users that never used a floppy in their life. We think the time has come to let the floppies rot in time. But that doesn’t mean we want to turn our back to the legacy metaphors in all cases.
A.N.: Good metaphors are hard. You have to consider what your target audience will expect and what they will be familiar with. If you’re making a application for photographers, you need to use concepts and metaphors familiar to photographers, hence the strong use of dark-room metaphors in GIMP for example. I think it’s important to be brave where you can when designing interfaces and remember that the interfaces that made sense when designing the Xerox Star might not make sense today.
Some people believe that a true masterpiece can be a work of a single person only. Do you think there really is a problem like collective creative work vs. creative work of a single artist, especially when in Tango project icons are sometimes/often finished by not its original designers?
J.S.: Tango project doesn’t really aim to create a masterpiece. It’s all about getting a consistent user experience with the least amount of work.
There are many great icon styles out there. What many developers and users don’t seem to care much about, but makes an artistically inclined person shudder is visual consistency. You may like vanilla ice cream and love hot dogs, but eating them combined will raise some eyebrows (and possibly test your gag reflex). What does it matter that you have a brilliantly executed Gorilla styled icon when everything else is following different style. That screams ‘unpolished product’ to me.
With GNOME we kept things consistent by essentially only working on icons in a two man team, keeping everything centralized in the gnome-icon-theme module. There is a better way to achieve consistency though — to provide a style guide, a cook book, so that other artists can create their own artwork that looks consistent. I think this worked much better. It’s better if a project can take care of its own artwork rather than relying on somebody else to fulfill their needs. It also solves the problem with 3rd party developers/ISVs. It’s much more sane to provide a gudeline to ISVs to handle the artwork themselves than living a fake dream that we’ll have enough resources to theme every app in the world. It’s a similar situation to getting applications work together/interoperate by either writing them all yourself (Adobe Creative Suite) or by defining open standards and formats (WWW).
After being confronted with hacker-made XPM artwork in the past I had my doubts about losing up the control, but in fact it turned out defining the style explicitly and opening up the artwork ‘development’ a much better way to achieve consistency. We have a lot of very capable artists contributing artwork to plenitude of free software projects. This has been a huge win for us and I’d like to thank all the great contributors.
A.N.: I think that it’s important to draw the line between interfaces and art. What we are doing is not paintings that are going to be hung in galleries, but parts of interfaces that are going to be used by people for getting work done, just like any slider, dropdown menu or pushbutton. Therefore, I don’t really see the problem of several people working on a single icon, if I start something and later on someone else does something to make that better (like changing color, fixing the shape or something similar) it’s a good thing. I think it’s the same thing with fonts: Deja Vu for example are worked on by a whole bunch of people, even though traditionally typefaces have been the work of one author.
You already mentioned Art Libre Set icons subproject. When you started it, you were taking into consideration a typical bitmap editor, vector editor and a non-linear video editing application. Now that Andreas has already contributed to both Scribus and Jokosher, are you going to extend the set to a “typical” desktop publishing application and a multitrack recorder? 🙂 Any other additions to be expected in this subproject? How exactly will this set be distributed and reused in applications?
J.S.: The drive behind the art-libre project was to a) define common metaphors for tools that did essentially the same thing and b) create a common library to reduce redundancy. I bet you have seen projects that aim too high and lose steam on the way, never getting anywhere. Even though I still think it’s a good thing to keep the idea alive, it’s going to be easier to focus on the first part initially. Even if the artwork isn’t re-used at runtime, it’s still reusable in terms of graphical assets (most of the time, granted the licenses are compatible). It turned out providing individual projects with artwork has a lot less friction than trying to make all the developers build lots of code to share a common art library. It’s still a worthwhile goal to get even to point b), but we don’t want to live in a vacuum in the meantime.
A.N.: The idea of Art Libre Set came up because if you look at GIMP, Inkscape and Scribus, you see that a lot of tools are similar and use similar icons (like the gradient tool, or pen-tool), so instead for them to install those icons 3-4 times, the applications could share them (and that makes my job quite a bit easier, as I only need to keep track of one, instead of four icons). It would be cool if more applications could share resources in a similar way, so having Pitivi, Diva and Jokosher share a similar library would certainly be possible. Myself, Edward (the Pitivi maintainer) and Jono (the Jokosher maintainer) has been meaning to discuss this, but haven’t found the time yet.
*What other subprojects are going to tango on the desktop floor? :)*
J.S.: Apart from the app icons you see are being done during the Tango Fridays, a lot of work goes into fixing up OpenOffice. Just like GIMP or Scribus, OpenOffice is a multi-platform application that will benefit from a tango-style stock. GNOME is also getting a Tango face-lift.
A.N.: I’m currently working on application-specific icons for some projects and trying to finish up A-L-S, but who knows what’s coming up. Like you said, I redesigned some icons in Scribus.
But I’ve been working on Tango icon theme for Inkscape for quite a while:
What happened to releases of the icon theme? The last one was uploaded this summer.
J.S.: There hasn’t been much happening on the tango base theme for a while now. The thing to understand is that the base theme isn’t as important as people seem to think. Tango project is not about providing an icon theme that will cover every action and status icon on the desktop. Tango project is about providing a style for developers to make their application look ‘native’ on the Linux desktop.
GIMP, Scribus, OpenOffice.org, GNOME are projects that have their icon follow the style guideline currently. Having GTK+ stock updated would be something I’d love to see happening soon too.
Tango base has been a great testbed to see if the goals we laid out in terms of ‘visual-interoperability’ would actually work. But the important thing which is happening now is that application developers follow the guidelines for their projects.
Do you contact to designers of other icon themes, especially Oxygen?
A.N.: Yes, I usually hang out in #kde-artists on irc.freenode.net and chat with the Oxygen-dudes from time to time, although I haven’t met any of them in person yet, as we haven’t been able to make it to the same conferences, although I hope David, Ken or Nuno can make it to the next Libre Graphics Meeting.
J.S.: I do know some of the people in the Oxygen project. Kenneth Wimer, who worked in Novell with us, was in fact one of the founding members of the Tango (Unify back then) project. David Vignoni is an excellent artist following the footsteps of another great KDE pixelpusher, Everaldo Coelho. Both of which I’ve only been able to get in touch by electronic means, but are excellent and inspiring artists. The goals of the projects differ, but there is common ground in the area of naming and metaphors. Meeting in person always helps, so getting together somewhere like the Libre Graphics 2007 would be great.
Do you think that cooperation on any level is possible?
J.S.: The Oxygen guys seemed rather positive about cooperation on the naming spec and defining the common metaphors, but nothing concrete has happened there yet. On one hand it’s sad to see fragmentation of people resources, but it’s idealistic to think that if people stopped hacking, say, on Krita, GIMP would move forward faster. Oxygen people don’t have the same goals and don’t aim to fix the problems we think are hurting the Free desktop. Their goal is to make a spiffy new KDE icon theme. They see a unique look is a good attribute of an icon theme that separates and defines them from the rest. They don’t seem to consider that users tend to run applications coming from various projects and the resulting style mish-mash a problem.
We took a look at this from the 3rd party developer perspective and figured out it’s not a good thing to suggest they ship two different sets of artwork. Defining a common style that works in both environments seems to be least work. And being lazy ourselves we knew it will benefit them when the same stock looks decent on Windows and Mac OS.
One of the reasons we started talking about finding common ground way back at the NY GNOME summit, was duplication of work and not being able to reuse common assets. Garrett LeSage, a graphic artist working for Redhat at that time and Tuomas & Me were looking at possibilities to create artwork synergies similar to what happens with free code. Both Redhat and Novell are developing their own products, but they benefit from sharing most of their work in upstream codebase. No such thing was happening for icon artwork sadly. Companies are tempted to jump in and think about icons as a mean to brand their product, but really never getting to do it properly, for every single application they ship. It’s a tanatalous task. Not even Microsoft is doing a good job here. In XP you see a combination of XP, 95 down to gems from 3.0 icon styles. Another style change for Vista ain’t help in that department either. Unless you want to do crazy amounts of work yourself it’s smart to work upstream as much as possible. Following the Tango guidelines doesn’t mean giving up the possibility to brand the most exposed icons on the desktop. Having custom icon artwork while following the guidelines can make both marketing and art director happy. In fact that’s what we do at Novell as well with our Industrial desktop icon theme. And even when you don’t do the right thing, going with a style that’s not utterly unique is a good choice. This happened with the new Human theme in Ubuntu where they can still benefit from large amounts of upstream artwork.
I looked at the recent development of the Oxygen style and it’s steering a bit away from the styles we considered in our ‘style pool’ to fit in. They use a lot of black and generally design for higher resolutions. We’ll see if changes to the style will be required to make Tango styled apps look decent under KDE4+.
Talking about “Save” icon and such… If someone thinks he could improve or help improving existing icons, what is the best way to do it? Fork? Discuss? Contribute?
A.N.: Discuss and Contribute. Nothing is set in stone! Although I feel I must mention that there are a lot of unfinished interfaces out there, so making the save icon better is perhaps not the most urgent thing right now.
J.S.: Creating derivative themes out of Tango base is definitely something positive. What matters is following the style guidelines so that users don’t have to suffer visual inconsistency. But if you meant creating your own metaphors for things you disagree with what we proposed in the naming spec, I think it’s the least good option.
Debating over the metaphors is something that needs to happen. Like with every project there is a risk of vocal minorities flaming away endlessly, but definitely having key people form KDE, OpenOffice, Abiword, etc. discussing the naming and metaphors is important to actually having the applications follow the naming and not keeping the old style separate ways forever. Either the xdg mailing list is or tango-artists is appropriate for such discussion. The naming spec is still work in progress, we appreciate contributions in this area.
About the author
Alexandre Prokoudine is a technical writer from Russia who works at pushing standards and I18N/ngettext to open source audio and graphics software development. When he’s not translating open source audio or graphic tools into Russian (including applications such as Audacity, Rosegarden, Hydrogen, Inkscape, Hugin, and Scribus), he helps with testing unstable code, improving interfaces and writing docs.
In this article John D. Ramsdell describes cross-platform GTK+ application development from a newcomer’s perspective.
In an effort to sharpen my programming skills, I wrote a game using a GUI framework with which I was not previously familiar and ported it to several platforms. The framework selected was The GIMP Toolkit, and the application was a puzzle solving game called GTK Sudoku. In this article, I will describe the path that I took to make use of this fine toolkit.
GUI Framework Criterion
I used four criteria for selecting a GUI framework: (1) The framework had to support cross-platform development. (2) The framework had to be one that I had never used, otherwise I feared that I wouldn’t learn as much. This eliminated FLTK and wxWidgets. (3) For my tastes, C is preferred over C++. (4) I wanted GTK Sudoku to be scalable in the sense that the size of the default font, not the resolution of the display, determines the size of each window and widget. The Cairo vector graphics library was of great help to meet this criterion.
A Sudoku logic puzzle is solved by filling each cell in a board so that every row, column, and 3×3 square contains the digits one through nine. GTK Sudoku eliminates much of the drudgery of solving a puzzle and provides educational tips should the path to the solution be obscure. It is different from most other programs in this category because users specify the rule that justifies each change to the Sudoku board. The program will fail to apply a rule if its preconditions are not met, thus detecting mistakes early.
Lua, GTK+, Import/Export…Oh my!
Before I list the lessons learned from this project, let me set the context. GTK Sudoku was constructed by wrapping a GUI around a formerly text-based application written as a Lua script. Lua is a lightweight and easily embeddable scripting language that is popular with game developers. The Lua interpreter is also available as a stand-alone program, and users can interact with scripts using a read-eval-print loop. I’ve been using and tinkering with my Lua Sudoku script for over a year, but there aren’t too many other people who are willing to type Lua function calls into a command-line interpreter for each game interaction. The addition of a GUI was required if I wanted to share my spin on this popular game.
Embedding the Lua script was quick and easy. It was naturally encapsulated in a C module that exports four functions and imports three. The major change to the Lua script was the addition of a help system, which was unnecessary when I was the only user.
The only tricky section of the GUI was the part that displays the board. A Sudoku board is a 9×9 array of cells grouped into 3×3 squares. The preferred way of presenting a board is to draw a line on each edge of each cell and then draw the boundaries of the 3×3 squares with thicker lines to distinguish them from the other cell boundaries.
The board is implemented as a widget that extends a GtkTable, and provides a 9×9 table of cells. Each cell is a widget that extends a GtkDrawingArea. The board widget ensures that there is no space between the cell widgets and that each cell has the same size. Cairo is used to make each cell dynamically resizable and to draw the boundary lines. The boundary lines of each cell depend on the position. Several alternatives had to be explored before this solution was found.
The first major challenge was finding documentation on versions of GTK+ that include Cairo. There were three steps that resolved this issue. First, I found and carefully studied Davyd Madeley’s article on writing widgets using Cairo. Next, I bookmarked and frequently referred to the HTML documents in /usr/share/gtk-doc/html on my GNU/Linux development machine. Finally, the key step was to expand the three source tarballs that make up GTK+ and create an Emacs TAGS file for all the C source and header files. I found the sources extremely helpful, and they adhere to a consistent style, which aids navigating them.
Porting GTK Sudoku
GTK Sudoku is built using the GNU Build Tools (also known as Autotools). Almost all that you have to do to make your system aware of GTK+ is add the following to your configure.ac file
AM_PATH_GTK_2_0(2.8.0,, [AC_MSG_ERROR([Cannot find GTK+])])
and also add
to your Makefile.am.
The use of the GNU Build Tools made it trivial to move GTK Sudoku to different GNU/Linux distributions, including one that runs on an Intel Mac. On the Mac I installed the version of X11 that came with the machine and used DarwinPorts to install GTK2. GTK Sudoku then builds as it does on GNU/Linux. Writing one’s own portfile is also quite easy. In addition to filling in the required fields one only need add:
Porting GTK Sudoku to Windows was challenging. Creating a GTK+ development environment on top of MinGW and MSYS is quite different than doing so for the other GUI frameworks that I have used. For example, with FLTK one can download the sources and easily build and install the framework. Being able to build from the sources allows you to statically link your application, easing deployment. In constrast, GTK+ depends on a number of packages that are not part of the standard MinGW or MSYS runtime environment. Assembling a development environment from precompiled binaries is painful enough to cause one to avoid using the sources. Additionally, there are technical reasons that make it very difficult to build an environment that allows static linking of GTK+ applications. As a result many developers simply download the collection of archives made available by Tor Lillqvist. This distribution is of great use to newcomers, and is something that I am thankful for. There are, however, difficulties to be overcome when using this distribution.
When moving to Windows, it is more difficult to port a GTK+ application than it is to port an FLTK or wxWindows application. If you follow the recommendations in the FLTK and wxWidgets documentation, your build system will work unmodified on all systems, including MSYS. On MSYS the link command requires the -mwindows option, which is added by the GUI framework’s configure script; however, the GTK+ configure script omits the -mwindows option on MSYS. I dealt with this problem by simply adding the flag to my local copy of /usr/local/lib/pkgconfig/gdk-2.0.pc.
Packaging GTK Sudoku for Windows presented the greatest challenge. For Windows, there is an installer for GTK+ version 2.8.18, which places a collection of DLLs and support files in C:Program FilesCommon FilesGTK2.0. The current Windows development environment provides version 2.8.20. It turns out you can run a GTK Sudoku binary created with GTK+ 2.8.20 using a GTK+ 2.8.18 runtime if you add to your source file a definition of the function g_type_register_static_simple, a function added to GTK+ after version 2.8.18. What a hack, no?
The GTK Sudoku Windows installer is close to the LuaForge 10MB limit in file size. This is because I had to include all the files in the GTK+ 2.8.18 installer into the GTK Sudoku installer. If you install GTK+ 2.8.18 into the Common File area, some other GTK applications, for example Gaim, stop working.
Once you place the runtime in your installer you can change its components. Tor Lillqvist tells me that the better solution to my runtime linking problem would have been to update its version of GLib to 2.12.
In summary I was very impressed with GTK+ and especially with Cairo; however, porting the GTK+ application to Windows proved challenging, but not insurmountable. It just takes perseverance.
In the past two years, GNOME and the GTK+ projects have inspired many enterprising hackers to start companies and risk investing capital into a market that surprisingly has shown to be robust, providing not only adequate funding for these companies but room enough to expand operations. Sri will discuss where Fluendo has been and where they are going.
In the past two years, GNOME and the GTK+ projects have inspired many enterprising hackers to start companies and risk investing capital into a market that surprisingly has shown to be robust. This market has shown to provide not only adequate funding for these companies, but room enough to expand operations.
I want to find out how successful these companies are and to really discover if there is a market out there for GNOME and free software desktops in general. I will be profiling various companies who have shown an affiliation with the GNOME free desktop and it’s underlying components in a series of interviews over the next couple issues.
I had the honor of attending GUADEC 2006 at Villanova, Spain, the main GNOME developer conference. I was able to take advantage of the fact that I would be able to meet many of the people who started these companies in person.
I met Thomas Vander Stichele at GUADEC, and was able to sit down with him for a brief chat about his company Fluendo. Thomas, an unassuming hacker with a relaxed air about him had plenty to say about Fluendo, which he started with Julien Moutte and Pascal Pegaz three years ago. Thomas, Julien, and Pascal had envisioned to start a company around the popular GStreamer. GStreamer is the common audio and video infrastructure that is in use today by the major free software desktops KDE, GNOME and others. The idea is to be able to have a small core multimedia system with the ability to extend multimedia capabilities with plugins. GStreamer is quickly becoming the standard multimedia subsystem everywhere.
Fluendo started with building a business model around a streaming server product called Flumotion. Flumotion is a highly scalable multimedia streaming server capable of streaming to hundreds of clients. This makes it an invaluable tool for those who wish to view videos from remote. The initial idea was to allow two to three years to let the technology mature before releasing as a product. In addition, Fluendo planned to do some consultancy on GStreamer on the side.
Thomas was candid that he didn’t think the consultancy would have gone anywhere. Much to his surprise, the consultancy actually was successful with business relationships formed with BBC, Nokia and Intel amongst others. Fluendo received a lot more success than it anticipated.
Fluendo currently has three different strategies. Consultancy on GStreamer along with developing and selling codecs for multimedia hardware, a streaming server using clustering hardware, and finally the Elisa project, a free software DVR project similar to MythTV.
One of the more controversial things that Fluendo is working on is enabling distributions to legally play music and video with legal codecs. Fluendo plans on talking with ISVs and Linux distributors about the distribution of codecs, like MP3, in a legal manner. The hope for this plan is that regular users will be able to play protected media content if they so desire. Fluendo has recently allowed users to buy these codecs at http://shop.fluendo.com/.
That said, Thomas is careful to note that he cares about the free solution. Fluendo funds the Xiph.Org Foundation to pursue free multimedia solutions unencumbered by DRM and patents like Theora for video and RTP for VOIP. Fluendo’s streaming server works with free codecs out of the box without additional codecs. Thomas thinks that this is what you need to do in order to enjoy community support.
For Thomas, the biggest concern is that Fluendo has a good standing with the Free and Open Source community and hopes that conflicts with work on DRM and proprietary codecs will be balanced by strong advocacy for the open multimedia solution.
Today, Fluendo seems to have filled a needed gap for companies who need to stay legal, want to use proprietary codecs, and are in need of a good extensible multimedia infrastructure. Fluendo has gained the attention of big corporations like Intel and Nokia and are working with them to improve the multimedia support for Linux as well. Fluendo is one of many Linux desktop technology companies that is creating a new market and succeeding in it.
We need you! That’s right…you! Come read why we need your help here at the GNOME Journal and what we need help with. The editor, Jim Hodapp, is back with a vengeance.
Welcome back. It’s been quite a while since I’ve been able to write anything for the GNOME Journal, but fear not, for I have returned. The GNOME Journal has been on a rough ride lately due to a lack of people with enough time to give the attention and loving care that a volunteer project like the GNOME Journal needs. And so, this reality gave me the topic for this issue.
The GNOME Journal Needs You!
Let me begin by reminding you that the GNOME Journal is brought to you completely by volunteers. Nobody receives any compensation in any form besides the satisfaction of a job well done. With that in mind, let me be forthcoming with you. We need you; we need you badly. Now, let me explain. We do receive articles from people who are passionate about a certain topic, and took the initiative to write an article and submit it to our mailing list. We greatly appreciate these volunteers, and really, without them we would barely have more than an article or two per issue.
But all of the regular volunteers have a vision for this magazine which celebrates GNOME. That vision is to make it a central source for original and high quality articles about GNOME that naturally lend themselves to marketing GNOME well. It is a place for people to be inspired by the altruism of the community, the dedication to excellence, and the pursuit of helping create something that is bigger than the individual contributors to each project. We have not, and still are not, been able to completely enact this vision yet because of a lack of regular volunteer writers. We have a number of people who are good at editing and helping polish the articles for publishing; but what we lack
If you enjoy writing even a little bit, or you don’t know if you like writing but are willing to give it a try, then we need you! Let me spell out what you need to do, if my call to action spurred you on at all:
- Pick something in the GNOME community that you’re passionate about or would like to learn more about
- If you need to learn about a topic first, then do the needed research and hands-on experimentation
- Start writing. If you need help with ideas for sections of your article, ask on the mailing list. If English is your second language and you need help with how to say something, again ask on the mailing list. If you can find someone who can translate your article from your native language to English then please feel free to write in your native language first.
- Let the project leaders know about your article by submitting a text version of it using the textile markup language that is used by the TextPattern content management system.
- Work out the details on the mailing list with someone to make sure that your article is edited and ready for publishing in an upcoming issue. To see when a new release is planned and the article submission deadline, refer to the following wiki page.
I realize that to some of you, the thought of committing to writing a regular article for each release of the GNOME Journal sounds like a large task. Let me motivate you by submitting to you that it’s a very rewarding experience. Not only do you get to write about something that you love, but you also get published in a very widely read publication. It can also be a useful experience for showing on your resume to show that you have communication skills, leadership and initiative skills through volunteering; and also it shows that you are organized since you can find the time to regularly write an article on a volunteer basis. All of these are traits that I know a lot of employers look for in potential new employees.
By no means must you make an immediate commitment. Please feel free to write an article or two as a trial and if you don’t like it, or want a smaller commitment then by all means let us know. But don’t let the fear of a commitment stand in your way. I call all of you writers and potential writers to action. Take hold of this opportunity to make an impact on the open source community and ultimately the world by becoming a volunteer writer for the GNOME Journal.
Please send me an email with your thoughts if you would like to discuss this with me.