Category Archives: June 2010

Interview with Quim Gil of the GNOME Advisory Board

Stormy Peters continues her series of interviews with GNOME Foundation Advisory Board Members, interviewing Quim Gil of Nokia.

Nokia is credited with starting an ecosystem of companies around GNOME and other free software technologies. How did that happen?

The Maemo project pioneered introducing a set of free desktop technologies in a commercial mobile product. At the time many of the experts of those technologies were either hobbyists or professionals in other areas that couldn’t suspect that a company like Nokia was interested in their work. The first contacts proceeded. Some of them became Nokia employees and moved to Finland, some of them were encouraged to create their own companies and work for Nokia. Thanks to this combined approach Nokia got the expertise in house and at the same time an ecosystem of new small and mostly European companies flourished around the GNOME project.

How did Nokia first start using GNOME technologies?

GTK+ was chosen as base toolkit to develop the Maemo UI. The main reason to choose this technology was the permissive LGPL licensing model common to the rest of the GNOME project and the decentralized setup of companies and individuals collaborating around the GTK+ development and other projects under the GNOME Foundation umbrella. At the time, this setup was clearly different than the setup around Qt, with a commercial & GPL dual licensing model and a development process in the hands of Trolltech. The choice of GTK+ brought almost as a cascade many of the other technological choices.

From a Nokia perspective, what do you think the GNOME Foundation is doing well?

The GNOME Foundation sustains the GNOME project as a neutral place of collaboration, which is a goal difficult to achieve and keep for years. Neutral in the sense that no single company has overall control, and also neutral in the sense that there is a good balance between commercial companies, public organizations, non-profits and a wide group of individuals.

What do you think the GNOME Foundation should be doing more of?

One could argue that the GNOME Foundation is ultimately responsible for the success of the GNOME project. There have been enormous developments and changes in the free software world and in the software industry in general, specially in the mobile context. Some GNOME Foundation members are quite active promoting these changes but if you go to gnome.org and you follow the public activity it feels like the project is not up to this speed. The feeling of long 2.x desktop-centric maintenance mode still prevails.

Maybe the GNOME Foundation should have a clear strategy on whether to jump on these new challenges shaking the industry or keep polishing the mission (basically fulfilled) of covering the functionality and user experience of the traditional computer desktops.

After the acquisition of Trolltech and transferring Hildon to the community, what is Nokia’s position about GNOME technologies?

This question still brings us to the old topic about what are GNOME technologies. Moving to a Qt centric platform with a Qt API style one could quickly conclude that Nokia has given the back to the GNOME project. However, looking at the MeeGo architecture it’s easy to see that there is a good collection of middleware technologies common to the GNOME Mobile architecture. Also, under the Qt style API there are many more components that strictly speaking belong to the freedesktop.org umbrella, but not coincidentally have their core developers and project dynamics quite aligned with the GNOME context.

This explanation doesn’t satisfy the average GNOME enthusiast, but note that our approach around Qt API and application framework + GNOME style middleware doesn’t satisfy the average KDE enthusiast either. One option is to keep this discussion in the 90s trying to place MeeGo in the GNOME-KDE axis. The option we push for, though, is to find the great aspects in each project and communities, to synthesize them in a leading free mobile platform.

Nokia has been moving away from GTK+ to Qt but recently gave $50,000 to the GNOME Foundation to help fund GTK+ applications on Maemo and MeeGo. Why did you do that?

When we announced last year the move to a Qt based UI and API, we mentioned that GTK+/Hildon could be supported by the community if there was enough interest. After some discussions with GTK+/Hildon maintainers and a BoF in the Maemo Summit, we decided to help the kick-off of that activity through a fund. The idea we had was to promote the porting or development of GTK+ based applications in Maemo 5 and a compatibility bridge to following releases.

This fund was discussed and overall agreed with the GNOME Foundation in the context of Maemo 5 and the Nokia N900, a mobile device with a GTK+ based UI that has received very good feedback. The outcome of this fund is yet to be seen. Nokia has made a big investment in Hildon and GTK+ in the past years, and even now when our team is entirely focused in Qt we have tried to find a reasonable transition path for the Maemo developer base. We hope this fund is useful for GNOME developers and indirectly for Maemo and MeeGo users.

