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.

Now that version numbers are meaningless for Firefox users, Mozilla refers to their latest milestone simply as new version.

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 resultant 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.

Now that Battle for Wesnoth 1.9.6 has been tagged, we can once again focus on the future!

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.

While I had read Rhonda’s post on the matter of Debian Sid’s status as “not for end-users” back in the day, I was not aware that it was just one side of the coin. Now that the puzzle is complete, I thought I’d share a couple of links with my vast, intelligent audience:

• 5 Reasons why Debian Unstable does Not deserve its Name
• 5 Reasons why Debian Unstable is Not for End-Users

Pay attention to the post dates, and don’t forget that both authors are Debian Developers.

Incidentally, at the time I read the last post (i.e. the same day it was published) I was already using Debian Sid, although in middle of Squeeze’s feature freeze. I didn’t pay much attention to the comments after it popped up in my feed reader, so I kind of missed the context.

Some broken forum or email client software have the nasty habit of prepending “Re:” to the subject field of messages that are intended as a response to previous ones, without checking whether this prefix is already in place, which is the case when you are replying to another user’s response to the thread.

If you have one of those broken messaging clients, replace it. If you are using one of those broken forum boards, you have two options:

• The user option: fix your subject field by hand and bug the administrator about it, whom I encourage to take:
• The admin option: check whether there’s a fix for the software you run in your site; bug the developers to release a patch fixing this behavior, or (in the worst case) switch to a better solution.

You can avoid making yourself look like an idiot if you follow these few simple steps! Please! No-one wants to read a message with a title full of ReReReReReRes, or visit a site filled with such posts! It’s up to you to save the Internet from this horrendous disease!

Duke Nukem Forever is being released at last, and some parts of the world already got it. U.S.A. will have to wait till next Tuesday.

I just want to say that I always knew it’d happen. I never used DNF as a measure of project completion probability, not even once. Nonetheless, I thought I’d note that, in no particular order, all the following things did not happen before DNF’s release:

• World domination by me
• The Year of the Linux Desktop
• GNU/Hurd 1.0 (you’ve got to give them credit for admitting their defeat, though)
• The release of Microsoft Windows’ core frameworks as open source software
• After the Storm version 1.0
• Commander Keen: The Universe Is Toast Screw that, Ceilick and his team did manage to complete an awesome unofficial trilogy
• Invasion from the Unknown version 2.0
• Battle for Wesnoth 2.0
• Ubuntu Linux 17.04 “Zany Zebra”
• Rei 2 IRC Bot 1.0
• Mesiga 1.0
• The end of Microsoft
• 2012 (no, not the movie)
• Google Chrome 69.0
• World domination by Linus
• Waldo being found for good
• Reicore Mk. II
• Linux kernel 3.0 (the RCs don’t count!)
• Irssi 1.0
• Rapture
• Evangelion 3.0
• Evangelion: Final
• Complete OpenGL 3.0 support in Mesa DRI/DRI2 drivers
• World domination by TV Tropes
• Invasion from the Unknown being merged into mainline Wesnoth
• The completion of the current Order of the Stick story arc (strips #673 - ???)
• The GNU General Public License version 4
• The end of the freenode IRC network
• phpBB 3.1
• World domination by Wikipedia (that’s no moon…)
• Debian GNU/Linux 20.0
• Contact with extraterrestrial intelligence (or did it?)
• Frogatto 2.0
• World domination by Lady Gaga
• Wesnoth-UMC-Dev SVN commit r10000
• Reiser4 being merged into mainline Linux
• ReactOS 1.0
• SuperTux 1.0
• Microsoft Windows 13 14
• World domination by Tommy Wiseau

… and many, many other things that would be totally cool to have now.

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.

Let us never speak of this again.

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.

<shadowmaster> Ivanovic: 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?
<shadowmaster> (garbage that goes away once the window and its shadow are actually drawn)
<Ivanovic> yeah
<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!