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.
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. 😉
Not too long ago, I forked a branch from Wesnoth’s trunk and started committing stuff to it in the mainline repository, thanks to the awesome power of Git branching through the git-svn bridge. My main goal is to experiment with improvements to the add-ons download interface, trying to address some of our users’ most common complaints, while not touching trunk directly to allow Ilor — who’s in charge of the WIP new add-ons server/client implementation — to easily merge his changes with trunk and the other way around until I can get confirmation from him about the mergeability of my own work.
Right now there’s very little done in my umcmg branch, but today I’ve come up with some patches that should be trivial to mix into trunk.
Pictured to the right is the new Add-on Description dialog (taddon_description), intended to finish my quick-and-dirty hack from September 2009, which made it to trunk nearly at the same time as a string freeze entered in effect, making it impossible for me to polish this feature for 1.8.
At the left you can see something potentially less interesting, a work-in-progress Download progress viewer (taddon_download_progress) that is written using mordante’s GUI2 toolkit instead of the old GUI1. This is hardly usable right now, and in fact, crashes the game, proving yet again that I’m not really fit for messing with the network layer of our dear game.
It’s really tempting to just run over the Download/Update dialogs with a steamroller, but mordante’s got his own plans for that and the GUI2 listbox widget, which will unconditionally become a basic building block of the hypothetical, unified add-ons manager dialog, plus there’s also Ilor’s work on the new server/client; therefore I can only wait for now until these matters are settled and try to have something ready for 1.10 as a last resort if neither of the aforementioned solutions are available by the time we hit another string/feature-freeze period.
Windows package:wesnoth-rcx-0.1.4-win32.zip (Zip archive, 5.2 MiB)
SHA1 checksum: 3832ddb798110f2e890aecc37519097e1e18e2b6
Mac OS X binary:wesnoth-rcx-0.1.4.app.zip (Bundle, 14.9 MiB)
SHA1 checksum: 60a5724d35b0bf64d02b4553ff9c1543d5964344
This binary is kindly provided by Alarantalara from the forums.
The only major change in this version is the addition of zoom support in the user interface, so you can take a look at your team-colored pixel art at 100%, 200%, 400% and 800%, or even at 50%. No more levels are supported at the moment, and will probably never be unless you submit a patch — this is really just supposed to be a help tool, so if you need more exotic zoom levels use a real graphics manipulation tool such as Adobe Photoshop or the GIMP. And don’t forget you can also drag and drop images now!
There’s also a brand-new grayed-out menu for you to observe and admire. Only observe — don’t touch it.
As with the last time, the instructions for building the source are in the included INSTALL file in the distribution archive. This file is not present in the Win32 distribution for obvious reasons.
Don’t hesitate to comment on RCX’s development, usability, bugs, or suggest new features! The only way things can get fixed or improved is that you make sure I am aware of what needs to be changed. If you think you can help with something else, please tell me!
It’s almost over. Time flies even faster as we get closer to the end of 2010, and apparently there’s a lot to summarize despite we’re not in the finish line yet!
This has been a particularly difficult year for me in a more personal sense, and I’ve faced some trials I won’t speak about and then some, but I’ve also learned new things in the road — things that may be of greater use to me in the future. There’s really a lot that could be said about this year but I’ll restrict it to computer stuff to avoid boring the audience too much bore the audience as much as possible.