What do you see as the GNOME community’s biggest challenge in the next few years?

Is the GNOME project in a trend of innovation or a trend of maintenance and optimization? GNOME is doing well as a desktop environment for deployments of traditional computers that need to just work, but what about all the innovation happening around the mobile and new computer platforms (the ones that MeeGo tries to address at once, for instance)? There you have Android/Chromium, iPhone and now MeeGo pushing for alternative stacks with UI and application frameworks.

Where is GNOME standing in such context and trends? This is a question common to KDE by the way, and to most of the Linux distributions GNOME has been relying upon to increase its user base.

How would you like to see Nokia and GNOME working together in the future?

It would be good to see GNOME taking an active role in the context of MeeGo, a project that combines upstream development with integration in order to deliver an innovative open platform..
The GNOME community has been pushing plenty of brilliant ideas and concepts that now exist as key pieces of software in the free desktop stack. There is an ongoing consolidation process to establish the main platforms of the next years. We believe MeeGo will be one of them: what other strong alternatives are there closer to GNOME?

How do you think your alliance with Intel through MeeGo will affect how you work with free software communities?

Nokia and Intel are often mentioned as good examples of companies collaborating with free software upstream projects, and the MeeGo context should only improve that.

The alliance between Nokia and Intel includes also The Linux Foundation. The goal is to deliver a top class free operating system for the mobile and computer industries. The approach to achieve this is to run an open project combining the usual free software processes with professional software development. Currently deliveries still go over openness but transparency and community involvement will take its prominent place soon. All this will be much clearer in few months, after the first release comes and the list of companies involved and contributing increases.

About the Author

Stormy Peters is the Executive Director of the GNOME Foundation, co-founder and President of Kids on Computers and dedicated to making the world a better place through free and open source software.

Discuss this story with other readers on the GNOME forums.

Advertisements

PHP-GTK, Widgets & Gadgets: An Interview With Elizabeth Smith

Sumana Harihareswara interviews Elizabeth Smith, maintainer of PHP-GTK, and discusses PHP-GTK and its future.

I recently chatted with Elizabeth Smith, maintainer of PHP-GTK. PHP-GTK is, as the website describes, “an extension for the PHP programming language that implements language bindings for GTK+. It provides an object-oriented interface to GTK+ classes and functions and greatly simplifies writing client-side cross-platform GUI applications.” Smith talked about the extension, its history and future, GTK in general, open source on Windows, and what you can do to help PHP-GTK.

Smith started off by describing PHP-GTK and how she got into it:

PHP-GTK is generally best suited for situations when you already have a lot of developers (or a lot of logic) already tied up in PHP. It makes it easy to whip up a desktop interface to that business logic without the need to expose that logic via a service or learn a new language. Personally, I got involved in PHP-GTK just to learn desktop programming. I didn’t want to learn a new paradigm (web to desktop) and a new language at the same time. I started PHP-GTK to learn desktop programming without learning a new language… and ended up learning C and being the PHP-GTK maintainer. Funny how that happens.

Can you give me a specific example of an app you’ve written or worked on that uses PHP-GTK?

If you want specific applications, I tend to do little more than play with PHP-GTK, since it isn’t my day job. However, there are quite a few people using it to write “real” applications. http://php-gtk.eu/en/apps is a community site for PHP-GTK and has quite a few open source applications written with PHP-GTK. One pretty amusing thing is a friend of mine has an OpenMoko phone. He ended up getting PHP-GTK running on his phone and wrote a couple more apps as well. But the only PHP-GTK code I write and use on a regular basis is my “demo application” – a basic Twitter client. The latest source for it is here in the zip file. I generally use it with my “PHP on the desktop” talk. I haven’t had as much time to devote to, well, anything as I’d like!

And Callicore?

That is my “framework” for applications. It was simply a way to wrap up some of the mundane details that I was using every time I got into a PHP-GTK programs: where to save user settings, saving and restoring window positions between applications opening and closing, and so on.

What GTK apps do you & other Windows users love?

