Include custom GTK+ RC style
I've been using a custom GTK+ RC style for the notes plugin since the version 1.4.0, right now it is at version 1.7.2. I have been playing with GTK+ theming again these last two hours, and I've get custom scrollbars, a gradient for the custom-made “title bar”, and better colours for the notebook to get the current tab stand out from the crowd.While experimenting on a test-case code I found out a better way to parse a gtkrc file in the program. The first time I was fighting with the existing gtk_rc related functions, I gave up on a solution I partially dislike that is to include a line to the custom gtkrc file within ~/.gtkrc-2.0.
Today I understood how gtk_rc_parse(filename) behaves. You have to call this function at the beginning of the program before building any widgets, it will work even if the file doesn't exist yet. Next, while the program is running, you can modify the file, create it, delete it, truncate it, whatever, and call gtk_rc_reparse_all() to get the style refreshed in the GUI. It's hard to believe that such easy things are sometimes a PITA :-)
Be prepared for a 1.7.3 notes plugin with nicer colours.
SCALE 8x recap
So SCALE 8x went okay.
I was interviewed by the SCALE Public Relations team; you can see the video here.
Gentoo@SCALE
I'd say we had the most diverse assortment of machines at any booth -- something like 10 different machines on 5 architectures. Certainly we had a bunch of developers; we haven't had a showing like this since SCALE 5x.
Everyone loves event pictures, so here's the Gentoo team:
Left to right: vapier, nightmorph, antarus, nerdboy, wormo, omp, halcy0n, solar
Not pictured: blackace (he took the picture)
And now, the hardware running Gentoo! On the table, from left to right:
1. Beagleboard running E17 on the huge monitor
2. Hammer/Nail board by Tin Can Tools (in the clear orange-capped tube)
3. Blackfin development board (hooked up to the middle keyboard, and with a touchscreen running Doom)
4. deployed Blackfin module (that 2-inch square to the left of the wireless mouse)
5. my Core2 Thinkpad running KDE4
6. a mini-notebook
7. OLPC XO (green/white, on top)
8. PowerPC Walnut board (in the K'Nex case). Barely visible behind it is the laptop that's tied in via serial port.
There were a few other Gentoo-powered laptops, subnotebooks, and smartphones demoed throughout the conference, but not all of 'em are visible in this picture.
I mostly demoed KDE 4.3 on my laptop, since the desktop effects and eye candy proved to be a good draw, especially the "falling snowflakes" animation. Man, I love that thing! It's a built-in KWin effect, so there's nothing special to install. Now all I want is a "falling raindrops" effect on my desktop, without resorting to Compiz.
I did occasionally switch the laptop to Xfce when I wanted to save power, or just to showcase Gentoo's flexibility. I got a good draw not when showing a standard Gentoo wallpaper, but when I showed off a desktop rather like this (clean version here). There were a buncha little kids that stopped by and oohed and ahhed over that for a bit.
Sessions@SCALE
The talks were rather disappointing this year. Several of my fellow devs stated that they "just plain sucked." Basically, none of us attended because of the talks. There just weren't any powerful draws. I was only vaguely interested in attending a couple of sessions, the ones on startup-up/embedded improvements and building a featherweight desktop. Didn't actually get to see those, as the timing and draw was just kinda "meh."
Instead, I found myself at the Mindstorms talk, which was very lackluster. I expected to see lots of toys in action, and videos, and whatnot. The speaker wasn't at all engaging, and the single Lego robot was impossible to see, and it wasn't working correctly for the entire presentation. I stopped by another session or two, but nothing grabbed my interest. I spent most of my time on the show floor, helping in the booth or wandering the floor. Speaking of which . ..
KDE@SCALE
I stopped by the KDE booth to see the newest 4.4 and 4.5 stuff being demoed, and I also tried to help one of the devs figure out the build dependencies for one of the latest libraries. Man, source building on Ubuntu sucks. There's some really, really nifty Plasma desktop stuff going on for small screens. The newspaper-like activity flow is something I wouldn't mind using day-to-day on my workstation.
Another neat bit of 4.4/4.5 is the ability to switch your Plasma desktop widgets while still keeping your applications open in front of you. It's sort of the opposite of workspace switchers, where each application group is on a separate virtual workspace, while the desktop remains fixed. I never bother with more than one workspace, but I do like the idea of switching the widgets behind whatever it is I'm working on.
The 4.4 improvements and upcoming 4.5 features are definitely enough to keep me interested in KDE, so I'll leave it on my laptop and look forward to the day 4.4 is stabilized in Gentoo.
Elsewhere@SCALE
The Gnome and XBMC booths were just across the alley from our booth, but I didn't get a chance to check out either. The Gnome guys blasted pounding techno music the whole conference, which gave all of us--even the ones without hangovers--good-sized headaches. The XBMC folks were running some pretty impressive demos on their Zotac MAG, but unfortunately I didn't get a chance to go over and chat with 'em.
In the last few days, I've decided to put together a living room HTPC built around an Acer Aspire Revo and XBMC Live, and it woulda been good to see the thing properly demoed a couple of weeks ago. Still, from what I saw from the Gentoo booth, XBMC is one heck of an awesome app.
Our booth was fairly well trafficked, but overall it felt like attendance (and interest in Gentoo) was down from previous years. Take that with a huge grain of salt, though -- while I felt like SCALE was more sparsely attended and the talks sucked, the actual numbers tell a different story. The event organizers say attendance was up more than 10% and there were more standing-room-only talks than ever before. So make of that what you will -- but I might not go back next year if it's going to be anything like my experience this year. There need to be more sessions that are relevant to my interests.
One of the high points of SCALE was meeting the folks interested in Gentoo, and definitely talking with our existing users, like the ever-loyal calculus from IRC. Thanks for coming by, folks!
Show/hide functionality from notification area
When using a status icon within the notification area it is common to use the left-click action to show/hide the main window. Obviously this is often done in different ways. So here is my tip on how to do it right :-)What I believe to me the most sense-full way is to:
- Check if the application is invisible and show it,
- Otherwise check if the window is inactive and present it,
- Otherwise hide it.
/* Show the window */I have been doing this for quite a long time inside the Xfce Notes plugin, except a little different with multiple windows.
if (!(GTK_WIDGET_VISIBLE(window))) {
gtk_widget_show(window);
}
/* Present the window */
else if (!gtk_window_is_active(GTK_WINDOW(window))) {
gtk_window_present(GTK_WINDOW(window));
}
/* Hide the window */
else {
int winx, winy;
gtk_window_get_position(GTK_WINDOW(window), &winx, &winy);
gtk_widget_hide(window);
gtk_window_move(GTK_WINDOW(window), winx, winy);
}
Some remarks, the PendingSealings proposes gtk_widget_get_visible instead of its analogous MACRO. And as you may also notice when the window is hidden it gets moved just after, this is important as otherwise the window would be repositioned by its initial value once shown again (e.g. centre of screen or dynamically by the window manager).
Xfce4 XKB plugin needs a new maintainer
Alexander Iliev, the current Xfce4 XKB plugin maintainer, sent a message to the goodies-dev ML telling that he is looking for a new maintainer for xfce4-xkb-plugin. Please get in touch with him if you are interested.
xfce4-xkb-plugin currently has 38 open bugs on the Xfce bugzilla, 4 of them have a patch in bugzilla. This plugin to switch between different keyboard layouts has a lot of users, so you'll make a lot of happy users if you start working on this! Xfce needs you!
SCALE, git, docs, Xfce
SCALE
SCALE 8x is just around the corner! I and something like 8 or 9 other devs will be there -- it'll be our biggest showing since SCALE 5x a few years ago. Several folks coming from the Bay Area or flying in from across the state. I'll drive up Friday sometime to help setup the booth, and maybe try to get my Beagleboard working a bit better in time for the show on Saturday.
Git
Since my last post, I've opened up a couple of public repos at GitHub: one for my fork of LogJam, and one for my overlay, overnight. (Clever, yeah?)
The LogJam fork is to create a sane base for Gentoo and other distributions to get an up-to-date version of LogJam without having to maintain a huge patchbase. I was delving into the Fedora patchset; they had a few dozen they maintain for their RPMs. Once I'd finished updating my fork, submitting an upstream pull request was as easy as clicking a button and adding a short note. Awesome!
GitHub does nifty graphs about which sources have ties to other projects, as well as commit history charts. The downside is that since there's lots of javascript and Flash powering the site, responsiveness can suck.
So, why choose GitHub? For all the reasons so far, plus the fact that there are a lot of Gentoo projects on there already, including other overlays. And LogJam upstream's already on there, which really makes it easy to interact via the web interface.
Now, I should mention that I'm not married to GitHub or anything. In fact, I've registered an account at Gitorious, too, just in case I switch. Or if I want to have separate/mirrored projects at both websites.
I'm even thinking of git hosting some of my other personal projects, like night-sources. You know, stuff that needs organization. However . . . the problem I have with GitHub is that binary file hosting SUCKS. Lemme say that again: it's terrible. Really bad. There's no such thing as a static, canonical file name for a given archive, like you'd expect from SourceForge or Gna! or similar. Instead a small commit hash is appended to every file name, which is just ugly.
Let's say that I have a kernel patchset (labeled only by a version number) that I distribute in an ebuild's SRC_URI. I can't just call it ${PV}.tar.bz2; it has to be something like ${PV}-36x746avF.tar.bz2. The maintenance for each subsequent ebuild version goes up, because you have to change SRC_URI every single time, which takes away the flexibility of using variables in the first place!
Now, I understand that with GitHub, supposedly the hashname increases security, as you'll always know which commit it's from. Same for which branch, etc. However, it's also unnecessary, because the version number is right there in the file name. It'd be nice if you could always get individual tarballs the way you're used to:
2.6.22.tar.bz2
2.6.23.tar.bz2
2.6.24.tar.bz2
. . . instead, you'll get a bunch of random crap, appended to a really/long/tree/master/ URI.
So GitHub, if not git itself, is not ideally suited for binary packages, be it tarballs, image files, PDFs, etc. Lots of stuff cluttering up the path, and I have no clue if it can actually be removed. None of the support conversations I read on GitHub had a fix, either.
So I'm still looking for a good alternative. I may just have to keep everything in my devspace. As much as I'd like better organization of, say, night-sources (like the genpatches team has), I don't want to deal with those kinds of weird versioning issues.
Docs
In spite of CIA being down for some time and losing lots of commits, I've done a fair amount of docs work in recent days.
Yesterday I spent awhile bringing the Printing Howto up-to-date for HPLIP, as well as fixing all the kernel config and usergroup info. There are also a buncha updates I made to the Openbox Guide; all patches were supplied by Nate. (Thanks!)
The Localization Guide also some some luv; I pruned the old section on using localedef with the real way to generate locales, localegen. This stuff was already in our other documents, including the handbooks, but somehow I just missed this one.
The Portage handbook received some updates for automatic block resolution, as well as using examples for packages that are still in the tree. Not all the commits I make are huge rewrites; some of them are small but really helpful. The Gnome Guide, for example, lacked explicit instructions to follow the Xorg setup doc before installing Gnome.
Now, it is possible to install Gentoo and then immediately go right to installing Gnome. However, you may end up with a few misconfigured or missing bits along the way. New users would probably not know what to do next, so by adding this short note about required configuration, hopefully some of those pitfalls can be avoided.
Xfce
Almost forgot this month's Xfce desktop! I found a really neat wallpaper, and started looking for some gtk+ themes with similar colors, to save me the trouble of creating one myself.
I decided to redo my desktop in a general Elegant Brit theme. I also decided to try out the Cairo Dock ebuilds. (These were originally from the desktop-effects overlay, but I brought 'em up-to-date and submitted a pull request to the maintainers. Git makes collaboration easy!)
I later unmerged Cairo-Dock, as I found it to be very unstable and buggy. Even now, DBUS and DBUS-apps still aren't working correctly, as not all of them can use the notification area anymore. Lame!
icons: Area o.43
gtk+: Elegant Brit (Pixmap and Mist engines)
xfwm4: Rezlooks-gtk (yes, it is confusingly named)
background: night launch
I rolled my own icons for Cairo-Dock, using a mix of Brit-inspired stuff from gnome-look.
The uncluttered version that shows off the wallpaper:
I cropped it from the original at APOD. That was the last planned night launch of the Space Shuttle before it's retired at the end of the year. Neat!
* * *
See at at SCALE, on Saturday!
Kernel and nouveau updates
In the midst of my Beagleboard frustrations, I actually have a bit of good news to report.
No, it's not about the Beagle. That's still a big ol' pile o' poop.
First is that I was digging around in the X11 overlay, and I found out what I was missing to make xf86-video-ati and KMS work on recent kernels: x11-drivers/radeon-ucode. There are a few extra steps for getting the firmware into your kernel config, but it doesn't take long.
So now I'm finally able to use vanilla-sources 2.6.33_rc7. I'd been stuck on vanilla 2.6.32 -- no additional point releases, just .32. Every other .32 release had major regressions that prevented booting.
Running .33 makes me happy. I get the newest goodies (no more need for staging drivers) and Urban Terror still runs great. KMS is even a teensy bit faster, too.
However, then I went back to using stuff from the staging drivers tree: I decided to try out Nouveau tonight. Once again, I used the ebuilds from the X11 overlay, and recompiled my kernel. To my surprise, things mostly work! In fact, I'm writing this blog post from within Xfce, running on Nouveau + KMS.
Turns out that Nouveau doesn't really work on Geforce 8200/8300 cards, and possibly not on any IGP with shared memory. This is a known bug -- in fact, I tried out Nouveau hoping to add some current testing results.
While KMS works okay (a little slower than radeon), and I can get into X just fine, performance is pretty slow once I get there. Xfwm4's compositor is enabled, but that's not a source of trouble. As I stated on the bug, it's better than the proprietary nvidia-drivers, but definitely laggy. No hardware acceleration at all.
I jumped on to #nouveau to see what caused my cryptic error messages. It's not the firmware loading that's the problem, the problem is that the acceleration code has yet to be written for my IGP.
This just confirms what I've suspected ever since I purchased my motherboard in October 2008: its chipset is absolutely good-for-nothing. My system is unbearably stutter-slow when using the proprietary nvidia-drivers, which means desktop usage is out, to say nothing of games or VDPAU decoding for movies. And the nv driver still doesn't work at all, and it wouldn't have any kind of hardware accel anyway. The last hope, Nouveau, is sorely lacking, so I'll just have to cross my fingers that some kind of support arrives before the 'board is replaced.
I guess it's back to my RadeonHD 4550: 3D and 2D are accelerated etc. Could still use power management code, and GL output or some other hardware decode logic for movies, but I've no real complaints. Those are all coming, fo' sho'.
I'm interested in getting an AMD chipset-based motherboard, but every benchmark I've ever seen shows poor USB, SATA/AHCI, ethernet, and other peripheral performance compared to an nVidia chipset. That's disheartening; I'd really like to go all-AMD. As long as there's a 4000-series IGP on the board, I could even ditch the low-end 4550 I currently use and save some power and heat. There don't seem to be many decent cheap options for microATX AMD motherboards these days.
Besides, aside from the nVidia IGP issues, I've no real complaints about my current mobo. You win some, you lose some.
Web developers and contributors needed for xfce.org
This post is the first (well, second if you count the one for Xfce4 Screenshooter) of a series of post offering some ways to get involved in Xfce. We need more people if we want to keep improving Xfce!
We are looking for new persons to help us to take care of the Xfce web site. We need a web developer/designer to handle the technical details and someone to improve/update the contents (can be the same person).
Our web site runs a home made PHP based CMS (with no online interface) which we would like to keep (improvements and bug fixes are welcome of course) for the time being. Though, its contents needs some love: some pages are strongly outdated, the style could be refreshed, some pages still use tables for layout, etc. We also need to find a solution for localization: the current system requires the user to translate raw PHP pages and often leads to errors when going live, up to the point that we are considering dropping translations. This will highly depend on the people who get involved in the web site.
The web developer position requires a good PHP, HTML and CSS knowledge to be able to handle the different aspects of the web site. A good command of English to update/rework the different pages and make the web site easier to use, this also requires to follow the Xfce development to update the web site accordingly. Of course, this work can be done as a team if several persons step in. This is a good opportunity to start contributing to the Xfce project and this work will be appreciated by a lot of Xfce users.
Please contact me if you are interested. Thank you in advance!
Xfce4 Screenshooter 1.7.9 – Looking for a new maintainer
I recently released Xfce4 Screenshooter 1.7.9. This is a release candidate for the 1.8 branch. It contains a great number of new improvements and bug fixes, listed below.
I recently started to contribute more to the Xfce core, particularly Xfce4 Session and Xfce4 Settings (I'll try to blog more about that later), which leaves me very little time for Xfce4 Screenshooter. I would like to find someone to take over the maintenance of this projet, if you feel motivated please contact me (jeromeg@xfce.org or jeromeg in #xfce on freenode). Obviously, some basic knowledge of English (to communicate with the rest of the Xfce team and to develop the UI) and knowing C is required. If you are not used to the gtk/glib API, I'm ready to do some mentoring during a transitional phase. Anyway, I would be happy to explain the current code organization, the main issues, the weak areas, etc. This is a good opportunity to join a nice community which needs more contributors to keep rocking!
**Edit**: Bruno Ramos kindly volunteered for this! \o/ For other people interested in contributing, I'll post in the next few days on a few Xfce goodies which need a new maintainer. Please also remember that patches for bugs opened in the bugzilla are a great way to start contributing. Do not hesitate to join #xfce on freenode if you have any questions.
Changelog
- The XMLRPC-C dependency has been replaced by libsoup.
- Gtk 2.14 is now required to compile.
- Switch to a non-recursive Makefile.am. This reduces the build time and centralizes the build information.
New features
- Scrolling the panel plugin button changes the area to be captured.
- When compositing is on, use a nice partially transparent rubber-banding, still needs some polishing.
- F1 opens the help page.
- Automatically fill the title and comment fields in the ZimageZ upload information dialog.
- Make enter validate the upload in the ZimageZ upload information dialog.
- Use the XDG image directory as the default directory for saving screenshots. If it does not exist, fall back to $HOME.
- Major interface rethinking. This new interface is based on a suggestion by Yves-Alexis Pérez. The former main dialog is split into two dialogs: one for selecting the region to be captured and the delay, while the second one displays a preview of the screenshot and lists the available actions. The main application shows the first dialog, then the second one. If one of the region CLI options is given, the screenshot is taken accordingly and the second dialog is displayed. The panel plugin uses the first dialog as a configuration dialog. When you click the plugin, the screenshot is taken and the second dialog is shown.
- Allow drag and dropping of the preview to other applications in order to paste the screenshot (Mike Massonnet).
Bugs fixed
- UTF-8 characters in user name or password caused a login failure.
- Fix all warnings triggered by running autogen.sh.
- Fix the ZimageZ upload when behind a proxy.
- Fix copying of links in the ZimageZ upload finished dialog.
- Fix 100% CPU usage when selecting a region in a non composited environment (spotted by Gauvain Pocentek).
- When capturing a window with rounded corners, don't capture the background of the window but make the screenshot transparent instead.
- Make sure the save folder in the panel plugin preferences is valid.
- Don't show the copy to clipboard option in the application if no clipboard manager is running as the screenshot won't be preserved after closing the application anyway in that case.
- Allow xfce4-screenshooter -r to be used as a command for a keybinding.
- Allow silent build.
- Fix most pre-build warnings.
- Escape screenshots path when opening them with an application.
- Plug some leaks in the application and in the panel plugin.
- Do not accept conflicting CLI options. Warn the user when he uses CLI options which are not coherent.
- Correctly save preferences, even if the rc file does not exist (Mike Massonnet).
- One second is now the minimal delay when using the interactive mode. This caused the screenshooter dialog to be partially displayed on the screenshot in some cases.
- A lot of updated translations for the application, the panel plugin and the documentation. Thanks to the Xfce translation team!
Screenshots can be found on the homepage.
Xfce 4.8 Schedule Changes
As the Xfce release manager, I’d prefer to be the bringer of good news. Unfortunately, we have to make some adjustments with regards to the Xfce 4.8 release schedule.
You may well remember last year’s chaos with the 4.6 release date. We’re trying our best not to repeat that and if it should happen again, we’ll at least keep you posted about the issues as good as we can.
So, what’s the deal with 4.8?
One thing that hasn’t changed much is that our development team is very small. A hobby project of this size requires a certain amount of time to be invested by each individual developer. Time not everyone has as much has he would like to dedicate to Xfce.
Today, Brian announced his absence for the coming months due to his new job, leaving 2-3 of our core components (xfdesktop, xfconf and xfce4-session) more or less unmaintained (aside from bugfixes). The good news is that Jérôme (who has recently started to improve xfce4-settings and port xfce4-session to libxfce4ui) and Daniel (the maintainer of the thunar-shares-plugin) have offered their help with xfdesktop and xfce4-session.
Brian is not the only one having little time at hand though. I’m preparing myself for my final university exams, so ideally I’d be sticking my nose into lecture notes all day long. I still have the time to write mails like this but there hasn’t been much activity around thunar and related projects lately.
Again, I’m really happy to see people volunteering to help because that’s what we need right now. There’s a lot left to do before we can release 4.8. Let me get to that now.
As some of might have heard, thunar was ported to GIO this summer. Through GVfs, GIO brings new features such as SMB, SFTP, FTP browsing which some people use one a daily basis already. Now, GVfs has turned out to be problematic for us for various reasons. At first it shipped a HAL-based volume monitor with a hard-coded dependency on gnome-mount. Today it ships a volume monitor based on gnome-disk-utility (uses DeviceKit-disks itself) which proves to be inconsistent and somewhat incompatible to the HAL mounting code in exo.
The result: thunar-volman (not part of the core but important for thunar nonetheless) and xfdesktop will have to be ported to udev (the mounting being done with GIO, ideally). I’ve started working on this but this is far from being finished.
Question to the other developers: Didn’t xfce4-session use HAL for logging out and stuff? We might have to look into replacing those portions of code with something based on ConsoleKit, I guess?
HAL/udev is not the only issue however. With Xfce 4.8 we’ll be replacing libxfcegui4 with a new library called libxfce4ui. Not all core applications (again, xfdesktop being one of them, I think) have been ported to it yet. In most cases, this is no big deal and probably could be resolved within a few days though.
Then we have garcon, the much improved menu library that is supposed to replace libxfce4menu. At the time of writing the only feature it is lacking that is crucial for 4.8 is file system monitoring. We’ll probably implement basic monitoring like we had in libxfce4menu. Work on this hasn’t started yet.
Also, xfdesktop needs to be ported not only from ThunarVFS/HAL to GIO/udev but also from libxfce4menu to garcon.
So, as you can see there is quite a lot of work ahead of us. Taking into account the little free time some of us have these days, we’ve decided to postpone the 4.8 release until June 12th instead of April 12th. The entire release phase in our schedule has been moved by two months in time, as you can see on the official schedule wiki page:
http://wiki.xfce.org/releng/4.8/schedule
To be honest, I wouldn’t consider this new date fixed either. It all depends on how much we can do until the feature freeze on April 1st. I’m optimistic that meeting the deadlines is possible though.
For all of you who can’t wait until June, try out our development releases which are announced on http://identi.ca/xfce. I have at least something good to share: For a few weeks now I’ve been running Fedora 12 with a mixture of Xfce 4.6 packages and development package from the upcoming 4.8 series and the new components have proven to be very stable already.
I’m especially happy about the new panel which works almost flawlessly (except for a few dual head issues) and not only supports real transparency and more comfortable launcher creation based on garcon, but is also compatible to panel plugins written for Xfce 4.6. (Good work, Nick!)
So, I guess this is it. A mixture of good and bad. I hope nobody is too disappointed. As always, we’re doing the best we can.
Cheers!
The download manager is in the wild
So it's finally done, it took very long, but it's done. The download manager I once had in mind is taking off into the wildness :-) Of course it took long because I never did something with it, writing a front-end to wget/curl isn't interesting -- who cares about downloading HTTP/FTP files when the web browser handles it for you anyway -- and reusing GVFS doesn't make sense cause really you don't want to download from your trash:// or whatever proto:// and again only HTTP/FTP is not interesting. Not at all. I have come across Uget and other very good projects but most of them are either writing the code to handle the protocol like HTTP and/or are looking forward to handle more interesting protocols like BitTorrent. I think it's a very tough job that demands too much for a one-maintainer project. Recently I saw the new release of aria2 that comes with an XML-RPC interface and this took all my interest during 4 days. I believe this utility is very promising and I had really like to write the good and user-friendly XML-RPC GUI client that it seems to be missing!What is so exciting about aria2? In case you know the project you don't have to read, but it is worth mentionning the features of this small utility. It supports HTTP(s)/FTP but also BitTorrent and Metalinks. It is widely customizable for each specific protocol. It can download one file by splitting it into several pieces and using multiple connections and even mix HTTP URIs with BitTorrent and by the same time upload to BitTorrent peers what has been downloaded through HTTP. So this has to be the perfect candidate to write a nice download manager, hasn't it?
The client is a very first version that I intended to code name draft although the release assistant on xfce.org doesn't allow this. Instead it will take the more neutral road of 0.1.0 to 0.1.1 etc until 0.2.0 followed by stable fix releases.
Why draft? Simple. It's being written with a higher level language than C but not even Vala :-) High-level languages are a great deal when starting a new application, as you can type more and get more, instead of typing like a dog for a rocking hot, well lousy, window. Since I do like Ruby, it's being written in Ruby currently, and it depends on the ruby-gnome2 project for the bindings. To get a picture, a main file to open a window takes 3 lines. Of course the final version is meant to be written in Vala/C, but I still need to convince myself that Vala+libsoup isn't an option that is going to waste too much time. Also at first glance libsoup looks easy to use, it allows to build XML-RPC requests, to request the HTTP bodies and to send messages, but it is not an XML-RPC client and you never know how well the Vala bindings will play. This means extra attention for small things. Starting an application from scratch with such constraints are usually a big time-killer therefore using like in this case an existing XML-RPC client is very important. The GUI is done with Glade in GtkBuilder format and reusing it into a new language will be pretty easy.
So what's next? I'll just wait for some feedback see what the audience thinks about it, if at all, and polish here and there. Keep tuned for the next update.
