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.
Web browsers break any established GUI design molds and this is no news for us. It was a necessity to create new controls (also known as widgets) in the ’90s when the Web was still a new, unknown thing and no common consensus on how users should interact with it existed. However, with time this practice has lost some of its technical grounds to become more of a profitable marketing strategy used by giants such as Mozilla and Microsoft to create distinct looks for their products.
Above we can see four browsers I personally consider major players in the GNU/Linux ecosystem in particular. From left to right, top to bottom in descending order of wheel reinvention and UI differentiation, we have: Opera 11 (???), Google Chrome 10 (GTK+), Mozilla Firefox 4.0 (XUL/GTK+) and Konqueror (KDE/Qt4) from KDE SC 4.4.
At the lower end, we have Konqueror, which has been designed to blend in with its parent application suite, the KDE desktop environment, so it uses a common visual design instead of inventing its own. At the top there’s Opera, a cross-platform browser that is not part of any specific suite and attempts to keep a consistent internal look between different operating systems, resulting in various reimplemented controls with different, custom functionality and a visual design unique to this software product.
In the middle we have Google Chrome and Mozilla Firefox, which have chosen to use the GTK+ toolkit to avoid reimplementing too much and concentrate on their actual business, that is, web browsing. But something’s horribly off about these two.
In Google Chrome’s case, we have a default, “Classic” theme that presents the user with the distinctive Chromium look and feel but keeps the standard GTK+ application design for modal dialogs. Embedded input controls in web pages such as checkboxes and unstyled command buttons appear to be rendered by a custom engine using Chrome’s own ideas of what a widget should look like. As Chrome belongs in the GTK+ territory like all of the GNOME desktop environment, this makes it really stand out as an individual application that behaves and looks like nothing native to GNOME or other GTK+-based environments. As an alternative, we can choose to use the “GTK+ theme” in the application’s preferences, which does nothing but switch the color scheme to respect the user’s desktop preferences a bit and fallback to GTK+’s icon paths for some (not all!) toolbar buttons.
This so-called “GTK+ theme” keeps the hideous low-contrast, Chrome-style scrollbar in the web page view area as well, basically mocking users who would hope for some desktop consistency and accessibility by choosing this option.
Mozilla Firefox provides an interesting case. Powered by the XULRunner framework, it aims to blend in with every one of its target platforms, using native Windows controls on Windows and GTK+ as a backend on Linux. However, someone didn’t get the memo with the main window’s tab bar, and instead of native GTK+ versions we get awful customized tabs that do not respect the user’s chosen GTK+ engine. It seems that in Firefox 4’s particular case the developers intended to achieve something closer to Opera in design, which worked in Windows, but didn’t get completed for Linux — probably due to time constraints and lack of volunteers to do the grunt work required in the coding area. Firefox 4 in Linux currently barely resembles the original mock-ups. (To their credit, those mock-ups showcase a really elegant — if somewhat unoriginal — design that is too unfortunately missing in the RTM builds.)
The current strategy appears to be all too profitable right now for these people to abandon it. We’ll probably just see more development in the GUI design department from web browser vendors than operating systems and desktop environments in the near future.
As I resolved to do last New Year, I’ve been progressing with After the Storm slowly at irregular intervals of time. During these last three days I’ve given it a bit of thought in regards to the future development plans and the road to 1.0.
I have settled for the following milestones:
0.3.0 — Ep. I, first act completed (scenarios 1 to 5)
0.4.0 — Ep. I, second act completed (scenarios 6 to 9)
0.5.0 — Ep. I, third act completed (scenarios 10 and 11)
1.0.0 — Ep. II completed
Right now AtS is about to hit the last set of changes needed for the 0.4.0 release. The first part of the ninth scenario is already finished in SVN trunk, and the second part is a work in progress. There are two art issues pending, but I plan to proceed with placeholders for now if it’s needed to have a release before the end of April.
Bluecore is now officially dead, and only a miracle could bring it back to a usable state. During the next week I’ll be taking it to technical support, so the current condition will hopefully be temporary.
Some days ago, I came up with a joke in ##shadowm regarding a hypothetical “Reicore” laptop, which would have some awesome NVIDIA GPU and a quad-core processor. This is most likely not going to happen, yet I have reused the computer name on my new, temporary laptop, which used to belong to my father and was, in fact, bought exclusively for his use during 2010.
1. Describing Reicore
Reicore is a fairly decent HP Pavilion dv4-1624la with 4 GiB of RAM (like Bluecore after an upgrade), 500 GB hard disk (as opposed to 250 GB) and an Intel Pentium T4300 dual core processor, which supports the AMD64/Intel64 instruction set — in fact, it came with Windows 7 Home Premium x64 preinstalled. Since its CPU is optimized for mobile usage, it doesn’t have some newer-generation assets like the Intel VT-x technology, which is essential for full-fledged hardware virtualization with KVM or VirtualBox. This is a major loss for me, since I doubt I’ll be able to achieve the same performance with Windows XP SP3 on a VM on Bluecore here.
(My Windows XP SP3 VM had been used for production purposes twice, during the development of Wesnoth RCX 0.1.x.)
This laptop has an integrated graphics controller from Intel’s Mobile 4 line-up as well, which is nonetheless decent enough for running software like Frogatto along with a composited window manager, in this case Kwin from KDE SC 4.4.
The LED-based display panel leaves much to desire though, as I can clearly see the LED grid beneath the screen when it’s active, no matter what colors are being visualized.
2. Choosing and preparing a Linux distribution for installing
The operating system I chose to install was Debian GNU/Linux 6.0 a.k.a. Squeeze, using a DVD snapshot of the Testing distribution from December 2010, which I later upgraded to current Stable. I had downloaded that snapshot of the amd64 builds along with a 32-bit x86 one I used on Blackcore for the sake of having a backup Linux system. The amd64 DVD image had seen no use until the night after Bluecore’s death, during which I rescued it from my awesome external 2 TB hard disk, as part of the last backup tree made from Bluecore’s Linux installation.
This decision makes Reicore the fourth machine on which I have installed Debian. Funnily enough, in all four cases I have not had a Stable snapshot handy, and have had to use Testing instead.
The actual preparation of the physical disc for installing Debian involved a lengthy and complicated operation involving Blackcore, Greycore, the backup hard disk (“multi”) and a 16 GiB USB pendrive (“UTIL_Q”).
Greycore has been running Debian Lenny (oldstable) since the last time I used it around the first week of January 2009, and thus has no Ext4 support.
The Squeeze DVD image was stored both on Bluecore (inaccessible) and the backup HDD, the latter consisting of a single Ext4 partition.
Blackcore runs Windows XP SP2 and Debian Squeeze, so it does have Ext4 support. The DVD drive, however, turned out to be defective and cannot burn DVDs.
Greycore, despite being in a miserable state, still has a functional Linux system and a DVD drive.
After juggling a 4.4 GiB ISO 9660 image around between the external hard disk, the USB pendrive and Greycore, I was ready to install a Linux OS on Reicore, deliberately wiping out Windows 7 in the process for a change.
3. Installing Debian
Installing Debian on Reicore turned out to be a quite satisfying experience compared to those I had on Bluecore (testing Lenny 2008-11) and Blackcore (testing Squeeze 2010-12). Unlike the initially Lenny-based laptop’s case, there were no hardware compatibility issues against the installer kernel; and unlike the desktop machine’s case, there is full availability of highly functional, free drivers for Reicore’s hardware in the first DVD of the distribution, without the need of installing optional firmware packages.
After finishing Debian’s installation I was greeted by a shiny Intel graphics driver with KMS and 3D graphics support, and a clean KDE SC 4.4 desktop. From this state I upgraded to the current Stable distribution.
4. Restoring from backups
Due to my painfully lazy nature, I didn’t make daily backup snapshots of Bluecore while it was still working. In my defense, I could say that transferring nearly 220 GiB of data through USB 2.0 is a royal pain in the ass!
shadowm@reicore:~$ stat /media/multi/bu/daily.0/ | fgrep Modify
Modify: 2011-01-19 18:51:34.000000000 -0300
The real losses since then aren’t very important, since all my projects are hosted in distributed repositories using Mercurial or Git, as I foresaw the possibility of theft or damage to the laptop. The only tree with local modifications that I didn’t push upstream in time is “rei2-rei2”, corresponding to a series of Rei 2 IRC bot scripts used by the official Rei2 instance administrating the ##shadowm IRC channel on freenode.
Other losses include configuration changes, local IMAP caches, unimportant downloads and various VM state changes, including a Windows Vista VM I set up around one week ago.
The configuration changes aren’t that important either, since although I have a full snapshot with all my configuration from Bluecore at that time, I decided to start fresh on purpose. This has unveiled some performance issues I initially attributed to Debian Squeeze’s architecture — they might have been in fact caused by the carry-over of configuration from the days of Lenny as a testing distribution on Bluecore. A rough estimate indicates that Bluecore would take around 2 minutes to boot into the KDE login screen, while Reicore takes around 30 seconds.
Last night, after shutting down bluecore and leaving it alone for hours, the BIOS boot stage failed and I had to turn it off and try again. Today that’s not the case, and bluecore won’t boot.
I do not understand why is this, or what could be the cause, since in both opportunities the laptop went through a successful hibernation cycle from Linux. There doesn’t seem to be any relation to the AC adapter or battery status, since I tried turning it on with different power source combinations. The GPU and display screen don’t come up, and the keyboard doesn’t work — the only visible indication of (in)activity is the two blinking Caps Lock and Num Lock LEDs, which I saw before when Linux wouldn’t resume from suspend-to-RAM properly back in the 2.6.26 days, two years ago.
This means that my files, configuration and software are currently inaccessible and unusable, save for a ~2 weeks old complete system backup on my 2 TiB external hard disk, which I could use with the machine I’m using right now, blackcore. There are various problems with this desktop computer, however, that make it barely usable with Linux. In particular, GL applications crash X.org thanks to VIA’s nearly nonexistent IGP support, and there’s nearly no means of 2D acceleration.
The current plan is to take bluecore to the technical support people. Hopefully they’ll prove their worth in money this time.
Due to recent abuse of the Tor anonymization network detected on Wesnoth.org’s forum board, I have decided to permanently block access through this service.
This is rather unfortunate, since I have found myself in need of using Tor before, as an alternative to broken ISP ←→ Wesnoth.org’s upstream network routes; however, it seems to be the most sensible solution to help fight vandalism. I won’t hesitate to extend these measures to the rest of Wesnoth.org if further issues arise.
Users’ accessing the forums via Tor or any other blocked hosts, service providers and proxies will see the following error message:
As those who have read the Wesnoth.org Website forum should know, there’s currently an ongoing brute-force attack targeted at the Wesnoth.org community board attempting to log into multiple users, developers, artists and administrators’ accounts.
Although the situation is mostly under control at the moment, it’s always a good idea to remind people to choose safe, non-guessable passwords for their online accounts, and to make sure they aren’t shared amongst services.
I have been setting up filters to deny access to the board to multiple suspicious addresses and subnets. If you see a 403 Forbidden message when trying to access the forums, follow the instructions on the error page to contact us so we can sort it out.
I don’t currently have further information available on the attack that I can freely disclose, although I personally suspect it’s an attempt to disrupt regular user activity by forcing people to fill in the maximum log-in attempts CAPTCHA in the User Control Panel page.
I have been thinking about some stuff to do during this year for a while, actually. It’s really hard to decide because I’m a person who runs into all sort of trouble while trying to get projects accomplished (including procrastination).
One thing I’m already doing is learning some Japanese, for no particular reason at all — although you’ve got to admit that having multiple languages in your curriculum is worth a bunch of coolness points. 😛 Espreon is helping me along the way with his own recently gained knowledge. It seems quite fun to learn a language in a non-Latin alphabet, if not a tad overwhelming at times, especially with kanji.
It’d be a good idea to lose some weight this year, too. My addiction to sugary stuff isn’t quite compatible with my heart condition! (Nor is coffee, but… meh.)
Then there’s Wesnoth. I intend to finish the Second Act™ of After the Storm Episode I as soon as I may, even through the means of placeholders — I’m willing to do anything to rescue AtS out of Development Hell before the end of 2011.
Wesnoth RCX’s development is halted right now due to lack of interest on my part to invest energy on writing the rest of the new functionality (i.e. definition of custom ranges and palettes), but I know that once I touch Qt Creator’s awesome interface I can’t stop working for a while — so I may eventually get some inspiration to redesign the main window, which should inevitably lead me to tinker around with the rest of the code.
C# was the first “major” programming language I learned, not counting Visual Basic. I have some fond memories of my first experiments with C#, but after I embarked upon learning and using C++ I kind of forgot about it. I have been considering the possibility of writing an IRC client of sorts using C# just for kicks, and to not forget this language in case I ever need it again. Why IRC? Because clients for this protocol are simple and challenging to implement, both at the same time!
I’ve already started to learn a bit of Lua for my work on the aforementioned Wesnoth campaign — in fact, there’s already some released code within it written in this language, particularly in scenario 5! I have plans to rewrite parts of Invasion from the Unknown in Lua to clean it up a little, thus paving the road for future maintenance work by me or other people (don’t forget that IftU is still abandoned!).
Another software project I intend to tackle in the short term is Rei 2. Sure, she’s doing well and her main command handlers are many and useful enough for channels such as ##shadowm and #wesnoth-umc-dev, but her dependence on Irssi’s core might well be a curse for one of our use cases: Shikadibot (the Second), which runs on a resource-limited VPS where every drop of RAM has got gold value. I’m already brainstorming a possible abstraction layer (codenamed “API 3”) which could allow the Irssi core to be swappable with a custom, native IRC client core (codenamed “Anya”). There’s really not much in the current Irssi-based implementation of the internal interfaces (“API 2”) that make a dependency switch unfeasible.
Finally, I’m not going to stop producing useless updates for my website! Dorset5 0001 is already a reality, although there’s still much I want to do before replacing the current layout. This time I have placed an emphasis on readability and elegance that I don’t think the previous revisions have lived up to so far.
• • •
All in all, I always have so many ideas floating in my mind that I rarely carry to realization, so this can’t be considered a definitive list. There are other possibilities I’m contemplating for the long term regarding my personal life, but that’s a much more volatile subject to discuss so I’m avoiding it for now.
Today I’ve found out that silene, one of the Wesnoth developers, has taken the decision to withdraw support for autotools (a.k.a. autoconf+automake, or configure + Make) without previous warning or discussion with the rest of the development team and distribution packagers.
This came completely out of the blue, as you can see. I can’t really say whether I agree with this decision or not, however, in an ideal world it would not have been done without previous discussion in the developers mailing list at the very least.
Although I’ve spoken in the past against SCons (blah), it is my preferred build system nowadays thanks to its ease of use, simple management of multiple build configurations and loonycyborg’s hard work on improving our build scripts.
This is just one of the many upcoming changes in Wesnoth 1.9.4, but one substantial enough to require some previous preparation for those who are used to the good old configure script. Hopefully this will not be a too disruptive change for our users, but in case you feel profoundly affected by the decision, now you know who to complain to. 😉
