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!
Eatmonkey 0.1.3 benchmarking
Eatmonkey has now been released for the 4th time and I started to use it to download videos from FOSDEM2010 by drag-n-dropping the links from the web page to the manager :-)I downloaded four files and while they were running I had a close look at top and iftop to monitor the CPU usage and the bandwidth usage between the client/server (the connection between eatmonkey and the aria2 XML-RPC server running on the localhost interface).
I had unexpected results and was surprised by the CPU usage. It is very high currently which means I have a new task for the next milestone, getting the CPU footprint low. The bandwidth comes without surprises, but since the milestone will target performance where possible I will fine down the number of requests made to the server. This problem is also noticeable in the GUI in that it tends to micro-freeze during the updates of each download. So the more active downloads will be running the more the client will be freezing.
Some results as it will speak more than words:
| Number of active downloads | Reception | Emission | CPU% |
|---|---|---|---|
| 4 downloads | 144Kbps | 18Kbps | 30% |
| 3 downloads | 108Kbps | 14Kbps | 26% |
| 2 downloads | 73Kbps | 11Kbps | 18% |
I will start by running benchmarks on the code itself, and thanks to Ruby there is built-in support for Benchmarking and Profiling. It comes with at least three different useful modules: benchmark, profile and profiler. The first measures the time that the code necessitated to be executed on the system. It is useful to measure different kind of loops like for, while or do...while, or for example to see if a string is best to be compared through a dummy compare function or via a compiled regular expression. The second simply needs to be included at the top of a Ruby script and it will print a summary of the time passed within each method/function call. The third does the same except it is possible to run the Profiler around distinctive blocks of code. So much for the presentation, below are some samples.
File
benchmark.rb:#!/usr/bin/ruby -w
require "benchmark"
require "pp"
integers = (1..10000).to_a
pp Benchmark.measure { integers.map { |i| i * i } }
Benchmark.bm(10) do |b|
b.report("simple") { 50000.times { 1 + 2 } }
b.report("complex") { 50000.times { 1 + 2 - 6 + 5 * 4 / 2 + 4 } }
b.report("stupid") { 50000.times { "1".to_i + "3".to_i * "4".to_i - "2".to_i } }
end
words = IO.readlines("/usr/share/dict/words")
Benchmark.bm(10) do |b|
b.report("include") { words.each { |w| next if w.include?("abe") } }
b.report("regexp") { words.each { |w| next if w =~ /abe/ } }
end
File
profile.rb:#!/usr/bin/ruby -w
require "profile"
def factorial(n)
n > 1 ? n * factorial(n - 1) : 1;
end
factorial(627)
File
profiler.rb:#!/usr/bin/ruby -wUpdate: The profiling showed that during a status request 65% of the time is consumed by the XML parser. The REXML class is written 100% in Ruby, and that gives a good hint that the same request done with a parser written in C may present a real boost. On another hand, the requests are now only run once periodically and cached inside the pooler. This means that the emission bitrate is always the same and that the reception bitrate grows as there are more downloads running. And as a side-effect there is less XML parsing done thus less CPU time used.
require "profiler"
def factorial(n)
(2..n).to_a.inject(1) { |product, i| product * i }
end
Profiler__.start_profile
factorial(627)
Profiler__.stop_profile
Profiler__.print_profile($stdout)
Eatmonkey 0.1.3 benchmarking
Eatmonkey has now been released for the 4th time and I started to use it to download videos from FOSDEM2010 by drag-n-dropping the links from the web page to the manager :-)I downloaded four files and while they were running I had a close look at top and iftop to monitor the CPU usage and the bandwidth usage between the client/server (the connection between eatmonkey and the aria2 XML-RPC server running on the localhost interface).
I had unexpected results and was surprised by the CPU usage. It is very high currently which means I have a new task for the next milestone, getting the CPU footprint low. The bandwidth comes without surprises, but since the milestone will target performance where possible I will fine down the number of requests made to the server. This problem is also noticeable in the GUI in that it tends to micro-freeze during the updates of each download. So the more active downloads will be running the more the client will be freezing.
Some results as it will speak more than words:
| Number of active downloads | Reception | Emission | CPU% |
|---|---|---|---|
| 4 downloads | 144Kbps | 18Kbps | 30% |
| 3 downloads | 108Kbps | 14Kbps | 26% |
| 2 downloads | 73Kbps | 11Kbps | 18% |
I will start by running benchmarks on the code itself, and thanks to Ruby there is built-in support for Benchmarking and Profiling. It comes with at least three different useful modules: benchmark, profile and profiler. The first measures the time that the code necessitated to be executed on the system. It is useful to measure different kind of loops like for, while or do...while, or for example to see if a string is best to be compared through a dummy compare function or via a compiled regular expression. The second simply needs to be included at the top of a Ruby script and it will print a summary of the time passed within each method/function call. The third does the same except it is possible to run the Profiler around distinctive blocks of code. So much for the presentation, below are some samples.
File
benchmark.rb:#!/usr/bin/ruby -w
require "benchmark"
require "pp"
integers = (1..10000).to_a
pp Benchmark.measure { integers.map { |i| i * i } }
Benchmark.bm(10) do |b|
b.report("simple") { 50000.times { 1 + 2 } }
b.report("complex") { 50000.times { 1 + 2 - 6 + 5 * 4 / 2 + 4 } }
b.report("stupid") { 50000.times { "1".to_i + "3".to_i * "4".to_i - "2".to_i } }
end
words = IO.readlines("/usr/share/dict/words")
Benchmark.bm(10) do |b|
b.report("include") { words.each { |w| next if w.include?("abe") } }
b.report("regexp") { words.each { |w| next if w =~ /abe/ } }
end
File
profile.rb:#!/usr/bin/ruby -w
require "profile"
def factorial(n)
n > 1 ? n * factorial(n - 1) : 1;
end
factorial(627)
File
profiler.rb:#!/usr/bin/ruby -wUpdate: The profiling showed that during a status request 65% of the time is consumed by the XML parser. The REXML class is written 100% in Ruby, and that gives a good hint that the same request done with a parser written in C may present a real boost. On another hand, the requests are now only run once periodically and cached inside the pooler. This means that the emission bitrate is always the same and that the reception bitrate grows as there are more downloads running. And as a side-effect there is less XML parsing done thus less CPU time used.
require "profiler"
def factorial(n)
(2..n).to_a.inject(1) { |product, i| product * i }
end
Profiler__.start_profile
factorial(627)
Profiler__.stop_profile
Profiler__.print_profile($stdout)
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.
Backward compatibility for Ruby 1.8
As I'm currently writing some Ruby code and that I started with version 1.9 I felt onto cases where some methods don't exist for Ruby 1.8. This is very annoying and I started by switching the code to 1.8 method calls. I disliked this when it came to Process.spawn which is a one line call to execute a separate process. Rewriting it takes around 5 lines instead.So I had the idea to reuse something I already saw once. I write a new file named compat18.rb and include it within the sources that need it. Ruby makes it very easy to add new methods to existing classes/modules anyway, even if they exist already, so I just did it and it works like a charm.
Here is a small snippet:
class Array
def find_index(idx)
index(idx)
end
end
class Dir
def exists?(path)
File.directory?(path)
end
end
Update: It can happen that a fallback method from Ruby 1.8 has been totally dropped and replaced against a new method in 1.9, and in this case the older method has to be checked if it exists, and otherwise make a call to the parent.
class Array
def count
if defined? nitems
return nitems
else
return super
end
end
end
Fed up with Moblin
I slowly begin to be fed up with Moblin, the base installation. The base system starts way too often with core-dumps (crash on mutter f.e. which also means X restarts), but mainly because of RPM. When package-kit starts to check for an update — or when you do any installation/upgrade with yum e.g. you use rpm directly or indirectly — the whole system goes unusable, the browser acts like it is frozen, it takes very long to switch between tasks, and all of this for at least a minute up to an hour if you accept to run an update. You can call this whatever you want, I call this a big fail.This happens on an Acer Aspire One 9", where I guess they installed the cheapest SSD out there.
In fact things were getting really bad when I switched to an Xfce session, I received unbelievable long startup times. Uxlaunch, the new automatic login application on Moblin 2.1, is totally uncooperative. The Xfce session ends launching many tools and applications twice, two corewatcher-applets, two connman-applets, etc. Uxlaunch will run xfce4-session, but also executes the same desktop files — as it seems after a quick look in the code — from the autostart directory, which is a role taken by the Xfce session manager.
So I have been looking around to finally throw away some junk.
Now I have been looking close at the autostart applications since the "all-in-twice" fiasco to get this netbook fast again. Of course you have to know what you do, this kind of tasks isn't open to people without technical skills. First I changed the default "desktop" to Openbox, by downloading the RPM source package, compiling it and putting it inside the uxlaunch configuration file. Then I have been removing some base packages and manually hiding some desktop files to avoid them to autostart — I have been playing with the Hidden/NoDisplay key but it didn't have any effect on uxlaunch so it ended with a chmod 000 command.
I dropped four packages, kerneloops, corewatcher and obexd/openobex. I really don't want them around anymore. And I "dropped" seven autostart files, ofono which depends on a lot of applications, the bkl-orbiter, and the rest are Moblin panel related applications, bluetooth-panel which I don't even have on this netbook, carrick-panel as I use connman-applet which works at least for an automatic connection, two dalson applications dalson-power-applet and dalston-volume-applet, and at last moblin-panel-web.
I kept the gnome-settings-daemon although I have the Xfce settings daemon installed which I do prefer at some extends. And after all this I changed the GTK+ and icon themes through the gconf keys. And what's the conclusion? Moblin is nice, but I managed to munch it and enforce my desktop.
Update: After running under OpenBox I feel that my remark toward RPM is wrong, I don't know maybe it is the mixed use of OpenGL that makes the tasks taking ages to react. All in all, the default desktop environment is something where you must know about patience :-)