No GSoC
Sadly, we didn’t get accepted into Google’s Summer of Code this year. It’s a shame, but I’m glad I went through the effort to apply. If nothing else, we got some potentially-useful ideas and possibly some developer interest. Obviously we can’t fund any of these people, but it would be great if they still want to contribute.
Update: The coordinator got back to me, and said our ideas page wasn’t very fleshed out, and that we should look at other accepted applicants and the program guidelines for help on how to do this right… never mind that I actually *did* look at some older accepted projects, and their ideas lists were at times even more sparse than ours (though many were much more formally written up as well). Also she gave the usual “we can’t accept every great project” excuse, which at least gives some hope for next year. I’m not particularly sure I want to go through the work to apply again, but maybe someone else will.
whaawmp 0.2.8
Today Jeff, released whaawmp 0.2.8.Check it out here.
There is a release for Python 2.4 too.
On to Xfce Edition. I still hope to get an iso out this week.
I'm thinking about replacing OO.o with abiword/gnumeric on default installation, if it reduces the iso size enough to fit on one CD.
But there are still things missing, so I will probably end up with a bigger image anyway.
Let's get it out for testing...
Xfce and Google’s Summer of Code
While we haven't been accepted into the program yet, we (Xfce) are applying to participate in the 2008 Google Summer of Code as a mentoring organisation. Please see our wiki page for more information, and add your name to the students list if you'd like to work on one of the projects. Feel free to add to the project ideas list as well.
If you'd like to act as a mentor, you still have a few more days before I submit the application. Add your name to the mentors list and email me to let me know.
Xfce and Google’s Summer of Code
While we haven’t been accepted into the program yet, we (Xfce) are applying to participate in the 2008 Google Summer of Code as a mentoring organisation. Please see our wiki page for more information, and add your name to the students list if you’d like to work on one of the projects. Feel free to add to the project ideas list as well.
If you’d like to act as a mentor, you still have a few more days before I submit the application. Add your name to the mentors list and email me to let me know.
Ristretto, a ‘lightweight’ image viewer
From the moment I started developing ristretto, I mentioned that it was a simple lightweight image viewer. This is a statement which is bound to be disputed by some, and here is the reason why: ‘There is no such thing as a lightweight image viewer‘. And they are right, decompressing an image requires a lot of CPU-power, and a fully decompressed image requires the presence of enough RAM memory in order to do anything usefull with it at any acceptable speed. No image viewer has been able to surpass this limitation, ristretto is no exception to that rule.
So, why do I say ristretto is lightweight? — Because there is more to an image viewer then the two constants I mentioned before, a basic image viewer should:
- Navigate between images in an entire folder
- Display image thumbnails
- Run a slideshow
- Flip / Rotate images
- Read (and interpret) EXIF meta-data, for jpeg images taken by digital camera’s.
- Have well-documented comprehensible code
At this moment, a rudimentary implementation of these features have found their way inside ristretto. Rudimentary, because each component is being looked after if it needs refactoring. The goal is to improve these features until ristretto is a stable and fast image viewer using as little memory as possible (making it relatively lightweight), considering it’s purpose.
I’ve just summed up the first priority of ristretto development; to write a simple and fast image viewer, which does just that: show images.
Any additional features, like importing images from a digital camera (using libgphoto2) or printing images to paper could probably be added through a plugin interface or something. Keeping the basic application simple while allowing individual users to add features they like. If, when and how this is going to be implemented is still a question though ;).
It’s getting there…
Fosdem is over. I heard some talkes, investigated some booths, but the fun thing was meeting Michael, Ken, Antonio, and some other guys there.I guess there are better organized events and meetings out there, but it was worth going there (at least if it's only a 2,5h ride). Unfortunatly I didn't run into any Xfce developer, but a few of them have been there. Hope next time they will have a booths or a devroom (even if they would have to share with Gnome).
I did some improvments to Xfce Edition, added a lot of "unimportant" packages I just forgot (network-manager-applet, gimp, inkscape, evince, brasero).
So biggest issue now is to make gdm start Xfce as default, for new users.
Whaawmp is now working with python 2.4, I added a svn snapshot to Xfce Edition.
Unfortunatly due to gst dvdnav bugginess, it doesn't support dvd menus. C'est la vi.
So long...
Video
Sweet! I got a brief mention in TiNDC #35. Now that I'm back to Linux after a 2-week stint on MacOS X, hopefully I'll be able to help out some more. Not that I don't have other things I'm supposed to be working on...
SCALE, ebuilds, burning apps, and gtk
SCALE
It's been a coupla weeks now since SCALE 6x, so it's about time for an after-action report.
My wife and I arrived Friday night after suffering a two-hour delay because of heavy traffic. The 405 was the worst. LA traffic always gives me nightmares.
Saturday morning came far too early, but at least we were already registered. We got there the same time as omp, who'd brought a Windows-using friend along as a booth slave--er, volunteer.
Our booth setup included a giant Gentoo poster, omp's desktop rig, and one (occasionally both) of my laptops, displaying Xfce. It was more popular than the extremely minimal openbox desktop, so HAH! We gave out lots of bribes--snacks--and even more LiveCDs. It's too bad we didn't have flyers, business cards, shirts, or other Gentoo swag this year. Lots of folks were asking for them. At least we gave out snacks'n'luv.
Wireless internet sucked throughout the weekend. Apparently it was the same for everyone. Spotty, minuscule bandwidth, and nameservers couldn't be reached. Made it hard to demo things that needed internet access, such as emerging packages, looking up our homepage, or highlighting documentation.
One of our users, calculus, was around much of the time to help out; was nice to see him at SCALE again this year. And wormo made an incognito appearance, too. To all the users and everyone else who stopped by and asked questions, gave feedback, or just chatted -- thank you. You're terrific. I'm always excited to meet a Gentoo user in person. It's like "Really? you use Gentoo? No way!" We were possibly the least-known distro there (tied with Foresight and Damn Small Linux?), certainly the least commercial one. The other distros were all heavyweights: Ubuntu, Red Hat, Suse, Fedora, etc.
Still, we had lots of traffic. Several people wanted to know what's up with Gentoo in regards to our recent legal status issues, so I provided the news in-person, and that seemed to go over well. Curiously, none of the enterprise-level folks were much interested in our legal status. They pretty much all said the same thing: "We're not worried. All the technical development is still there; nothing's changing." It was only the individual users who had all kinds of worries and needed the explanation. The corporate sector wasn't worried at all: "As long as it's still being developed."
There are plenty of pictures of our booth around the 'net in reviews and photo sites; you just have to look for 'em.
I had a blast at SCALE. I plan to attend next year, too.
ebuilds
Lately I've been poking random ebuilds from the tree, posting updates to Bugzilla, creating new local ebuilds, asking for keywords/stabling, and so on. It's a lot of fun. A fair amount of edgy experimentation, but that's what my new laptop is for. Things like wicd that I'd like to see in the tree, or the latest version of brasero.
burning apps
Speaking of burning software . . . brasero seems to be the only actively developed gtk+-based application. Everything else hasn't had a release in years. Xfburn, gnomebaker, graveman, xcdroast....you name it. That's not good news. Brasero is a good choice for my Gnome desktop workstation, but I wouldn't even think of putting Gnome on my laptop, which is a pure Xfce machine. And yet I hate the idea of putting K3B on my laptop even more, because of the ugly, ugly Qt and kdelibs dependencies.
I went ahead and installed brasero on my laptop anyway, since it's gtk+, and it can work with DVDs. None of the other apps I mentioned support 'em. That added 33 huge Gnome deps, including (ugh) nautilus. The irony? K3B only wanted 18 total packages. Still, it's uglier. That's what counts, right?
So thinking about this sad state of affairs for gtk+-based burning apps got me thinking . . . what would it take to create a new one? Something fast, with minimal dependencies, and gtk-based.
gtk
I've skimmed the gtk tutorial and the reference manual before, but only as a passing curiosity. Today I really took a shot at figuring 'em out. This is where I ran into the cliff known as "C programming."
I'm not a programmer. I can do markup languages, I can do some bash, some javascript, little things like that. But I've never been trained in OOP. Or any kind of programming, except some BASIC in elementary school and college. My degree is in theatre, not computer science!
Still, I'm determined to make what headway I can with these gtk+ guides. I've started to see what does what, and why. And some of the necessary parts of an app. Now I need to find out how to get that button press to do something, like . . . burn a CD. Copy a disc. Save an iso. And so on. For that, I've been poking at the source code for Xfburn, libburn, and brasero. This is all still just a bit over my head, but I'm trying, at least.
I've already partly answered my own question of "Why aren't there more up-to-date gtk+ burning apps available?" because I created a sample task list.
Writing a graphical app is a huge undertaking. What burning backend will be used? cdrtools, cdrkit, libburn/libisofs, dvd+rwtools are all possibilities. Same goes for the media types used in writing audio discs. The app has to handle notification (possibly via dbus), disc drive status/detection, set/get write speed, and a dozen other critical tasks. Oh, and it needs to be translatable (those pesky .po files that take up space), and it really should make use of autotools. What other libraries will it use? Will any of its features be optional compile-time switches? Got to add those too. Where will the project be hosted? What VCS? And so on.
Lots of stuff to do. No wonder brasero's the only active gtk+ burning app. And that's too bad, too. It has a ton of dependencies that folks using Xfce or just a WM don't care to install. I'd like to see the huge gap between "brasero" and "nothing" filled by a low-dependency, fast, capable application. I just don't think I'm up to the task of creating it all by myself. 
SCALE, ebuilds, burning apps, and gtk
SCALE
It's been a coupla weeks now since SCALE 6x, so it's about time for an after-action report.
My wife and I arrived Friday night after suffering a two-hour delay because of heavy traffic. The 405 was the worst. LA traffic always gives me nightmares.
Saturday morning came far too early, but at least we were already registered. We got there the same time as omp, who'd brought a Windows-using friend along as a booth slave--er, volunteer.
Our booth setup included a giant Gentoo poster, omp's desktop rig, and one (occasionally both) of my laptops, displaying Xfce. It was more popular than the extremely minimal openbox desktop, so HAH! We gave out lots of bribes--snacks--and even more LiveCDs. It's too bad we didn't have flyers, business cards, shirts, or other Gentoo swag this year. Lots of folks were asking for them. At least we gave out snacks'n'luv.
Wireless internet sucked throughout the weekend. Apparently it was the same for everyone. Spotty, minuscule bandwidth, and nameservers couldn't be reached. Made it hard to demo things that needed internet access, such as emerging packages, looking up our homepage, or highlighting documentation.
One of our users, calculus, was around much of the time to help out; was nice to see him at SCALE again this year. And wormo made an incognito appearance, too. To all the users and everyone else who stopped by and asked questions, gave feedback, or just chatted -- thank you. You're terrific. I'm always excited to meet a Gentoo user in person. It's like "Really? you use Gentoo? No way!" We were possibly the least-known distro there (tied with Foresight and Damn Small Linux?), certainly the least commercial one. The other distros were all heavyweights: Ubuntu, Red Hat, Suse, Fedora, etc.
Still, we had lots of traffic. Several people wanted to know what's up with Gentoo in regards to our recent legal status issues, so I provided the news in-person, and that seemed to go over well. Curiously, none of the enterprise-level folks were much interested in our legal status. They pretty much all said the same thing: "We're not worried. All the technical development is still there; nothing's changing." It was only the individual users who had all kinds of worries and needed the explanation. The corporate sector wasn't worried at all: "As long as it's still being developed."
There are plenty of pictures of our booth around the 'net in reviews and photo sites; you just have to look for 'em.
I had a blast at SCALE. I plan to attend next year, too.
ebuilds
Lately I've been poking random ebuilds from the tree, posting updates to Bugzilla, creating new local ebuilds, asking for keywords/stabling, and so on. It's a lot of fun. A fair amount of edgy experimentation, but that's what my new laptop is for. Things like wicd that I'd like to see in the tree, or the latest version of brasero.
burning apps
Speaking of burning software . . . brasero seems to be the only actively developed gtk+-based application. Everything else hasn't had a release in years. Xfburn, gnomebaker, graveman, xcdroast....you name it. That's not good news. Brasero is a good choice for my Gnome desktop workstation, but I wouldn't even think of putting Gnome on my laptop, which is a pure Xfce machine. And yet I hate the idea of putting K3B on my laptop even more, because of the ugly, ugly Qt and kdelibs dependencies.
I went ahead and installed brasero on my laptop anyway, since it's gtk+, and it can work with DVDs. None of the other apps I mentioned support 'em. That added 33 huge Gnome deps, including (ugh) nautilus. The irony? K3B only wanted 18 total packages. Still, it's uglier. That's what counts, right?
So thinking about this sad state of affairs for gtk+-based burning apps got me thinking . . . what would it take to create a new one? Something fast, with minimal dependencies, and gtk-based.
gtk
I've skimmed the gtk tutorial and the reference manual before, but only as a passing curiosity. Today I really took a shot at figuring 'em out. This is where I ran into the cliff known as "C programming."
I'm not a programmer. I can do markup languages, I can do some bash, some javascript, little things like that. But I've never been trained in OOP. Or any kind of programming, except some BASIC in elementary school and college. My degree is in theatre, not computer science!
Still, I'm determined to make what headway I can with these gtk+ guides. I've started to see what does what, and why. And some of the necessary parts of an app. Now I need to find out how to get that button press to do something, like . . . burn a CD. Copy a disc. Save an iso. And so on. For that, I've been poking at the source code for Xfburn, libburn, and brasero. This is all still just a bit over my head, but I'm trying, at least.
I've already partly answered my own question of "Why aren't there more up-to-date gtk+ burning apps available?" because I created a sample task list.
Writing a graphical app is a huge undertaking. What burning backend will be used? cdrtools, cdrkit, libburn/libisofs, dvd+rwtools are all possibilities. Same goes for the media types used in writing audio discs. The app has to handle notification (possibly via dbus), disc drive status/detection, set/get write speed, and a dozen other critical tasks. Oh, and it needs to be translatable (those pesky .po files that take up space), and it really should make use of autotools. What other libraries will it use? Will any of its features be optional compile-time switches? Got to add those too. Where will the project be hosted? What VCS? And so on.
Lots of stuff to do. No wonder brasero's the only active gtk+ burning app. And that's too bad, too. It has a ton of dependencies that folks using Xfce or just a WM don't care to install. I'd like to see the huge gap between "brasero" and "nothing" filled by a low-dependency, fast, capable application. I just don't think I'm up to the task of creating it all by myself. 