Back to regular business on IRC and Wesnoth for now.
Ever since I got my first laptop, I always wondered what kind of people are actually meant to use the ‘tap’ capability built into touchpads.
I remember being stumped at first when I would try to do normal things (on Windows) only to get continuously interrupted by some unexplained drag-and-drop action or accidental click. There was absolutely nothing anywhere evident explaining that ‘tapping’ was a thing I was expected to do, and in fact, was accidentally doing repeatedly. It took me some experimentation to get the gist of the interface and its configuration, and as soon as I understood it better I went and disabled it.
Later when switching (back) to Linux I would encounter the same issue and I’d have to check the X.org synaptics driver man page to figure out the necessary options to add to
/etc/X11/xorg.conf to get rid of that questionable ‘feature’. Fortunately, nowadays I can just install the
kde-config-touchpad package on Debian and configure everything according to my preferences through a more user-friendly mechanism.
Alas, just like the power button, that laptop’s touchpad buttons were not designed for daily use — thankfully KDE (like Windows) includes a feature to control the pointer with the keyboard.
What touch-based input lacks is intrinsic tactile feedback. Unlike button or key-presses, I cannot feel the action of tapping a touchpad any more than I can feel the action of casually or accidentally sticking my finger on it. A very small amount of pressure counts as a tap, whereas pressing a normal touchpad or mouse button requires a much larger amount, and with good reason; that pressure could be the difference between holding back an embarrassing post and inadvertently submitting it, or (when dragging gestures are enabled) ruining one’s system by dragging half of the Windows system files to the wrong place. Fortunately, most of my experiences in that regard have been of the “cannot drop a folder onto itself” kind.
There is also the issue that not everyone has the common sense to keep their hands clean at all times. Helping other laptop users can be a quite unpleasant experience without a mouse handy — yuck.
And then there are cell phones. Touchscreens are becoming irritatingly common (even in the low-end market) and they are even worse than touchpads in most respects. Sure, you can see what you are going to tap right there, but is that any help against “fat finger” mistakes? Scrolling gestures are a hit or miss action by design, and it is awfully easy to screw up the timing and have the device register it as a tap. These are your time and money in the balance here; you do not want to miss while navigating cell phone menus. And exactly how am I supposed to point other people at some element on the screen without activating it or giving up accuracy and pointing from afar?
In any case, I am pretty sure I do not want to be forced to use a touchscreen-driven phone to call an ambulance.
The obscene joke that is Windows 8 was clearly intended to push OEMs to produce more and more touchscreen-based garbage, as if we needed to merge phone and tablet user interface paradigms with desktop and laptop computers. I could rant some more about Windows 8, but that would take at least a dozen more paragraphs for a worthless tangent. The only thing that matters is that Microsoft will most certainly succeed regardless of the platform’s user experience merits (of which there are basically none compared to Windows 7), simply because of the OEMs and software vendors’ obligation to lick Microsoft’s smelly boots. I can see non-touch monitors becoming increasingly rarer in the future for this reason; I can see the pain for user interface toolkit developers and clients (users) in a few years when everything is required to support touch input — yes, even Wesnoth.
And in this case, mice are not an optimal alternative. I have tried the Windows 8 Release Preview on virtual machines with a mouse and I can safely say I find any other version from 3.0 through Windows 7 to be more efficient for daily use. I guess your mileage may vary after a while, though. Perhaps technologically-challenged kids and elders will learn to use the “modern desktop” faster and better than us veterans?
Not my business anyway — as long as the KDE crowd doesn’t fuck up, that is. Let us all hope Canonical doesn’t fuck up in a similar way too, because everyone likes to imitate Ubuntu nowadays.
My initial experience with computers was through MS-DOS and old-fashioned keyboards. I grew up using standard two-button mice in tandem with more old-fashioned keyboards, and later upgraded my experience with scrolling wheels, and wireless mice. Scrolling wheels are great for web browsing, coding, examining lengthy terminal output buffers, and even drawing, but the cheaper mice out there don’t really last very long, and lint and hair do not really help matters when the design doesn’t include a simple way to access and clean the wheel’s gear.
Wireless mice are apparently a love-it-or-hate-it subject. My current mouse has lasted over a year, it is large enough to work well as a laptop mouse and a desktop mouse, and the battery charge tends to last nearly a month. I bought a couple of rechargeable AA batteries with it and I always keep one fully charged for quick replacement; the mouse only uses one battery at a time. All of my previous mice used two AAA batteries, which lasted significantly less. Their scroll wheels were evidently not designed to last either.
I am pretty sure I will not be buying any touch-based devices for the foreseeable future. My new cell phone is more than enough to keep my patience below nominal levels for a while, at least when using it; I am grateful that the manufacturer was kind enough to include a physical numeric keypad along with two actual call and dismiss buttons.
Just wanted to note that I am ceasing my online Wesnoth and IRC related activities for an indeterminate amount of time while I tend to some matters of greater priority. In case you are wondering, yes, everything is fine, but I do need a break.
You can still message me through Twitter, email (preferably!), or private message through the Wesnoth forums (which result in email notifications) if something absolutely important crops up in the meantime other than the forums being down. I have provided the other Wesnoth.org administrators with instructions in case I’m needed for something specific, and for other issues you can always PM the Forum Moderators or Administrators groups or email the forums support address, which is displayed whenever things go completely wrong.
And of course, I may continue to post about non-Wesnoth things here as I see fit.
UPDATE 2012-11-30: The problem described in this post no longer applies since yesterday 2012-11-29, as the
ia32-libs* multiarch transitionals have finally landed in Testing. Installing
libgl1-nvidia-glx:i386 after previously installing the rest of the NVIDIA stack from Experimental appears to work flawlessly.
From my previous post:
Quite notably, everything is working fine with the latest Debian wheezy packages (although I compiled my own newer kernel later anyway) except for the onboard sound controller.
Ah! But not so fast! I had forgotten that Debian wheezy’s half-baked multiarch support has serious implications for 32-bit OpenGL-based software on the amd64 platform (a.k.a. x86_64 for everyone else), regardless of whether one is using a proprietary (e.g. NVIDIA) or free (Mesa) stack. In Reicore’s (Mesa) case, this meant that I had to stick to the version from
ia32-libs in Testing, which is Mesa 7.7.1 — contrast with the native version, which is 8.0.4.
In Nanacore’s case, the implications span even more packages. The description of the
libgl1-nvidia-glx-ia32 package in Testing (amd64 arch) says:
This is an empty transitional package to aid switching to multiarch. Run the following commands to install the multiarch library:
dpkg --add-architecture i386 ; apt-get update
apt-get install libgl1-nvidia-glx:i386
And, surprise, surprise. That doesn’t work in Testing because of bug #686033 — fortunately for me, apt-get was wiser in blocking the operation due to some perceived conflicts.
In an attempt to solve this, I pulled the NVIDIA driver packages from Unstable and then tried to install
libgl1-nvidia-glx:i386 again to no avail — it requires me to upgrade ia32-libs from the version in Testing to the one in Unstable, which is really a multiarch transition metapackage. After watching multiarch in Debian wheezy become such a major disappointment over time, I decided to do something different with
I decided to install it by hand.
The procedure was a little convoluted and involved a lot of symbolic links, and I’m not completely sure whether what I did works because I don’t have Wine installed right now and I don’t really want to install Debian’s packages because—again—they use multiarch support to pull nearly 92 MiB worth of redundant crap:
shadowm@nanacore:~$ sudo apt-get install wine [sudo] password for shadowm: Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: gcc-4.7-base:i386 libasound2:i386 libc6:i386 libc6-i686:i386 libdbus-1-3:i386 libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386 libdrm2:i386 libexpat1:i386 libffi5:i386 libfontconfig1:i386 libfreetype6:i386 libgcc1:i386 libgcrypt11:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libgnutls26:i386 libgpg-error0:i386 libgpm2:i386 libgsm1:i386 libice6:i386 libjbig0:i386 libjpeg8:i386 libltdl7:i386 liblzma5:i386 libmpg123-0:i386 libncurses5:i386 libodbc1:i386 libp11-kit0:i386 libpciaccess0:i386 libpng12-0:i386 libsm6:i386 libssl1.0.0:i386 libstdc++6:i386 libtasn1-3:i386 libtiff4:i386 libtinfo5:i386 libuuid1:i386 libv4l-0:i386 libv4lconvert0:i386 libwine:i386 libwine-alsa:i386 libwine-bin:i386 libwine-gecko-1.4 libwine-gl:i386 libx11-6:i386 libx11-xcb1:i386 libxau6:i386 libxcb-glx0:i386 libxcb1:i386 libxcomposite1:i386 libxcursor1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxi6:i386 libxinerama1:i386 libxml2:i386 libxrandr2:i386 libxrender1:i386 libxslt1.1:i386 libxxf86vm1:i386 uuid-runtime wine-bin:i386 zlib1g:i386 Suggested packages: libasound2-plugins:i386 glibc-doc:i386 locales:i386 rng-tools:i386 libglide3:i386 gpm:i386 libmyodbc:i386 odbc-postgresql:i386 tdsodbc:i386 unixodbc-bin:i386 wine-doc:i386 libwine-cms:i386 libwine-sane:i386 libwine-ldap:i386 libwine-print:i386 libwine-openal:i386 libwine-gphoto2:i386 Recommended packages: uuid-runtime:i386 ttf-liberation:i386 xml-core:i386 The following NEW packages will be installed: gcc-4.7-base:i386 libasound2:i386 libc6:i386 libc6-i686:i386 libdbus-1-3:i386 libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386 libdrm2:i386 libexpat1:i386 libffi5:i386 libfontconfig1:i386 libfreetype6:i386 libgcc1:i386 libgcrypt11:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libgnutls26:i386 libgpg-error0:i386 libgpm2:i386 libgsm1:i386 libice6:i386 libjbig0:i386 libjpeg8:i386 libltdl7:i386 liblzma5:i386 libmpg123-0:i386 libncurses5:i386 libodbc1:i386 libp11-kit0:i386 libpciaccess0:i386 libpng12-0:i386 libsm6:i386 libssl1.0.0:i386 libstdc++6:i386 libtasn1-3:i386 libtiff4:i386 libtinfo5:i386 libuuid1:i386 libv4l-0:i386 libv4lconvert0:i386 libwine:i386 libwine-alsa:i386 libwine-bin:i386 libwine-gecko-1.4 libwine-gl:i386 libx11-6:i386 libx11-xcb1:i386 libxau6:i386 libxcb-glx0:i386 libxcb1:i386 libxcomposite1:i386 libxcursor1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxi6:i386 libxinerama1:i386 libxml2:i386 libxrandr2:i386 libxrender1:i386 libxslt1.1:i386 libxxf86vm1:i386 uuid-runtime wine wine-bin:i386 zlib1g:i386 0 upgraded, 70 newly installed, 0 to remove and 0 not upgraded. Need to get 91.9 MB of archives. After this operation, 265 MB of additional disk space will be used. Do you want to continue [Y/n]?
Not to mention that by pulling Mesa it might as well break my little patchwork setup with NVIDIA’s 32-bit libGL here. This is not something I’m too keen on trying out while stuck on shitty 3.5G mobile broadband.
I intend to revisit and unravel this conundrum at a later point and try to understand and document my libGL installation solution but, again, I have bigger fish to fry.
It was only fitting that the seventh machine—a desktop—would be Nanacore (nana なな) then.
|Reicore||2010||Intel Pentium T4300|
2.1 GHz dual core
|4 GiB||500 GB||Intel GM45||Debian testing (Wheezy)|
|Nanacore||2012||Intel Core i7|
3.5 GHz HT quad core
|16 GiB||2 TB||NVIDIA GeForce GT610||Debian testing (Wheezy), Windows 7 (???)|
Quite notably, everything is working fine with the latest Debian wheezy packages (although I compiled my own newer kernel later anyway) except for the onboard sound controller.
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
The Intel HDA codec for these controllers is apparently not quite ready yet; as a result, the mixer sliders are slightly broken in that there is no master channel, the speaker channel has no actual volume slider, changing the PCM channel’s volume causes some slight noise, and I suspect some features are missing as well. Despite this, the driver works for basic usage given some precautions with the KDE sound system to choose the correct (PCM) channel for audio instead of the sliderless (speaker) channel. I would not mind to spend some additional time researching the situation later, but I really need to get back to work on non-audio stuff (a.k.a. AtS) right now, so that will have to wait.
Incidentally, the Debian KDE desktop task includes PulseAudio now (I believe this wasn’t the case with Squeeze). Rather unsurprisingly, PA continues to be a considerable annoyance for my usage (e.g. lockup during KDE login, 1% extra CPU usage during playback from any application), so I ditched it after a day or two for plain ALSA. I don’t really have a need for the extra layer of indirection since PA uses ALSA anyway and my sound needs are very basic — basically, just playing sound from media players, games, and application notifications.
For graphics I’m using a decidedly inexpensive NVIDIA graphics card for the sake of having an NVIDIA graphics card and parting ways with Mesa for a good while. And while I had intended from the get-go to install the proprietary drivers, a forced and thankfully short Nouveau intermission confirmed that Nouveau indeed eats kittens. And that’s really all there is to say on the matter.
Both the machine and Debian wheezy can do UEFI, but I quickly stumbled upon a couple of issues:
- Using the EFI version of GRUB means the only way to get a working text console on Linux is to use a framebuffer console driver such as efifb. This is not supported by NVIDIA and the driver complains quite loudly about it.
- The machine appears to enumerate my (USB) 3G modem’s built-in storage as the first and second hard disks when it is connected, breaking GRUB’s expectations about the location of the disk from which it will boot, which becomes the third (SATA) hard disk in such a situation. The PC BIOS version of GRUB only gets to see the real hard disk drive.
Since this is my first time dealing with an UEFI-based system yet, I don’t really know whether the second point is a bug in GRUB, or the platform itself. Regardless, the first point pretty much convinced me to not spend any further time on that and just go back to the BIOS flavor of GRUB. This doesn’t seem to have done anything for my broken Windows 7 installation, which I probably don’t really need.
I have been working on transferring my configuration and files from Reicore since this Monday, approximately, and I think I’m nearly ready to get back to business now.
(I actually wanted to post this on the 7th but I got sidetracked by the system migration and testing.)
First there was an old (1997) Windows 95 OSR 2 box boasting a P55C Intel Pentium processor with an staggering clock frequency of 166 MHz; 16 MiB of RAM (later expanded to 32), a 1.2 GB* hard disk; it had an onboard S3 Trio64V+ with 1 MiB of video RAM.
* Hard-disk manufacturer ‘gigabytes’.
Then, there was another OEM machine (2002), running Windows XP on a 1.3 GHz Intel Celeron (“Celeron-S”) including 256 MiB of RAM and a 40 GB hard disk; before it was decommissioned for good, it ran both Windows XP SP2 and openSUSE 10.0; it was the first machine on which I ever installed Linux (SUSE Linux 9.3), and my original introduction to Wesnoth (0.9.5 from openSUSE 10.0) happened there; the onboard Intel 810E IGP became the victim of various Linux graphics-related shenanigans. (This was the last computer I ever owned that included a 3.5" floppy disk drive; unfortunately, it was broken and it took me a year and various casualties to figure this out.)
Later during 2006, Blackcore appeared: another OEM machine running Windows XP SP2, equipped with a 2.6 GHz Intel Pentium 4 (Prescott) with Hyper-Threading; 1 GiB of RAM, a 160 GB hard disk, and an IGP from the biggest piece of shit chipset manufacturer otherwise known as VIA. This was my first named computer, a practice which has truly paid off to this day. It currently runs the same original installation of Windows XP upgraded to SP3; it has run various Linux distributions and versions and I’ve not stuck with any of them simply because VIA is the biggest piece of shit chipset manufacturer.
Following the color-themed naming scheme, Greycore became the first laptop I ever owned around mid 2007; an Acer Aspire 5050 including an AMD Turion 64 MK-36, an amount of RAM I don’t remember anymore, 80 GiB hard disk drive, and Windows Vista. It first ran openSUSE 10.2 and openSUSE 10.3 besides Windows for a long time, until I got fed up with an incident involving a security update utterly ruining my system with terrible timing. It took a while before I finally decided to switch to another distribution instead of keeping the same old 10.3 installation around, but it was worth it — Debian Lenny (testing at the time, Q3 2008) was my choice and I have stuck with Debian ever since.
Greycore was decommissioned once Bluecore took over; an HP Pavilion dv5-1132la running Windows Vista SP1. It was a much better deal than Greycore in the long term, as I acquired it on Christmas Eve 2008 and it lasted until January 2011 with mild wearing symptoms until it finally kicked the bucket (it got better later); Greycore did not last more than a year before it got utterly wrecked.
Bluecore started with 2 GiB of RAM and ended up with 4 GiB as Wesnoth began to demand significantly more memory for compiling. The 2 GHz dual core AMD Athlon 64 performed very well at the beginning, but our favorite open source game’s development largely outpaced it. The 250 GB hard disk served me well despite running into low space situations in various opportunities as I began to experiment with the processor’s hardware-assisted virtualization capabilities. This overheating beast (51 °C - 64 °C idle, 65 °C - 92 °C under load) has only run Debian as its native operating system besides Windows — first Lenny (testing, later stable), then Squeeze (testing), and very recently, Wheezy (testing). The ATI Radeon HD 3200 was an infinite source of frustration when it came to OpenGL on Linux until very late 2009.
Its untimely and infuriatingly IGP-driven demise resulted in Reicore taking over; first temporarily, and then permanently as its 2.1 GHz dual core Intel Pentium T4300 and Intel GM45 graphics processor ended up proving far more worthwhile than Bluecore’s AMD-based configuration. Reicore (an HP Pavilion dv4-1624la) was purchased for someone else at first, and ran Windows 7 until she became mine, and then I proceeded to wipe it out to make room for Debian — first Squeeze (stable), and now Wheezy (testing). I have never run out of space with its 500 GB hard disk, and even today my
/home partition has a little more than 50% of free space. It helps that the processor’s lack of virtualization capabilities has not been very encouraging in the virtual machine department, I guess.
Notice that Reicore also breaks the naming pattern. This was explained before.
|32 MiB||1.2 GB||S3 Trio64V+||Windows 95 OSR 2.0|
|256 MiB||40 GB||Intel 810E||openSUSE 10.0, Windows XP SP2|
|Blackcore||2006||―||Intel Pentium 4|
2.6 GHz HT
|1 GiB||160 GB||VIA POS||Windows XP SP3, Debian GNU/Linux 6.0 (Squeeze)|
|Greycore||2007||2008||AMD Turion 64 MK-38|
|??? GiB||80 GB||ATI Radeon Xpress 1100||Debian GNU/Linux 5.0 (Lenny), Windows Vista|
|Bluecore||2008||―||AMD Athlon 64 X2 QL-62|
2 GHz dual core
|4 GiB||250 GB||ATI Radeon HD 3200||Debian testing 2012-10-22 (Wheezy), Windows Vista SP1|
|Reicore||2010||―||Intel Pentium T4300|
2.1 GHz dual core
|4 GiB||500 GB||Intel GM45||Debian testing (Wheezy)|
Six computers — that’s quite a lot! I wonder what will come next... (Written wink!)
Wesnoth-TC 1.5.1 has just been released... or maybe not. It has actually been tagged for more than 24 hours already.
This version is really just a bug-fix release, which is why it’s not 1.6.0. In fact, it only really addresses some build-time issues that have cropped up over the last couple of years.
- Source code: wesnoth-tc-1.5.1.tar.bz2 (156.2 KiB)
- Windows (Win32) binary: wesnoth-tc-1.5.1-win32.zip (383.6 KiB)
Both distributions come with a
README file, and the source code distribution also includes an
INSTALL file with detailed instructions for configuring, compiling and installing Wesnoth-TC. The Windows binary distribution doesn't require any installation besides unpacking it into an appropriate directory — which you may optionally add to
The past, and the future
Long ago, this came into existence. At the time, I needed a quick way to preview my own team-colored unit sprites without going through the hassle of starting/restarting Wesnoth (or its internal cache), loading a saved game, and creating units in debug-mode. That was my initial motivation for writing Wesnoth-TC, and since it was tailored to my specific needs, it was born as a console application. I later decided to publish and extend it, hoping that someone else would provide a good full-featured user interface for it.
Actual artists prefer using graphical user interface applications on Windows and Mac OS X, and with good reason. That’s the software interaction paradigm that suits visual types better for obvious reasons, and that’s why I took it upon myself to write a larger GUI front-end for Wesnoth-TC that could be built and run on the three major platforms from a single code-base.
That front-end quickly became an adaptation of the original back-end code. And thus Wesnoth RCX became an entirely separate project sharing little more than a bit of history with Wesnoth-TC. And most importantly, Wesnoth RCX became the first GUI (Qt 4) application I have ever written.
Over time, my needs and personal preferences have changed. Wesnoth-TC now feels largely inferior to RCX merely because of the lack of a native front-end for it. RCX has also recently gained visual palette and color range editing capabilities, which renders Wesnoth-TC’s definition file system somewhat obsolete. Furthermore, RCX has continued to compile and run correctly over time regardless of the Qt 4 version currently installed, whereas Wesnoth-TC has broken in a few occasions with newer development environments.
Wesnoth-TC truly feels like a relic now, one I don’t really want to continue developing at this time when I feel RCX is more fun to improve and work with. I had plans to eventually integrate a full-fledged implementation of the Wesnoth Image Path Functions mechanism, but that seems over-ambitious right now.
So, yeah, Wesnoth RCX is the future. Stay tuned for version 0.2.0, coming soon with more features and improvements.
I have just finished moving Wesnoth-TC and Wesnoth RCX to Github — in my humble uneducated non-expert opinion, a much nicer place to be than Gitorious, which still lacks native CIA.vc support after all these years. Instead, Github supports CIA.vc and a large amount of alternatives which I’ll probably never use.
The project page on this website has been updated accordingly. If you were tracking the repositories at Gitorious, you will not be able to get further updates unless you update your configuration to point to the new locations:
- Wesnoth RCX (codename Morning Star):
Updating client repositories is actually far easier than it sounds:
$ git remote set-url origin <new URL>
Afterwards, you should be able to fetch/pull as usual.
This switch actually began some time ago when I was considering resuming Wesnoth RCX’s development (which stagnated ‘some’ time ago too). It took a while, but I finally seem to be back on track, all thanks to my currently unannounced self-imposed campaign development break — a break that should allow me to get back to business soon enough, with the renewed energy and coder momentum I will seriously need in order to pull *it* off.
Wesnoth RCX 0.2.0 will probably be released before the end of this week, as soon as I make sure everything works as intended, which will be less trivial this time due to the new shiny features it packs. There’s also a couple of Windows-specific oddities that I want to tackle before releasing.
Oh, and in the meantime there will be an update regarding Wesnoth-TC’s future.
I could not bear using Chromium for a week as I originally intended. All right, I admit I always intended to go back to Firefox, but the whole exercise didn’t go as planned for various reasons.
The thing is, I have always used Firefox since version 1.0 or so and it has basically become part of my personal life — it’s impossible for me to stay mad at it for too long after all we have been through together.
Nothing of this renders the points I previously raised here any less valid, but I have coped with those annoyances for a good while already — let’s not get too demanding in the usability department here, otherwise I may as well invest a zillion dollars in Apple products right now.
Besides, Chromium insists on taking up preposterous amounts of CPU time in the background every once in a while, even after getting rid of a certain bug with the Linux kernel and leap seconds. Despite all its inefficiencies, I have never seen Firefox indulge in such erratic (and potentially harmful for laptops) behavior like that while idle. I already did my best to diagnose the issue, but I never had that much interest in using Chromium as my primary web browser in the long term anyway. After all, I am a KDE user, which means I like options — the Chromium design philosophy is more or less the antithesis of that, and it shows.
Not to mention that there’s no Chromium add-on providing a Bookmarks menu that looks nice, probably due to the previously mentioned design limitations. It’s also somehow more natural for me to have the Home button at the right end of the toolbar, but this might just be Firefox inculcating habits.
Going back to Firefox, it does seem like resetting its configuration and clearing all of my old web history before March 2012 improved overall performance. In case someone else wants to try resetting their own configuration:
- Backup your profile or the whole
.mozilladirectory (on Linux/X11, no idea about other platforms);
- Go to the
about:supportpage, and choose the Reset Firefox option;
- Follow the instructions on the screen to create a new profile preserving your browsing history, bookmarks, cookies, and saved passwords.
When done, you will be left with an additional copy of your old profile that might or might not still work — I didn’t check this. You can start Firefox with the
-P switch to see the previous profile, and possibly delete it after you are done making sure all the information you need is present in the new one. You will lose all your installed add-ons, their configuration, and your browser preferences; this is pretty much the whole point of the procedure.
I for one had accumulated heaps and heaps of unused or obsolete configuration entries (both from add-ons and old Firefox versions) carried over since late 2008. That can’t possibly be healthy, especially considering that I have tried many, many add-ons and hidden configuration options over the years, and used pretty much all versions since Firefox 3.0.
It’s probably more important to keep the web history under control, though. Older versions of Firefox—if I recall correctly—had a user-visible option in Preferences to limit history to a given amount of time, but that doesn’t seem to be the case as of Firefox 13 and it’s all or nothing. Of course, it’s also possible that the current defaults do limit history and there simply isn’t a way to change that limit anymore; so if I ever changed it with a previous version, it would have become inaccessible to me later short of using
Version 0.8.1 is out, right on schedule!
Just like the last time, this version will definitely not be exempt of flaws. You will most likely stumble upon dreadful bugs along the way, and I will need your help to fix them — make sure to report them in the campaign’s forum topic as usual!
Special thanks go to bumbadadabum for kindly providing a patch to integrate the changes to the Aragwaithi faction from his multiplayer add-on (The Aragwaithi in the 1.10 add-ons server) into AtS. 0.8.0 users shouldn’t have any game-breaking problems playing with their old units from saved games of E3S3 (Amidst the Ruins of Glamdrol), although some animations may not display correctly. If in doubt, restart from the start-of-scenario save for E3S3.
Also note that due to an internal change, if you load the start-of-scenario save for E3S4 (Outpost of Hell) from version 0.8.0, you will see the loadscreen twice. This is normal and intended, and only affects old saved games for that scenario.
This release is a turning point for various reasons I had already explained a while ago. The good thing is that once scenarios stop landing in SVN, I no longer need to worry about release schedules and pacing. I can now start pushing bug-fix releases as necessary, without affecting the development of the campaign finale.
It is also a turning point in other senses that attentive players will most certainly realize on their own. But in case someone feels disappointed by certain developments: I left enough clues scattered everywhere before, and everything is going according to plan. The bottom line is: if you don’t like the story and you can’t ignore it, don’t play the campaign. And just to be clear, it has never been my intention—at least since I resumed its development in 2011—for it to be eligible for mainline or anything like that.
The changelog for this version follows:
Version 0.8.1: -------------- * Graphics: * New or updated unit graphics: most Aragwaith units (wayfarer). * Scenarios: * E2S3.1 - Unrest in Raelthyn: * Updated to use Aragwaith units. * E2S8 - And then there was Chaos: * Fixed elves who are initially Loyal getting a duplicate trait when switching allegiances. * E3S2.1 - Return to Raelthyn: * Minor map balancing changes. * E3S4 - Outpost of Hell (Gateway): * New scenario. * E3S5 - Pass of Sorrows (Gathering Storm): * New scenario. * Sound effects: * Added hit and death sounds for Doors. * Added additional explosion/thunder sounds. * Added magic glyph sounds. * Units: * Balancing: * Removed marksman special from the Demolisher Drone's ranged attack. * Increased Sprite's impact resistance from -20% to 0%. * Increased Fire Faerie's impact resistance from -20% to 0%. * Increased Dryad's impact resistance from -10% to 0%. * Increased Aragwaith Seer's HP from 39 to 44. * Increased Aragwaith Seer's melee attack from 7-2 to 8-2. * Increased Aragwaith Seer's ranged attack from 8-3 to 10-3. * Decreased Shaxthal Razorbird's melee attack from 10-1 to 8-1. * Decreased Shaxthal Thunderbird's melee attack from 13-1 to 10-1. * Gave Doors a unit icon for the sidebar and the attack dialog. * Updated Aragwaith units to match the faction from bumbadadabum's "The Aragwaithi" add-on. This has resulted in the following changes: * Protection only affects allied L1 and L0 units instead of any allied lower level unit * Ancient Banner abilities: +leadership, -protection, -steadfast * Ancient banner resistances: impact 10% -> 20% * Ancient banner stats: HP 55 -> 58, MP 4 -> 5 * Ancient banner attacks: sword renamed to scythe * Archer attacks: melee 6-3 -> 4-3 * Captain abilities: +leadership, -protection, -steadfast * Captain resistances: blade 20% -> 10%, fire 10% -> 0%, cold 10% -> 0%, pierce 20% -> 10% * Captain stats: HP 43 -> 55, MP 4 -> 5 * Captain attacks: spear renamed to glaive, 17-2 -> 18-2; sword renamed to glaive, 9-4 -> 10-4 * Eagle Master stats: HP 48 -> 45, MP 7 -> 9 * Eagle Master attacks: blade 9-3 -> 10-3, impact 15-2 -> 16-2 * Eagle Rider defense: mountain 60% -> 50% * Eagle Rider stats: HP 36 -> 34, MP 7 -> 9, cost 21 -> 23 * Eagle Rider attacks: impact 10-2 -> 12-2 * Flagbearer abilities: +leadership, -protection, -steadfast * Flagbearer resistances: blade 20% -> 10%, fire 10% -> 0%, cold 10% -> 0%, pierce 20% -> 0%, impact 10% -> 0% * Flagbearer stats: HP 34 -> 45, MP 4 -> 5 * Flagbearer attacks: spear renamed to glaive, sword renamed to glaive * Greatbow stats: HP 43 -> 46, MP 5 -> 6 * Greatbow attacks: melee 13-3 -> 10-3 * Guard abilities: +steadfast * Guard resistances: pierce 20% -> 10%, impact 20% -> 10%, blade 30% -> 10% * Guard stats: HP 40 -> 54, XP 78 -> 64, cost 27 -> 28 * Guard attacks: melee 12-3 -> 11-3 * Guardian resistances: fire 10% -> 0%, cold 10% -> 0% * Guardian stats: HP 51 -> 62 * Lancer now has a female variation * Lancer stats: HP 40 -> 48, cost 38 -> 34 * Longswordsman stats: HP 38 -> 46, MP 5 -> 6, XP 78 -> 88, cost 24 -> 27 * Pikeman resistances: blade 20% -> 10%, impact 10% -> 0%, fire 10% -> 0%, cold 10% -> 0% * Pikeman stats: HP 44 -> 50, XP 94 -> 70 * Pikeman attacks: melee 17-2 -> 16-2 * Scout now has a female variation * Scout stats: HP 31 -> 36, XP 36 -> 40 * Scout attacks: melee 10-2 -> 11-2 * Shield Guard abilities: +protection, +steadfast * Shield Guard resistances: pierce 30% -> 10%, impact 30% -> 10%, blade 40% -> 10% * Shield Guard stats: HP 54 -> 66 * Shield Guard attacks: melee 16-3 -> 15-3 * Silver Shield now has a female variation * Silver Shield stats: HP 54 -> 62, MP 8 -> 9, cost 38 -> 48 * Silver Shield attacks: melee 13-4 -> 12-4 * Slayer stats: HP 45 -> 53, MP 5 -> 6, cost 46 -> 62 * Slayer attacks: melee 12-4 -> 11-4 * Sorcerer renamed to Sorceress, no longer has a male variation * Spearman resistances: blade 20% -> 0%, pierce 20% -> 10%, impact 10% -> 0%, fire 10% -> 0%, cold 10% -> 0% * Spearman stats: HP 30 -> 34, XP 38 -> 43 * Spearman attacks: 11-2 -> 12-2 * Strongbow stats: HP 35 -> 38, MP 5 -> 6, XP 80 -> 85, cost 31 -> 38 * Strongbow attacks: melee 9-3 -> 7-3, ranged 8-4 -> 9-4 * Swordsmaster id changed, breaking old saved games with the unit * Swordsmaster stats: MP 5 -> 6 * Swordsman resistances: blade 10% -> 0% * Swordsman stats: HP 28 -> 32, XP 32 -> 39, cost 13 -> 14 * Warlock renamed to Witch, no longer has a male variation * Witch stats: XP 44 -> 54, cost 18 -> 22 * Witch attacks: staff renamed to kick, 6-2 -> 7-1 * Wizard no longer has a male variation * Wizard attacks: melee 10-2 -> 7-2, ranged 11-3 -> 10-3
A couple of things:
- I cannot press Escape on a loaded page to stop all playing GIF animations.
- There isn’t an obvious way to search page contents backwards with the keyboard as in Firefox (it is Shift+F3 there).
What the hell?
For more than a year I have been actively avoiding the web browser that all the cool kids use these days. I’m obviously talking of Google Chrome.
For all its excellent performance and ease of use, I kept being bothered by its insistence on breaking the mold and looking like a completely different thing running on my Linux system, instead of behaving like an application blending with its environment. I think it was this big annoyance that kept me from adopting it as my regular web browser for all this time. But compared to Mozilla Firefox, I think there’s just no matter of dispute anymore. Chromium/Google Chrome keeps getting better, and Firefox is stuck in the noughties, much like an evolutionary dead end in the history of
fail web browsers.
The fact is, there are perfectly plausible explanations for the blending issue. It was only last night that I decided to do some research, and the first thing I found while looking around in the Chromium issue tracker was #10949, “Use GTK widget renderering in web content”. Various valid points are raised by the developers amidst some background noise — courtesy of random users. And truth to be told, it works. If one takes any XUL (e.g. Firefox, Thunderbird) application and tests it against Gtk+ theme engines or color schemes other than the Ubuntu defaults*, various design shortcomings become evident, including things such as the developers’ inability to choose a toolbar icon set for Linux/X11 that doesn’t become uncomfortably unreadable against bright backgrounds.
There are many other subtle quirks in Firefox as of late that make it glaringly obvious that it is unable to keep up with my own evolving requirements. Just to provide a few examples:
- The whole browser often freezes for milliseconds (up to one second) when performing certain operations in the background such as opening a new tab. (Chrome appears to use and abuse IPC on Linux to avoid this at all costs.)
- Scrolling motion often feels jerky, with occasional momentary rendering artifacts such as large blank chunks that are just displeasing or even painful to the eye. (In this regard, Chrome > Opera > Firefox here.)
- Awesome Bar suggestions may take long to appear in some cases due to my extensive browser history, which is pretty much the only way those suggestions can be useful in the first place (I currently have no idea whether Chrome is different in this respect). The main problem with this is that there is no obvious indication as to how much time I should wait for suggestions to come up before giving up.
- I can’t keep my tabs open and start a Private Browsing session on a new window. (Chrome allows “incognito” windows separate from normal browsing sessions.)
- Firefox Sync is somewhat cumbersome by design, and yet it refuses to work most of the time for unknown reasons.
As far as I am concerned, there’s a certain threshold beyond which an application starts to become a nuisance rather than the facility any modern application should strive to be. Those days when everything was a chore are long gone; I want a web browser that’s fast, efficient, effective, and does not get in my way. Google Chrome/Chromium is rather daring—perhaps a little too much—in these terms, as you can see by yourself under “Content not chrome” in their User Experience page, but their approach appears to be effective if the browser marketshare trends are anything to go by.
In conclusion, I have decided to give Chromium a more extensive test run for the rest of this week. Yes, Chromium (version 20 from sid), because I tend to feel the Debian packagers know their OS better, and the built-in Flash in the current stable Google Chrome appears to have problems with my machine and/or configuration.
Thankfully, importing my Firefox bookmarks, saved forms and other cruft took just a few clicks**. I will probably have to adapt to the different user interface design (already had to move some bookmarks around for easy access), but it might as well be a minor one-time hassle if it all works out well.
* (Seriously, “every Linux operating system is Ubuntu” would become a trope if Linux ever achieved
** (I decided against importing my web history, which goes back as far as June 8th 2011.)