Category Archives: December 2007
Say cheese! Or maybe that’s “Cheese”? Either way, take a look at this interview by Sayamindu Dasgupta with Daniel G. Siegel, the author of Cheese, a funny GNOME application for taking pictures and videos from your computer’s webcam.
Daniel G. Siegel has been behind one of the most visible GNOME projects for Google Summer of Code 2007 – Cheese. From it’s page on the GNOME Wiki, Cheese can be described as a Photobooth-inspired GNOME application for taking pictures and videos from a webcam. It also includes fancy graphical effects based on the GStreamer media framework.
I had the opportunity of meeting him (and having him as my room mate) during GUADEC this year, and recorded a small interview with him on his project. The interview below is something like an extension of the recording that I made at Birmingham, with a number of updates and corrections made to reflect the current
state of Cheese (and its author).
Tell me a bit about yourself
I’m Daniel, hi!
How did you first hear about GNOME?
My first Linux distribution was packaged in a journal and it had KDE – I thought it was awesome. I was playing around with it, but however, after a while, I was looking for a new challenge, and so I watched out for alternatives, and obviously, there was GNOME.
Before the summer of code project, were you involved in GNOME?
Not really. I did some basic GTK+ things, like gpomme (hotkey manager for Apple Macbook laptops), if you know that. Just basic things, so not much actually, just a bit.
What interested you in your particular project, Cheese?
I wanted to work on an enjoyable project. I didn’t want to do something that was already there and I wanted to do something that was cool. So I just thought, here is my Macbook, what is not possible with that hardware and Linux at the moment, eg: hotkey manager (which I had already been working on)…
So, in a way, you were scratching your own itch?
Yes! I thought something like Cheese would be great and some days after that notion I found Raphaël Slinckx who had written a basic application in Python. I contacted him, and…
When you started out, what were the most difficult things that you had to handle?
Most Difficult? . I think getting my hardware working.
So there were driver issues?
Well, on the one hand, there were driver issues, but on the other, there were issues created due to my own crappy code. In the first two weeks, I had real problems to get a picture of my pretty face on the screen. It was quite hard to get used to and understand new libraries, but it became easier and easier with time. Now for example, if I want to write a new feature, I know where to look, what it takes, and of course it takes me less time.
As a new developer, or rather, comparatively a new developer, looking at the GNOME development platform, which part did you like the most?
Good one. I don’t have a favorite. Or wait, maybe
In that case, which part of the platform did you dislike the most?
auto-. Ah, and then there was GObject, which provides a lot of advanced stuff but it takes some time to understand such a thing. Especially if you are used to plain C and your application is not really big. In that case you will have a lot of boilerplate code.
So you are wondering if it’s worth the effort for a comparatively small application?
Yeah, it’s awesome to have object-oriented capabilities in C code, things like properties and so on, but i don’t think it’s worth the time to use it on really small projects. Of course Cheese is now big enough, and uses GObject almost everywhere. Other project members and myself really enjoy that, as the code gets much more readable.
In the GNOME Development Platform, which areas do you think should be worked on to attract new developers?
If you ask me, it’s pretty hard to get started. I mean, if you are in, once you know what your required API is, your workflow and the exact functions you want to look for, it’s quite an easy process. But if you are new, you don’t know what to do. So the only way to get “in” is to download some source code and study that. It’s not a really good way to attract new developers. There are quite a few tutorials on the net, but I missed the one and only good one .
Going back to the question about the part you liked the most and kind of rephrasing it, what are the things you think work well within the existing system? What do you like about the GNOME development platform? What made your work easier?
I feel GTK is really great. Creating your UI is pretty straightforward. GStreamer is also a very cool platform as well as Glib too. The developers did a really awesome job almost everywhere in the GNOME development platform!
Any advice for a new GNOME developer, someone who wants to get started in GNOME development?
I think one of the most important things is to find someone like Raphaël who is online day and night so that you can bug him whenever you like. 3 AM was a really great time, but quite often either he or myself were drunk . You can always ask in the IRC channels or on a mailing list, but if you want to ask something like ‘How to create a big, fat, blue, shiny button, which blinks when you put your mouse pointer over it,’ they will laugh at you. So it’s nice to have someone to ask such basic questions, like how to begin.
Moving on to a slightly different area, what are the latest updates to Cheese?
Oh, there are many: Cheese has been refactored, a drag and drop implementation, added HAL-webcam recognition, GtkUimanager, some accelerators, a GConf back end, fixed a few million problems (however problems, not bugs, as Cheese is bug-free of course), GObjectified quite literally everything, and finally, we will implement a Conduit back end too.
You mentioned that the original prototype that Raphaël developed was written in Python. Many developers today including myself prefer to code in Python, as it usually makes life easier. What led you to write Cheese in C?
Pretty easy – I don’t know Python. Of course C is a bit more work, but in the end I prefer C because it’s more plain and it has its own advantages.
What tools do you normally use to debug?
printf . Yeah, that’s probably the best debug tool. But sometimes I use the GNU debugger or my programmer slaves for that.
How is the response to Cheese?
Awesome! My mailbox was full of emails. People have contacted me on mail, IRC or IM, providing suggestions, tips, bug reports, enhancement requests, translations, and that was really cool. After all, it was one of the first times that so many people contacted me without wanting me to pay their bill.
How did you go about designing the interface – the UI design?
I had Raphaël’s work to begin with in the first place, but I didn’t like the effects widget, so I (re)wrote it. I know it’s not very good, but at the moment we are fancying it up a bit and soon, we will get a live preview. Overall, the whole UI became better over time and even now, we make enhancements to it every week.
Now that SoC is over what advice would you give someone who is thinking of applying for the program in 2008?
Oh… Apply to GNOME, it’s just damn cool! Ah, and do some work before you apply, like designing the interface or planning the program. It looks better if there is already something you have achieved yourself when applying.
Well, that’s about it, thanks a lot for your time.
Great, I’m already hungry – thank you.
About the author
Sayamindu Dasgupta is a student of Computer Science and Engineering from Kolkata, India. He was a participant in the Google Summer of Code 2007 program, under Federico Mena Quintero. Apart from GNOME and computers, Sayamindu loves travelling, taking photos and having good food.
Davyd Madely reviews the book Foundations of GTK+ Development by Andrew Krause, and published by Apress.
There aren’t many books available that cover GTK+ and even fewer of them are up to date. For a long time, the only book covering GTK+ 2.0 was Matthias Warkus’ The Official GNOME 2 Developer’s Guide from No Starch Press. Now Andrew Krause, a computer engineering student from Pennsylvania State University, has written Foundations of GTK+ Development, published by Apress. Mr. Krause was very kind in providing me with a complementary copy to review.
While by no means the heaviest book on my shelf, Foundations of GTK+ Development weighs in at 630 pages with 13 chapters and 6 appendices. Krause has the right idea with his chapters. The book first covers terminology and what you need to develop GTK+ programs. The second chapter then gives the archetypical “hello world” example, important for the budding GTK+ developer to feel a sense of accomplishment. It introduces the fundamental concepts of GTK+: events, the mainloop, signals and widget heirachies. Chapters 3-5 cover a wide range of GTK+ widgets, starting with packing containers (and how box packing works in GTK+), many of the common widgets you see day to day and finally dialogs. Chapter 6 touches on the functionality provided in GLib. Chapters 7 and 8 cover GtkTextView and GtkTreeView respectively. 9 is menus and toolbars and 10 covers Glade. Chapter 11 briefly touches on writing custom GTK+ widgets and chapter 12 cleans up any miscellaneous items. Chapter 13 then looks at some example apps to discuss how they work.
The book starts with a reasonable overview of X11, GTK+ and its main components (GLib, GObject, GDK, Pango and ATK, but not Cairo) and makes mention of the language bindings. Though be warned, while the bindings are mentioned, this is very much a book for C programmers, and those who are working with a language binding may find it of only minimal usefulness. Krause attempts to explain how to get GTK+ development packages from
your vendor or how to build and install them yourself, but I don’t believe it covers this in enough detail. There is neither a discussion of what packages to install or what the set of packages you will need to build are called. Prospective developers will find it confusing to set up their environment and will likely require extra help.
Krause takes the time to provide some words of caution to the unwary, beginning, for example with regards to widget layout. He also references the Human Interface Guidelines a handful of times when discussing the design of user interfaces, as well as providing his own advice.
Chapter 11 covers writing a custom widget, but I personally found this chapter to be a little bit disappointing as it seems to diverge from GTK+ best practice. For example, it doesn’t use G_DEFINE_TYPE(), or consistently demonstrate functionality like GLib’s runtime type checking for public functions. In my opinion, The Official GNOME2 Developer’s Guide contains a better treatment of GObject, although it doesn’t cover creating custom widgets. The drawing functions described in this chapter are the old GDK drawing functions rather than the Cairo drawing API. Cairo is instead briefly covered in the next chapter under Additional GTK+ Widgets after GtkPrint.
Krause comprehensively covers most, if not all, of the UI widgets available in GTK+, along with an excellent chapter detailing most of the features and data structures provided by GLib. Unfortunately the book does not spend much time discussing GTK+ best practices nor does it provide canonical design patterns for some of the widgets (e.g., GtkRadioButton, a widget that many inexperienced GTK+ programmers get confused by). The book covers Glade (version 3.0) and libglade, but does not cover libgnome/ui, GConf, GnomeVFS, libmlx2 or other GNOME-related technologies (which are covered in The Official GNOME2 Developer’s Guide).
I like the //Test Your Understanding// section given at the end of each chapter. These sections present small exercises to the reader that allows him or her to put what they’ve read into practice (e.g. connecting a signal or creating a menu). Brief answers to these exercises are provided in the back of the book with source code available on the Web. Each chapter also ends with a summary of what was in the chapter.
The last chapter of the book discusses the construction of several small sample applications: a simple file browser, a calculator, a hangman game, a wrapper around `ping` and a calendar. Hints are provided for each application so that the reader can attempt to implement the utility him or herself, although source code is provided on the Web. The chapter then suggests where to go for further help. Five of the six appendices are GTK+ reference documentation: properties, signals, styles, Pango markup, stock items and GError types. Unfortunately the book never points budding developers to awesome tools like Devhelp.
The publisher, Apress, has also made a PDF eBook version available for purchase. The eBook is locked using the email address you provide when you purchase it (which is supported by Evince) and you are able to print it, if you so desire. The PDF does have bookmarks for the chapters, but does not have hyperlinked cross-references or other nice features. Unless you particularly like eBooks, or can’t get a hardcopy where you are, I’d spend the extra $8 for the real thing.
On the whole, the book had both excellent and disappointing aspects. Generally, I like the order in which the topics were presented, though occasionally the book gets bogged down in details that otherwise wouldn’t have a home; and some important concepts, like Interfaces, end up introduced midway through a chapter where they are easily missed by the reader. I like the summaries and exercises and the book is reasonably up to date, covering GTK+ 2.10 and Glade 3.0. Unfortunately the book does not really cover major parts of GTK+’s underlying infrastructure like Pango and Cairo as explicitly as I think it should. Boiling it all down, this is not the book for someone who knows GTK+ to improve their skills, but as its title suggets, will provide the foundations for someone looking to learn GTK+, although not perhaps the canonical GTK+ developer’s style. I am giving it 3.5 feet out of 5.
More information: http://gtkbook.com
About the author
Davyd Madeley is an electronic engineer and computer scientist from Perth, Western Australia. He has previously been the GNOME Applets maintainer and has been an occasional author for GNOME Journal. His interests are UI design, machine learning, electronics and playing the tenor saxophone.
Ian McIntosh interviews Amy de Groff, Head of IT for the Howard County Library, about their switch to GNU/Linux and implementation of Groovix, an Ubuntu-based distribution.
In 2004, the Howard County Library in Columbia, Maryland, made news when they switched 300 of their public computers from Windows to an in-house Linux solution. Recently, they upgraded those computers to a version of Ubuntu distributed by Groovix. Amy de Groff, Head of IT for the library, answered some questions about making the switch to Linux and implementing Groovix.
Before switching to Linux, what software was the library using?
Before we moved our customer machines (we call them PACs for Public Access Computers) to Linux, they were running Windows NT®. A former IT person had shut down a great deal of the functions, access, etc., but the machines remained a constant source of support: icons changed to tacky images, items saved to the desktop, etc.
How did the library first get interested in Linux? What aspects of Linux were attractive?
We got interested in Linux because two of our IT guys (former UNIX® administrators) were big fans. What we liked about it was the ease of management from a remote location (we have six branches and, at that point, two IT guys managing the machines) and the ability to strip off functions, applications, and services that we did not want.
The financial aspect was also attractive, but it was actually not the first thing we fell in love with. I see it as an added bonus and a wonderful service to our community that I can offer a streamlined desktop and save money!
How was the first switch?
The first switch was from the NT environment I described above to LuMix, [a Linux distribution] designed and managed by Mike Ricksecker and Luis Salazar.
LuMix basically just had a browser, Mozilla, stripped to bare essentials. We put it on all but three machines at each branch, leaving NT on those with MS Office 97.
LuMix ran like a top for nearly two years, but customers wanted more. They wanted word processing, they wanted access to USB flash drives (we’d shut that down in LuMix and it was not available on our NT version) so we started thinking, ‘What next?’
One option was, of course was to rebuild and upgrade LuMix. Mike began work on LuMix 3.0 (as we were tentatively calling it).
At the same time, we researched the vendor world, and we found two interesting options: a Canadian firm called Userful®, and a technology called Groovix, built by Open Sense Solutions.
We chose Groovix. Hard to quantify why; it just felt more open and we liked the support staff very much.
How long did you evaluate the Groovix/Ubuntu solution before deciding to move forward?
We evaluated Ubuntu for two months. To be honest, I was sold ten minutes in, but I knew I had to give it more time and use. I am truly amazed at the usability of Ubuntu—I think it is down-right ELEGANT.
What expenses were associated with the switch to Groovix/Ubuntu?
It cost us around $20,000 to upgrade the memory on the 300 PACs (we went from 128 to 512), and we spent $25 on the software (yes, twenty-five dollars).
We pay for support from Open Sense Solutions—a flat, yearly rate that is about 1/10th of what we pay for other enterprise-wide software.
And we bought T-shirts for staff for the launch day.
Had we remained a Windows shop and chosen XP instead, we probably would have replaced the hardware entirely, anticipating the move to Vista. At around $800 for each of 300 machines, that would have cost $240,000.
What has the library done with the money saved so far by this switch?
Some of the money we saved so far has gone to hardware—we bought lovely 19” flat screens for every single machine.
Is it safe to say that the library will continue to save money in the future as a result of switching to Ubuntu?
Very safe to say. We’ll continue to use the funds for service: computer training, books, movies, programs, and hardware upgrades.
What kind of requests for help has your staff received from patrons?
Our requests for help/help desk tickets have dropped by 40% since the Windows NT days. Most customers sit at the machine and work away, requiring no help. Customers who are less comfortable on a computer have questions, but they are not Linux-based. Instead, ‘How do I bold text?’ or ‘How do I add a page break?’ The kind we’d get with any application.
Most help desk tickets now are hardware problems, a hard drive dying or a machine being unplugged (one of the most common ones, actually).
How has the staff responded to the switch?
All in all, they are fine.
We have a few staff who are reluctant to move to OpenOffice. They maintain that because it is free, it is not as good. I really don’t agree with that opinion. We are moving all staff to Ubuntu desktops this fall and winter so, soon, they will be using OpenOffice. I do hope those who are uncomfortable come around. I work hard to do one-on-one training and to be a cheerleader for them.
Have you had any problems with the new Ubuntu computers?
The only problem is that a few websites, for example some college grade sites, require Internet Explorer. They don’t work here. And we don’t apologize for that. We encourage our customers to express their frustration to their colleges.
We had one machine that kept ‘turning off for no reason’ a while back; of course all assumed it was the ‘third rate’ open source software. Turned out the user was a leg swinger: she was bumping the power switch! As a leg swinger myself, I can relate to this story!
Is there any software that the library would like to use that is not available in Linux?
The sole piece of software we can’t use here is the CLIENT for our integrated library system. It is a shame, because this vendor’s plan, presented to us three years ago, was to be entirely web-based by now. It was because of this plan that we were comfortable doing all that we have done.
That vendor changed course, and while I could have chosen to change course with them and abandon our vision of Linux system wide, I will not. I can’t let any vendor dictate how I spend taxpayer money. We are likely to part ways with this vendor in the coming year.
What barriers do you see preventing other libraries from switching to a similar solution?
I think the biggest barrier facing libraries in doing what we have done is fear of the unknown. We ran into this of course. When people started using the software they would often come into my office sheepishly and say, ‘Um, this is not a big deal,” and I would smile and say, ‘YUP!’
Can library patrons play a role in getting their libraries to evaluate open source software?
Library patrons can and should request an accounting of what software costs, especially with [Windows] Vista® on the horizon.
Patrons should ask, ‘Why? Why move to Vista? What does it give me as a customer?’
I had one Vista user tell me the 3-D functionality was cool. I said, ‘What does that do to get my customers information about my collection?’ There was no answer! Is ‘cool’ worth taxpayer dollars?
And most libraries will have to replace EVERY machine to run Vista.
Bring them an Ubuntu install CD! I do it all the time!
Thank you so much for your time, Amy!
It was my pleasure! I am proud of what we are doing and I would love to help other groups use Ubuntu. I would also like to hear about other projects or applications that your readers think would be nice additions to our deployment!
Amy de Groff can be contacted at firstname.lastname@example.org.
About the author
Ian McIntosh is a freelance software developer from Cambridge, MA, currently living in Mendoza, Argentina. In his free time he works on Luz, an open-source music visualization application for GNOME.