Personally? I am addicted to Pidgin. It’s on every box. Inkscape is the other big one I use. Vector graphics are fun and make my life SO much easier, and really the only thing that comes close is some horribly expensive Adobe atrocity!

So, I do have to ask, since most of GNOME Journal’s readers are running GNOME on Linux—are you choosing to use Windows, or is it something rather forced upon you?

Initially it was forced; now it’s by choice. Really I use … lots… of operating systems but for a solid desktop I still use Windows. It’s just absolutely covered in open source software (OSS on Windows – the gateway drug). And, as I’m happy to tell most people: all operating systems (and languages for that matter) basically suck. It’s just a matter of what sucks least for the problem you’re trying to solve.

Is there some initial dependency one needs to install on Windows to make GTK apps work, or is it built in?

Well, I wouldn’t say it’s a “dependency” per se, but you do need to install the GTK libraries and their “stack.” On most Linux systems this comes all built in, since they’re already installed for GNOME (or often side by side with KDE). But it’s no different than, say, on a Mac. GTK is smart enough to speak Windows; you just have to get everything compiled and installed. It’s just about 13MB for all the GTK libraries, the PHP runtime, and the PHP-GTK extension on Windows. When I package PHP-GTK for Windows, it’s all in there. You literally unzip and run. (A small advantage of having a native Windows person as lead.)

So, I asked the #gnome-hackers channel on GNOME IRC for some questions for you. One question, from Rob McQueen: “are they aware of the gobject introspection work, and do they have any plans to rebase the bindings on top of that to access the whole GNOME platform?”

Actually – yes, we’re aware of the introspection work, and we’re working on a new “stack” that splits up PHP-GTK into more “pieces”—there are already glib and gobject components started doing that—however, because of the tight ties PHP uses, it’s not going to work to do runtime level introspection. Instead it will be tied into our code generation stuff. We have a real problem with the current introspection stuff though that I’d personally give my right eye to have fixed. We support lots and lots of GTK versions. We really really need version information available to us.

So other people who are interested in PHP & GTK should feel free to jump in and help fix that?

Sure. There is a running joke right now that if you come to freenode, join #php-gtk and mention “I want to help” you’re hired. Really, though, what we need is the “fun work.” PHP-GTK is fairly stable now and bugs are scarce, so we just need people willing to help write the next iteration. Because of the nature of GTK, PHP-GTK previously had all of its pieces tied up in one monolithic extension. Recently we’re been working on “splitting off” functionality, so there is now a Cairo PHP extension, which basically the PHP-GTK folks are taking care of. And pango, and, as I mentioned, a gobject and glib. So, we’re breaking out the pieces – to make it easier to maintain, make it easier to add new features (because all these GTK libraries are often released separately), and add additional GNOME-level library bindings. Well, they’re not really “GTK” libraries, they’re stuff on the GTK stack. But that means basically redoing almost all of PHP-GTK … and no one really likes a rewrite.

One person asked whether PHP-GTK is maintained.

Define “maintained.” There are three of us basically that still hack on the source. We have a release that’s currently been waiting for me to get enough time to get the Windows builds going so we can get a release done. If there are bugs, they are fixed (check the
bugtracker) – they always get priority. However, it’s new features that really suffer when the developer pool is that small. So it’s not abandoned, it’s just really slow development, a lot of which depends on my load at work (which has been far too high recently). Open source work for me is all after hours, while I’m folding laundry, etc.

Come join. I love new devs. No, we’re not dead, just short on manpower.

I’d like to hear about what you like & don’t like about GTK.

What I like? Cross-platform support, the fact that it’s written in C and so is very easy to stick in anything, lots of features, the general gobject design itself. What I hate? Not a lot of good Windows devs (regressions are the bane of my life), non-standard file and print dialogs, building the sucker with Visual Studio (owie), sometimes too many features. Take a look some time at the number of widgets available in GTK, plus all the deprecated stuff is still there… it’s just huge. Sometimes I think it would be smarter for some of the more advanced widgets to be broken off.

And that’s another thing that I think could be a great strength of GTK, but the community doesn’t seem to be there – additional widget libraries.

