Since I’ve not felt particularly inspired to finish the last two parts of my review of the Under the Burning Suns campaign’s post-quartex (1.3.x - 1.9.x) development history, I suppose I may as well bother my loyal readers with yet another useless report on GUI2 dialog conversions in Wesnoth trunk.<
Okay. I lied. The screenshot above does not come from Wesnoth trunk, but from its fork in a private branch in my local git-svn repository. The component in question is evidently the File Chooser dialog, which is used in the map editor for locating files to open or save, and in the Preferences dialog (and more rarely in the MP menu) for finding the wesnothd or wesnothd.exe MP server binary used to host LAN games.>
I figured that converting the File Chooser to GUI2 will help stomp a few bugs with files whose names look like the obsolete, so-called “WML markup”, and generally make it easier for people to improve it. Once I have reimplemented the current functionality I may look into adding some kind of bookmarks system, or at the very least shortcuts for jumping to directories that are commonly used by both mainline developers and UMC authors.
All this rewriting may also introduce new bugs, of course; hence I’ve not pushed these changes to trunk, even though they are already guarded by the --new-widgets command line switch. I have not pushed them to a public SVN branch either because local Git branches make it much easier to rebase commits against trunk as time goes on.
In the process I found myself in need of converting the New Folder dialog to GUI2 for consistency. Given the sheer size of the C++ code added in the process, I am pretty sure this won’t inconvenience anybody for now — hence I pushed this changeset directly to trunk instead.
(And yes, it should be “New Directory”. I am going to hate myself for the rest of my life for keeping the legacy “user-friendly” terminology that was already in place.)
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.
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.
For those of us who were wondering whether the Battle for Wesnoth team would release another revision of the latest stable branch, today we have definitive confirmation that version 1.8.6 will, indeed, come to life very soon, as the release manager has just informed us in the developers’ mailing list:
Currently I consider tagging 1.8.6 maybe on Wednesday next week. Please ping me ASAP if you got anything I should be waiting for (and obviously tell me what it is). Yes, I think that 1.8.6 will really be the last 1.8.6 release.
It should be pointed out that the necessity of another stable release was decided back in February during FOSDEM, after evaluating the current status of 1.10’s development.
An incomplete list of changes can be found in /branches/1.8/changelog from the SVN repository. Some noteworthy code changes as of this writing include:
Fixed transparent portraits not supporting image modifications
ANL: Awarded correct amount of research to units. (Fix for bug #17406, patch by kernigh.)
Remove useless debug output introduced in r42226
Fix loadscreen progressbar "bleeding" on the old MP lobby when running with -s switch
Fix for bug #17573: wesnoth unusable with certain combinations of glibc and sdl due to changes in memcopy
Rework MP chat log as a GUI2 dialog with colored display of messages
Apparently the people at Mozilla finally decided to give their last Firefox release a try on a Linux/Gtk+ configuration other than Ubuntu 10.10’s default, or some diligent user reported to them how awful the new interface looks to the rest of the world who’s not using Windows. In any case, I seem to be receiving new builds through their beta channel, and a few hours ago I got my hands on Firefox 4.0.1 “beta” build 1, whatever that means.
The following picture should speak by itself: (Hint: look between the Firefox button and the toolbar.)
Before switching to Mozilla Firefox 4’s builds from the Nightly (Minefield) channel some time around mid-2010, I used to follow closely the blog of one of the Debian Iceweasel maintainers, from which I got goodness such as updates on the status of Iceweasel 3.6 for Debian Sid/Squeeze in Experimental, that I used for a while.
Turns out that this night after Firefox 4.0.1’s update, I decided that the “Firefox button” should match the Oxygen window decoration in style — because I’m that crazy. I took the ~/.mozilla/firefox/<session>/chrome/userChrome.css modifications from the blog post and played around with various combinations until I produced something marginally uniquer.
#appmenu-toolbar-button>.toolbarbutton-text{
/* oxygen "carved" effect */
text-shadow:0px1px0pxwhite;
/* bold */
font-weight: bold;
}
I am actually afraid of messing around with the many possibilities of XUL/CSS styling further, lest I spend the rest of the month producing my own full-fledged Firefox theme. The fact that I can handle CSS makes this all the more worrisome.
