The announcement that Mozilla was switching to a “rapid” release cycle did not entirely catch me by surprise back in the day. With the advent of Google Chrome to rekindle the fire of the Browser Wars a couple of years ago and its significant contribution to the general adoption of HTML5, I knew Mozilla Firefox 4.0 would have little to offer that wasn’t already the standard in Chrome.
It’s kind of sad to see those who were once pioneers in open-source web technologies development — in no small part thanks to Microsoft Internet Explorer and the death of the formerly glorious Netscape Navigator — now relegated to following in the footsteps of the youngest actor in the market, an actor which really just took Apple’s Webkit library as a building foundation and released the resulting project under one (if not the one) of the most recognizable brands of the Internet.
As far as I understand the roadmap for Firefox 6 and 7, there’s very little in terms of user-visible features ahead this year, and most improvements are either bug-fixes (like in good old point releases), HTML5 crap or minor polishing. That is not to say that I don’t welcome any performance improvements, but I think that the Mozilla folks need to come up with something really new and unique if they don’t want to see their market share drop to dangerous levels and lose the war to Google’s over-pretentious product.
I’m not exactly the resident usability expert in the Wesnoth development team (multiple people have claimed that title under dubious circumstances before) but I believe I can recognize a design issue when it’s in front of me.
The issue in question is the game’s Preferences dialog. Over time it has accumulated needless cruft in the form of options that no-one should ever need to use, which are nevertheless offered to the player under the Advanced Preferences section. Funnily enough, the programmatic design of this area lends itself to random developers and patch contributors senselessly throwing crap into it; this is the only piece of user-visible configuration that can be defined almost entirely in WML, requiring only a couple of accessor functions in the C++ side for whatever module needs to query or set those options at runtime. In the “best” case, just a single getter suffices.
Of course, Preferences is built upon the previous Wesnothian GUI toolkit jokingly referred to as “GUI1”. Despite what some people may say, it’s far from ideal to work with hardcoded widget locations and an inflexible rendering scheme. As new options have been added to the game, developers have preferred to do things the lazy way and abuse Advanced, leading to arguably essential entries getting clobbered in middle of the rubble.
Naturally, I tried to tell people about this problem. But since it’s been nearly a week and I’ve not gotten reactions of any kind, I decided to start chopping trees.
→
The main thing here is that the Enable scroll tracking of unit actions and Reverse Time Graphics options were moved to Advanced, and in their stead I brought Show Unit Standing Animations and Animate Map, and messed around with some spacing.
With Wesnoth 1.9/1.10 boasting a plethora of standing unit animations and animated terrains, a performance drop is to be expected on low-end machines — or even high-end as well, depending on what other processes are running in the background and local factors such as map size, amount of visible units and possible targets during AI turns. Increasing the visibility of performance impacting options makes a lot of sense if it will result in less complaints. 😉
→
If one looks hard enough, it’s always possible to find other details to nitpick. A little patch went into 1.9.7 to add some indentation and change font sizes for slider labels in Preferences that were associated to checkboxes, but I preferred to leave the follow-up for 1.9.8 — the Sound tab sliders had some overly verbose labels that truly only served to give translators three extra strings to manage.
That said, Preferences still glitches at the bottom on the minimum resolution of 800x480 pixels. The effect can be seen here on the Close button itself. I don’t think I’m able or particularly interested to tame this beast, however, so fixing it may have to wait for the GUI2 redo of the dialog. Meanwhile, OpenPandora users will have to do with this minor inconvenience.
• • •
I should note that my original plan was to completely scrap the Reverse Time Graphics option. After doing some research, I discovered that ESR did it once, and that it got reverted the next day by alink. The rationale? I’m not sure, but the IRC logs are quite entertaining.
After playing around with Debian “wheezy” and getting fed up with X.org 1.10.x, I decided to go back to Debian stable — but not without trying downgrading to X.org server 1.9.2 from Debian Experimental 2010-11-31 first!
It turns out that yes, most of the slowness and pre-paint garbage were caused by the X.org server alone. Sadly, the intermittent shadow glitches are seemingly inherent to KDE SC 4.6 and not to the graphics server.
Annoyed and without the required willpower to file bugs and wait for things to be magically fixed in a few months, I burned a Grml live CD from an ISO I downloaded for no particular reason at all about a week ago (!) and embarked on a journey to wipe out my root file system and restore Squeeze from the pre-ugprade backup in my external hard disk.
It was a successful mision, barring the ensuing breakage caused by the inconsistent versions of GRUB found in /boot and the disk’s MBR.
Whoops.
One chroot and grub-install and update-grub later, Reicore was running Debian GNU/Linux 6.0.1 again, at last. In total, I spent around an hour on the restoration procedure. Cheap.
While it’s true that in previous occasions I have switched to Debian testing awaiting the worst to happen to my computer and at the end it’s all been for the better minus the unavoidable annoyance of having to rebuild some of the software I run without the blessings of a package manager, this time the switch from Debian GNU/Linux 6.0 “squeeze” to “wheezy” (current Testing) surpassed my expectations.
I knew that something would go wrong but I expected it to be a temporary issue of the kind “oops, packager screwed up this build, uploading a fix to Sid shortly”. However, for all I know it’s a more complicated issue that just hit me in the face, and it’s called X.org server 1.10.
Stable uses X.org server 1.7.7, which is well tested and stable and worked well with my hideous mix of newer libraries from upstream (Mesa and libdrm from git master, xf86-video-intel 2.15.0) and in fact provided top-notch performance despite its age.
Some time around the end of 2010 while I was still using Bluecore, I switched to X.org 1.9.x from Experimental, of all things, and didn’t cause any problems with my ATI R6xx-based configuration. I was an idiot and switched to Debian testing now based on my previous experience with X.org 1.9.x instead of considering that the second version number is not attached to bug fixes but features. (A Wesnoth developer is supposed to know better, I know. I’m an idiot and I deserve this.)
Now the jump from Debian Stable to Testing was particularly rough because it’s left me swamped with a lot of bugs that are difficult to describe and leave me in the uneasy position where I’m unable to discern exactly what I should report and to whom.
Following the switch, I restarted X without rebooting and logged into KDE SC 4.4, noticing some annoying issues:
Kwin’s compositing became glitchy, with menu shadows being partially or completely missing at random.
Huge black rectangles or random garbage lines started appearing in place of popup menus or combo box popups for an instant; while the menus/popups are correctly drawn at the end (bar their shadows) the effect is pretty nauseating.
Cairo/Gtk2 applications’ performance went down the sink with compositing enabled.
Frogatto and other GL clients no longer run at near max framerate when compositing is enabled. (Uncannily, this also affects Wesnoth, a pure-software SDL client which I previously had to run under a compositing WM to make it playable at all on Bluecore!)
That was with X.org server 1.10.1. In rage, I grabbed version 1.10.2 from Sid, and KDE SC 4.6. Neither solved it.
I’d like to blame the X.org server itself since using Mesa, libdrm and xf86-video-intel from Debian did not help either. Neither did switching from Linux 2.6.38.8 to 2.6.39.1. All signs point to an issue that’s completely out of my control as a user. To make sure this was the case, I asked Ivanovic in the Wesnoth devs IRC channel about it. For the record, he uses Gentoo and the open-source Radeon stack on an ATI R6xx family GPU, while here I use the Intel stack on a GM45 IGP.
Me: are you using X.org server 1.10.x and KDE SC 4.6 there? do you see some garbage beneath the areas where a window will be drawn when compositing is enabled and very awful gtk2 drawing performance?
Me: (garbage that goes away once the window and its shadow are actually drawn)
Ivanovic: no idea about gtk2 drawing performance
Ivanovic: but yeah to the rest
The drawing glitches are only slightly more bearable when using QtCurve in place of Oxygen and Oxygen-gtk. Using Fluxbox helps with the Cairo/Gtk2 performance loss (which impacts GIMP hard) but not with the menu pre-paint garbage glitch, which seems to not be tied to any window manager, Gtk2 engine or client in particular.
So yeah, I got KDE SC 4.6 as I wanted. Is it an improvement over 4.4? Perhaps — whatever Kwin optimizations have been done in the mean time are pretty much irrelevant right now. Plasma is very dependent upon a graphics server that does shit right, and this is not one of those right now. The new (4.5?) notifications are nice, though.
Of course I really regret the idea of switching to Testing at this point, but I somehow can’t bring myself to nuke it and restore Stable from the pre-upgrade backup snapshot that I still have in my external hard disk. Perhaps I am masochist after all, or I have hopes that this will be solved in the next version of whatever component regressed so hard. Just… don’t try this at home!
It seems that after Roberto Romero abandoned the maintenance of the Wesnoth Spanish Translation team in 2007, it’s all gone downhill.
(Fun fact: it was under his leadership that I contributed my first translations for mainline Wesnoth — my first involvement with a FOSS project ever.)
Some time after he left the team (apparently without previous notice to Ivanovic or Torangan), the translation was taken over by a significantly less competent group that did a very lousy job (read: no quality control) before abandoning it again. Around the end of 2008, I took it over and quickly, with the help of an Argentinian guy who joined me later, brought it to completion in time for the first release of the 1.6 series.
In the process I realized how hard it really is to maintain a complete translation of a large game like Wesnoth.
Due to a series of RL complications, I had to abandon the Spanish translation shortly after Wesnoth 1.6 was released (March 2009). The translation was not taken over by anyone in time for Wesnoth 1.8 (April 2010). Much later in November, though, a new fellow became maintainer and got some work done along with other new collaborators.
Things were starting to look unusually bright because, for the first time in years there was more than one active translator. However, this world full of rainbows and pink unicorns did not last, and it ultimately fell into oblivion following the departure of this last maintainer from the community. No-one took over the team afterwards, and now the Spanish translation is in its natural state once again. The last update in mainline trunk took place in January 2011.
You can have a look at the current situation in gettext.wesnoth.org, our translations statistics website.
It seems that Battle for Wesnoth just doesn’t manage to appeal to many Spanish-speaking people from the FOSS users community to attract new individuals with the knowledge, patience and time required to resurrect an abandoned translation, and the sense of leadership required to coordinate work and keep certain quality standards to attract and, most importantly, keep new translators.
Of course, Wesnoth is a huge undertaking of its own with over one dozen of thousands of strings in mainline and its distinctive approach to storytelling — I know for sure I do not want to work on translating campaigns again, at least, not alone. Still, there are people far more capable than I am for this kind of work, and I do believe our game could really use more publicity among Spanish and Latinamerican players and their contacts.
All the technical fluff relevant for starting to work on an existing or new translation can be found in the wiki, after all.
Today, May 26th, a few minutes past 06:00 AM UTC, after 6 or 7 years of history, the Wesnoth.org favicon has finally been replaced by command of the Art Director on the live website and in SVN trunk, revision 49655, meaning this change is also effective in mainline starting with version 1.9.7 (not yet released).
The differences between both versions are far from subtle, as you can see to the right.
I for one mourn the loss of this significant piece of history that reflects an older, more cartoony art style that was slowly abandoned towards Wesnoth 1.0 and beyond. Until now, this icon also accompanied the owned village counter in the game’s top bar, and served as an indicator overlay for moves affecting village ownership since version 1.4 onwards. Finally, it served for a long time as the village terrain category icon in the Map Editor.
In case anyone requires the old icon for the sake of nostalgia, it’ll be preserved here for your own use under the conditions of the GNU General Public License version 2.
Whatever rules Mozilla Firefox follows to determine the user’s default email client don’t seem to work properly on Debian, at least not when GNOME is not the desktop environment originally installed. For whatever reason, what Firefox tries to do with mailto links and the Send Link context menu option is to open the Evolution mail client, which is not installed with the KDE or LXDE desktop environments.
Fixing this is supposed to be trivial, and it is, but the relevant option is hidden in the worst possible place in Preferences.
Chromium/Google Chrome does not have a user-accessible setting for this, but somehow still appears to get the right idea from the desktop environment.
If you are running Google Chrome 11 or Firefox 4 or later and you know how to find your way through a Unix console OS, here’s something you might want to check out: it’s a Javascript PC emulator running a custom (patched) build of the Linux kernel 2.6.20. Directly. On. Your browser. With Javascript.
Despite Bluecore being back home, I have decided to continue using Reicore as my primary working laptop for all purposes, as it is in much better condition, uses a more Linux-compatible IGP, and doesn’t suffer from uncannily low I/O throughput like Bluecore does.
The ATI mayhem isn’t over, after all.
Reicore’s CPU (an Intel Pentium T4300) does not have hardware-assisted virtualization capabilities, but it seems to compensate what it lacks in technology advances with raw power — surprisingly enough, with little to no increase in heat.
Just now I have finished migrating my Windows XP SP3 virtual machine from the latest Bluecore backup snapshot — something that should have been done the week before the big crash. Windows still runs lightning-fast on VirtualBox 4.0.8 using software virtualization, with low idle CPU usage ranging between 4% and 20%.
An idle Windows session is certainly not the best benchmark, yet compiling Wesnoth RCX in it doesn’t seem to take any additional time in comparison to the Bluecore configuration, the impact on the host’s CPU usage is not significant, and the guest’s responsiveness is unaffected. Then again, at the time Bluecore died, I was not using Linux 2.6.38 and the automatic process group scheduling code (SCHED_AUTOGROUP).
Naturally, the lack of Intel VT-x implies that I won’t be able to virtualize 64-bit operating systems, but for a virtual machine on a host with just 4 GiB of RAM that seems fair enough.
Windows Vista does not seem to represent much of a difference over Windows XP in terms of VM performance.
As for Ubuntu 11.04 “Natty Narwhal”, its performance on VirtualBox is so awful that one would wonder whether VirtualBox’s VM manager code has actually been optimized for Windows guests only.
Sooner than expected, I was notified that Bluecore had been repaired and was awaiting to be retrieved in the support center. Thanks to my never-ending laziness, however, the retrieval did not take place until yesterday.
The verdict was that the screen had to be replaced.
A big problem with this is that I still see the same gray stains beneath the screen’s outer layer that were there back in February the last time I used Bluecore, around the top left corner of the panel, which brings up the question, what did they mean by “screen”?
Whoever did the repairs or testing managed to boot and properly shutdown Linux several times, so my logs indicate that the first successful boot (resuming from hibernation) took place around 15:30 UTC-04:00 (+DST) on April 28th. I’m glad that they figured out how to turn it off from the KDE display manager instead of resorting to wild button pushing.
Since the repairs were effected under an “extended warranty” plan from the store at which Bluecore was purchased, the only mission of the tech support people was to make Bluecore boot again, so everything else (fan, keyboard, etc.) is still in the same crappy conditions, except for the touchpad buttons — oddly enough, the right button is no longer hyper-sensitive to touch and works correctly.
I’d love to know exactly how a screen replacement fixed the laptop or whether it is really possible and valid to replace all display components bar the outer transparent material layers with the aforementioned stains.