I liked having things like libsexy that gave nice new features—but they weren’t in the core if I didn’t need them! I guess what I’m trying to whine about is that I’d appreciate more modularity, and some kind of a community to then allow those who extend and enhance to have a place to “display their wares.” An app store for widgets? Heh!

When you want to find widgets, how do you currently find them? Are there any IRC channels, planets, mailing lists, or Usenet groups?

Right now it’s a Google nightmare. Either I see something cool in a search engine I want, or someone comes to PHP-GTK and says “this widget here, I would like wrapped.” Communities—not that I know of. Now, that just might be because I don’t know where the official place is, but that is not something where I’ve seen any coherence in the community.

So a little about you, now. It sounds like you do a lot of web programming?

I do a lot of… everything, but I started in web programming and that’s my “day job.” I’m in the US, in Michigan, in a tiny little town with lots of corn. I work remotely, which is nice because I”m juggling a full time job, four kids, plus as much open source work as I can do and not make my husband overly irritated.

I’m also involved in the PHPWomen user group, speak at conferences, and recently threw my hat into the CoApp project (Common Opensource Application Publishing Platform)—“apt-get for Windows,” in Linux speak! Windows needs it. Would help open source for the Windows platform in so many ways. I just got back from the design summit; we’re currently working on the API for the engine core. We need C devs who aren’t afraid of Windows, and those are hard to find.

Are any of your kids showing signs of turning into geeks?

Oh yes. Let’s just say my four year old gets up in the morning, logs on, and goes to nickjr.com without any intervention… And my oldest son wants to be an engineer and builds motion detectors out of snap circuits to keep his brothers out of his room!

So, one last question—your gadgets! What gadgets do you love right now?

I’m currently in love with my very strange setup in the basement: I have a very large server, running HyperV (2008 Windows hardware-based VM stuff), and I have so many versions of Unix and Linux on there it makes me chuckle. Nothing like booting FreeBSD on a Windows box to make you feel subversive.

About the Author

Sumana Harihareswara manages projects and people. She has worked at Collabora, Fog Creek Software, and Salon.com, and contributed to the AltLaw, Empathy, Miro, and Zeitgeist open source projects. She is currently an editor for GNOME Journal and a blogger at GeekFeminism. She blogs at Cogito, Ergo Sumana and microblogs at Identi.ca.

Discuss this story with other readers on the GNOME forums.

Time’s Making Changes – A Letter from the Editor

Paul Cutler writes his first Letter from the Editor.

I am honored and thankful to have been entrusted with GNOME Journal from our outgoing Editor in Chief, Jim Hodapp. Jim has done a wonderful job over the last six years in launching GNOME Journal and working with countless volunteers to produce almost 20 issues of GNOME Journal over that time.

In Jim’s very first Letter from the Editor way back in September of 2004, he launched GNOME Journal with its mission:

  • Fill a gap in the lack of original content centered around GNOME
  • Provide a centralized place for people wishing to learn more about GNOME and using a free software desktop who use a different operating system
  • Because it’s a cool idea

That mission is as true today as it was six years ago. GNOME Journal will always hold a special place for me as it was one of the areas I first became involved in volunteering within the GNOME community. It started with the little things – I helped the GNOME Journal team with editing, including the Annual Report which Lucas Rocha would ask the GNOME Journal team to help with. After GNOME Journal took some time off in 2008, a few of us spoke up about getting it back up and running, and last year I took on the role of release coordinator helping to get new issues organized, finding authors, writing articles and communicating with the team. Or as I like to think about it, herding cats.

As Jim said in his last Letter from the Editor about GNOME Journal: It is a testament to voluntary organization that we’ve produced original content about GNOME on a consistent basis. And that has been true over the last year.

In the last year we’ve accomplished a lot:

  • The first special edition with a theme focusing on Women in GNOME
  • Long time contributors like Jorge Castro write articles and new contributors write multiple articles, such as Jim Nelson and Jono Bacon
  • Stormy Peters, in addition to her day job as GNOME’s Executive Director has conducted multiple interviews for GNOME Journal, including an interview in this issue with Quim Gil who represents Nokia on the GNOME Advisory Board*We’ve welcomed new editors to the team including Scott Anderson and one of my favorite Linux journalists Joe “Zonker” Brockmeier, who also contributed an article
  • Last, but not least, Sumana Harihareswara has edited more articles than I can count and has also written for GNOME Journal

