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.
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.
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.
After so much work, codename “Hakone”, the new website layout and software powering the Wesnoth-UMC-Dev website is finished, bringing with it a series of changes to begin to renew the project for the upcoming new year.
Ancient, old, and new
The Wesnoth-UMC-Dev website has gone through three revisions counting “Hakone” — “Soradoc” and “Kalari” being its predecessors.
My emphasis during the construction of codename “Hakone” was placed on functionality, standards compliance at the web interface level, and a soft, elegant and modern look, all of which I think have been accomplished. Through the integration of technologies such as XML feeds using SimplePie, and the minimalistic yet extensible blog engine provided by Blosxom along with our homegrown Poison Ivy PHP engine, we have achieved our ultimate objective of establishing our own network identity as an independent, parallel project to Battle for Wesnoth.
We have also added an embedded IRC client using freenode’s neat webchat gateway, available from within the Contact section. This should pave the way for further coordination between developers and repository administrators using our official discussion and support channel.
In this opportunity I’ve also opted for standardizing the spelling of our short project name to “Wesnoth-UMC-Dev”, as opposed to the earlier “wesnoth-umc-dev” and “Wesnoth UMC Dev[elopment]”.
There are bugs that remain to be fixed though, which are related to the feeds handling within the various site components — but nothing that is going to matter for the moment due to our rather restricted audience.
So there goes another bit to add to my web design stories, an experience from which I’ve learned a lot of valuable information for my work on “Dorset5”.
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.
The Wesnoth users community has always been rather special compared to other gaming groups. The forumers are usually civilized, they respect the Posting Guidelines, rarely start heated discussions on their own, and follow our moderators and developers’ orders and recommendations.
The development team, our current moderators and I are usually around to help with any thread requiring moderation. Such a pacific community doesn’t require maintenance work like that very often, not counting the insatiable spam generators that never stop coming to attempt to plague the forums with cheap search engine-feeding signatures and gratuitously large ad-posts.
However, a rather recent phenomenon is that of Rent-a-Modding. There are some members who seem to think, consciously or not, that forum moderation works by following a tight set of rules resulting in mechanical procedures fitting every possible situation, derived of course from our Posting Guidelines. Other users attempt to answer to forum posts authored by newbies, by guessing what a developer or moderator would say in such situation, or by copying past moderator reactions.
The behavior I’m describing here is commonly known as backseat-modding, and as Urban Dictionary puts it, they are, effectively, a pain in the ass for actual mods and admins, but it’s not because they look like wannabe-mods, but because most of the time they are doing it wrong!
As I was saying, moderators don’t really follow strict rules to decide how to react to a particular situation, since every situation involves completely different contexts which depend a lot on the poster’s background and past behavior — there is, after all, a reason for handpicking Forum Regulars who might fit the job. This is what makes Rent-a-Mods annoying in the first place, since they can easily give out a really bad impression of our community and standards, scaring away newcomers and spreading bad words about us in other corners of the ’net.
Taking a wild guess of what a Developer will say to a poster regarding a specific development issue, such as Wesnoth’s future plans, or why problem X has not been fixed yet, or why feature Y is apparently never going to be implemented, is also a really Bad Thing™ since it wastes our time correcting the spreading misinformation before it gets stuck in people’s heads. There has been a lot of random guesswork regarding recent problems such as the supposed GNU General Public License violations by the iPhone/iPad port creator and distributor, or why a complaining poster has been banned from the multiplayer server(s) — hence we had to ban both to keep things orderly and avoid the development of useless time-consuming arguments.
In case I’m not getting my point across:
DON’T DO IT. IT’S NOT USEFUL FOR ANY OF THE INVOLVED PARTIES. LET THE MODS DO THEIR JOB.
Thanks for reading. I’m fairly certain that this post might not provide a clear enough answer for cases such as this, but I don’t feel like writing a longer and thorough rant at this moment.
People’s curiosity has no limits, particularly when it comes to Wesnoth add-ons.
In order to reproduce a bug, I had uploaded and removed a test add-on from the add-on servers for 1.8 and trunk several times, yet it seems I forgot to remove it the last time. This hasn’t stopped people from downloading it out of morbid curiosity, although nobody has dared to ask me about it on IRC or the forums. Certainly not news to me, since this is exactly what happened with it the last time prior to its removal.
As of this writing, the 1.8 version has had 949 downloads, as it can be seen in the screenshot above. You’d think an add-on with a description of “FOO” and a misspelled title would not attract anyone to try it, but this principle doesn’t work in practice. Had the add-on contained code to break all other add-ons, people would still not get the idea, I guess. Then again, I’m talking about users who often mistakenly download the source code tarballs and then ask how to install Wesnoth on Windows or Mac OS X.
This is what I get for forgetting to remove this kind of stuff. Thanks Gambit for pointing it out to me this night.
Often on IRC I refer to my computers by their unique hostnames, which I also use to differentiate their Linux kernel configuration sets, optimized for every individual machine.
Many get confused with this because the names aren’t very descriptive of these machines, so here’s some technical background and history for every one of my technological pets.