Sumana takes over my role as release coordinator for GNOME Journal, and I am thankful to have her on the team. In the short time I’ve known Sumana, I am continually amazed with her passion for writing, open source and the number of interests and hobbies she has.

Sumana and I, as well as the entire GNOME Journal team, plan to continue to publish GNOME Journal on a regular basis and in every issue we try to include articles for GNOME users, developers and at least one interview that’s relevant to GNOME. We also have ideas to build upon special issues dedicated to certain themes and have more surprises in store throughout the year.

I hope you enjoy this issuse as much as you’ve enjoyed past issues of GNOME Journal. I would love to hear your feedback about GNOME Journal, whether it’s this issue in particular, ideas you have about future issues or how to continue to improve GNOME Journal. You can email me at pcutler@gnome.org. And if you want to get involved, we’d love to have you – this was one of the first ways I became involved in free software and you can too.

Discuss this story with other readers on the GNOME forums.

Shotwell Photo Manager

Jim Nelson discusses the features of Shotwell, a new photo manager for the GNOME Desktop.

Introducing Shotwell: A GNOME Photo Manager

When I was in high school back in 1987, I took an introductory photography class. We worked in the darkroom, enlarging negatives onto developer paper and then moving the prints down an assembly line of baths filled with some of the harshest chemicals I’ve ever been exposed to.

Today, digital photography has all but eliminated this process. Film isn’t just cheap now, it’s virtually free, and reusable as well. An amateur photographer can snap thousands of photos a month without hesitation and share them worldwide with a click of a mouse button.

With large collections becoming the norm, the need to organize, edit, and share one’s photos has become a common task. That’s where Shotwell comes in.

Our intention from the beginning has been to write a photo manager stocked with the best features top-of-line commercial applications offered. We’ve looked hard at how other photo managers worked and weighed the benefits and costs of their features and design. Shotwell is the default photo manager in Redhat Fedora 13 and will be default in Ubuntu 10.10 shipping in October. Here’s where Shotwell stands today.

Non-destructive Editing

One philosophy we’ve taken to heart is that your photos are precious. Shotwell preserves the original photo no matter what transformations you perform on them—the only time it edits the original file is if you explicitly tell it to update the metadata (such as the time the photo was taken). Think of your photo files as old-style negatives. If you damage a negative in the process of perfecting a developed print, that’s the last print you can make. By preserving the negative, you can make new and different prints over and over. This is the heart of the thinking behind Shotwell’s non-destructive editing engine.

As you alter your photo in Shotwell—crop, color adjustments, rotate, and so forth—the changes are stored in an internal database. When you view a photo in Shotwell the adjustments are applied on-the-fly. This has three important benefits:

  • As mentioned, there’s never any data loss due to overwriting your original (a destructive model).
  • It saves disk space. Rather than storing updated copies of each image you alter (a generational model), Shotwell only stores the alterations, which are expressed in a compact notation.
  • Edits are fast, to the point of being almost instantaneous. For example, if you adjust the saturation of a photo, Shotwell only has to save the saturation value (which is a single floating-point value). In a destructive or generational model, the new saturation would be applied, and then the photo would have to be re-encoded and saved to disk, which can take up megabytes. JPEG is lossy, so re-encoding entails more data loss.

Non-destructive editing relies on an image pipeline, where an image is modified in stages before being sent to the screen (or to disk in the case of export, or to the printer). We’ve spent a great deal of time optimizing and fine-tuning the pipeline, using whatever tricks possible to get the image from disk to screen as quick as possible.

Auto-Enhance

This brings up one of the features we’re most proud of, our auto-enhance tool. We considered various algorithms and performed qualitative testing of photos enhanced by different applications. After a few tries, we landed on an algorithm that gives great results most of the time. (We’ve yet to find an auto-enhance that improves every photo.)

Our algorithm involves analyzing the photo’s luminescence, dropping the outer points of the distribution and boosting the middle ranges to expand the contrast of the image, making it punchier and more vibrant. If a fair portion of the photo is dark, the shadows are lightened to bring up detail.

Because all these adjustments are available in our color tool, the user can fine-tune the enhancement if the result was not quite right. Sometimes increasing the saturation of a photo can bring out richer colors, for example.

And because Shotwell is entirely non-destructive, if you wish to back out of the enhancement, it’s as simple as clicking Photo -> Revert to Original.

Fast and Scalable

Earlier this year I wrote about Vala, the new programming language we’re using to build Shotwell. We continue to believe Vala was a great choice for Shotwell, for all the reasons I explained in the article.

One way Vala has been a win is in Shotwell’s speed and memory footprint. We have fine-tuned control over the application in critical areas. For example, application startup is under one second to Gtk.main() with all objects loaded and ready for use, even with a library of 10,000 photos. Shotwell with a 10,000 photo library consumes 57MB of RAM at startup. If we wanted to be leaner, Vala allows us to control this even further, but we’re content with this footprint.

Ten thousand photos is not an extraordinary library size according to our users. We’ll continue to measure and optimize Shotwell to keep it speedy and its resource utilization low.

RAW Support

In Shotwell 0.6 we’ll be introducing support for RAW images. This is a highly requested feature, especially since the price point for cameras with RAW support is rapidly falling. RAW images are “digital negatives”, a dump of the state of the camera’s sensor when it was exposed as well as metadata regarding color profile, exposure time, and other information needed to process the file. The advantage of using RAW is that you have more control over correcting and improving the image. Once imported into Shotwell, all the benefits of its non-destructive editor are available.

Users may want to edit their RAW photos (or any photo) with a more full-featured editor. Shotwell 0.6 will also introduce the ability to edit photos with an external editor. We architected this feature to accomodate other editors—which are generally destructive—while still offering use of Shotwell’s own non-destructive one. Shotwell makes a copy of the master, applying any transformations you’ve made so far, and launches the editor for that photo. When you’re finished, Shotwell continues to allow you to make non-destructive edits to the edited photo. This means you can use GIMP, for example, to make sophisticated edits. Then, returning to Shotwell, you can use its non-destructive tools to fine-tune the image without losing the GIMP version. If you want to go all the way back to your master photo, you can return to that state as well; it’s never touched.

Organization

Shotwell today offers two primary ways to organize your photos: by tag (or keyword) and by event.

Most photo organizers offer a tagging feature. Tags allow you to notate a photo’s subject matter, creating groups of photos tagged, say, “London” or “GUADEC 2009”.

Events are different. When you import photos, Shotwell automatically sorts them into events. An event is a grouping of photos taken on the same day. Shotwell determines this by the exposure datestamp stored in the photo’s metadata. Think of events as chronological photo albums that Shotwell builds for you.

This means Shotwell immediately offers a grouping system for the user, with no effort on their part.

What Does the Future Hold?

We’ve brought Shotwell far, but we see its current feature set as merely a launching point for more great stuff. Possible future enhancements include:

  • Replace our pipeline with a 16-bit GEGL pipeline. Shotwell’s current pipeline is only 8-bit, which limits the range of color transformations we can make on RAW and (soon-to-be-supported) 16-bit TIFF images.
  • Monitoring the filesystem for photos and automatically adding them to Shotwell.
  • Automatic organization of your photos by geolocation, by their location on disk, and automatic face detection.
  • Better slideshows with customizable transitions and music.
  • Basic video support. As most digital cameras support recording movies, Shotwell will import those videos and allow you to play them right in the application. (Editing, however, will be the job of a dedicated video editor.)
  • Full synchronization, so you can share your photos across a LAN or synchronize from a server across the Internet.

… and plenty more. Shotwell’s home page is a great place to find out more information about Shotwell. We hope you find Shotwell a useful and vital tool for managing your ever-growing photo collection.

About the Author

Jim Nelson works at Yorba developing multimedia applications for the Linux desktop.

Discuss this story with other readers on the GNOME forums.