07.20.08
Posted in Life, Software at 8:11 pm by Smokey
Unsurprisingly, a new version of WordPress appeared while I was away in Europe. Once returning, one of the first things on my agenda was upgrading from WordPress 2.5.1 to the new version 2.6. This was going to be my first upgrade using SimpleScripts (a replacement for the once-vaunted Fantastico), and an upgrade to an entirely new version, not simply a small security release, at that, so I was interested to see how the process would play out.
First off, I read the WordPress release announcement and learned that there were very few changes that would adversely affect plugins and themes (the latter very good news, since I’m using a somewhat-customized version of the Ocadia theme and the theme’s author, Becca Wei, seems to have vanished shortly after I installed her theme way back with WordPress 2.0 
). Database backups in hand, I then popped over to my host’s cPanel and opened SimpleScripts; the WordPress 2.6 upgrade was waiting for me. Since I was abroad, I’m not sure when the new version appeared in SimpleScripts, but by my count it’s been five days (two of them a weekend) since the WordPress release announcement, and that beats the best performance I ever saw with Fantastico. I switched back to my WordPress admin page, disabled plugins, and then started the upgrade process. About a minute later, I was running WordPress 2.6. 
So far everything seems to be working fine, the only “side-effect” being a spam comment that snuck in while Akismet was disabled for the upgrade. That’s more bad luck than the fault of SimpleScripts. 
The verdict: SimpleScripts does indeed seem to make upgrades simple!
Permalink
06.24.08
Posted in Camino at 12:05 am by Smokey
Just a brief report on some of last week’s progress:
- Sean Murphy posted an updated version of his anti-phishing patch, as well as a patch that adds the ability for Camino to perform useful action when a user clicks on a XUL button in the content area (buttons which have been proliferating with the move to introduce new error pages for every error type).
- Chris Lawson worked on a few Preferences window-related bugs again last week.
- Over the weekend Samuel Sidler switched one of our G4 minis over to build the
MOZILLA_1_8_BRANCH (as we continue to await the return of our Xserve, which went AWOL in late May), so we once again have nightly builds of what will become Camino 1.6.2 in the near future.
- Towards the end of last week, I gave Ted Mielczarek a few ideas about how to address bug 406088 (make the Mozilla Crash Reporter work better for right-to-left languages) on Mac OS X. I also began preparations for the Camino 1.6.2 release, including compiling the release notes and putting them up for review. Over the weekend I also created a patch that causes Camino to use some
.css files from toolkit/themes/pinstripe/ instead of from the old mozilla/themes, which will lead to better appearance of the aforementioned XUL buttons, among other things.
That’s all for week 25. If I have the time, there might be another summary next weekend; otherwise, this feature will resume after my return from Europe.
Permalink
06.16.08
Posted in Camino, Uncategorized at 10:57 pm by Smokey
I mentioned previously that WWDC and the Camino Meet-Up would probably lead to less Camino work last week, but that wasn’t exactly the case; there was still enough interesting activity for me to write up a brief weekly summary.
- Mike Pinkerton, Stuart Morgan, Nick Kreeger, Jeff Dlouhy, and Peter Jaros all attended WWDC and presumably learned lots of valuable information under NDA. Our fearless leader also pulled a tree on whatever laptop he had with him for the conference, so it’s possible he’s up to something.
- About two-thirds of our active development team made it to California for Saturday’s second-annual meet-up. In addition, Desmond Elliott was patched in from across the pond via voice and video chat, and I joined the video chat during the afternoon. Samuel Sidler will write more about the meet-up, and post a summary to the wiki, in the coming days. There were many fruitful discussions, but, as I understand, the real highlight for Jeff was finding out that I was not, in fact, a figment of everyone’s imagination or some form of artificial intelligence.
- Chris Lawson worked on various bugs over the course of the week, including a patch to remove more Windows ampersand shortcut marks from Core strings that are passed to our alerts. He also worked on fixing a few bugs in our HTML bookmarks importer until Stuart decided to take the old importer out behind the woodshed and put it out of its misery.
- Stuart started fixing some of the lingering problems preventing our chrome from being completely compatible with Apple’s accessibility API, moved most of our menu code over to a newer API, and started working on a replacement for the aforementioned HTML bookmarks importer.
- When he wasn’t on the job or representing Camino at WWDC parties, Sam continued bringing up our replacement tinderboxen (with help from Mark Mentovai on a pesky Ts timeout); we now have two G4 minis cranking out builds while we await the return of our Xserve.
- My contributions for the week were some assistance with the tinderbox configs, a handful of checkins, and finishing the May ad-blocking bug, as well as a bit of the usual triage.
In spite of all the conferring taking place, we weren’t standing completely still on the code front last week. Hopefully this week will see an end to our tinderbox woes and development on Camino 2.0 Alpha 1 can resume in earnest!
Permalink
06.15.08
Posted in Camino, Life, Software at 4:28 pm by Smokey
Ever since I upgraded to Mac OS X 10.5, I’ve been unable to share my 10.5 Mac’s files with any of the other Macs on my local network. This is despite the firewall claiming that AFP is an “allowed service” and happens regardless of whether the firewall is on or off. (My “solution”: continue sharing the disk in my 10.3 Mac, where enabling file sharing Just Works™, and mount that shared volume on the 10.5 Mac.)
By contrast, I joined the second annual Camino Meet-Up remotely yesterday afternoon, and though I’d never used iChat before, all I had to do was open the app and tell Sam my old mac.com username. Poof, there were pink and the gang in San Francisco and Desmond across the pond, all staring back at me and chatting away. No messing with the firewall required.
It’s obvious which task Apple believes is common and therefore optimized. I have no arguments with making video chat completely seamless, either; it’s just that file sharing used to be the same way, from early Mac OS versions all the way up until the arrival of 10.5—why did Apple have to break that?
Permalink
06.10.08
Posted in Camino at 1:38 am by Smokey
Some of you may have noticed it’s been some time since I’ve posted a weekly update on Camino—just over two months, in fact, although there have been a few Camino news posts in the interim. It’s been a busy couple of months for me, so the updates haven’t been on the top of the stack for a while. For the moment, here’s a brief update on what we’ve been doing.
- We released Camino 1.6 and 1.6.1, in 13 languages (though we’re still missing British English and Slovak from the 15 that were in 1.5.x). Samuel Sidler and I updated the website for all the changes and new features in Camino 1.6.
- Sean Murphy fixed a number of issues with our OpenSearch implementation for 1.6.1. When not working on those bugs, he has been hard at work at our phishing and malware prevention implementation; he attached a complete patch last week.
- Chris Lawson jumped back into our preference pane documentation and updated both the text and sample code. He also helped restore our support for a much-used but deprecated AppleEvent in 1.6.1 and has been working on some preferences window and location bar bugs.
- Bryan Atwood recently posted an updated patch for implementing the Flashblock whitelist; it’s currently awaiting review.
- Desmond Elliott (of scrollable tabs fame) has started looking into getting OCUnit set up and some tests written so that we can start unit-testing our own code.
- Stuart Morgan tag-teamed with Sean on the OpenSearch bugs, supplied a few other fixes for 1.6.1, and has been driving the Camino 2.0 Alpha 1 bug list. He landed a few Tabsposé fixes and is currently working on upgrading our version of Sparkle and rewriting our security UI to adapt to trunk changes. Stuart also continued providing milk and cookies to the update system on release days.
- As always, Mark Mentovai has been our fearless build-wrangler, build-stager, tinderbox guru, and the final word on the text of our release notes.
- Sam has been wearing his IT hat recently, coaxing better performance from our webserver and helping track down problems with our tinderboxen. With some help from Mark, Sam restored trunk nightlies by coaxing our 1.24 GHz G4 Mac mini into building. Whenever Sam is done with his IT hat, Philippe Wittenbergh has a few improvements to the website content and style waiting for him to review. In his free time, Sam has also been organizing our second annual contributor meet-up this weekend.
- When I’ve had blocks of time for Camino that haven’t involved releasing new versions, I’ve been fixing a number our various website content bugs. I’ve worked on a few miscellaneous bugs as well.
Whew! That’s a quick summary of the past two months of Camino development.
Most of the team is in California this week, either for WWDC, our second-annual meet-up, or both, so between that and our run-away tinderboxen, it’s unlikely to be a busy week, code-wise.
I hope to get back to updating on a more frequent basis, but regular weekly updates are unlikely to resume until I return from Europe in August, at the earliest.
Permalink
06.08.08
Posted in Life, Software, Uncategorized at 1:03 am by Smokey
Some time ago, Gravatar announced the first round of “improvements” added to the service after having been bought by Automattic (the company behind WordPress, the software that powers افكار و احلام). Among those changes was a buried, but rather unpopular, one: Gravatar had dropped support for images in PNG format and, with that, transparency. Worse, the new Gravatar service had converted all existing PNG images into JPEG images, turning any transparent sections into pure black!
Automattic’s initial responses to the first questions about the deleted PNG support were a bit brain-dead, as others pointed out. I was flabbergasted at how clueless Automattic seemed, and I started working on my own post about the subject. Fortunately, I quickly got distracted with the run-up to Camino 1.6, and the mostly-finished post sat around, awaiting some polish and a conclusion. In the meantime, I also discovered that Automattic had attempted to unify Gravatar and WordPress.com, replacing email-based Gravatar logins with WordPress.com username-based logins. Initially, however, there seemed to be no way to prove you owned a WordPress.com username after Gravatar reported the username was in use.
Since I was busy with Camino releases, I just let my Gravatar complaints sit, the critical post still unfinished, hoping that at some point “soon” Automattic would come back from 1995 and rejoin the PNG era. In addition, I’m not overjoyed at writing involved criticisms of people whose work I’m otherwise fond of, so if I never needed to finish the post, I would be just as happy. Finally, today I happily discovered that Gravatar had indeed come back from 1995 and had restored support for PNGs and transparency. Even better, when I attempted to log in, I could supply my WordPress.com password to prove I owned the username I wanted to use. After that, it was just a quick upload, and my old gravatar plagued with a black line was back to a nice transparent PNG. Nice work, Automattic!
Now, if I could just figure out a good way to add gravatars to this theme, everything would be perfect.
Permalink
06.07.08
Posted in Camino, Software at 5:05 pm by Smokey
It’s pretty rare that I write about a technical topic (or even a mostly-technical topic), since I’m not really what most people would consider a “developer.” When I have written about such things in the past, it has generally been surrounding our feed handler applications, and this time is no different.
Because the feed handlers function as faceless background applications (they simply receive an open location/GURL event, do a tiny bit of processing, then send Camino a open location/GURL with the URL of a web-based feed reader and a feed, and quit), users have the best experience when they don’t even really know the handlers exist. That is, users don’t see the feed handlers launching, and the apps don’t steal focus from what the users may be doing when the apps launch.
Often Mac developers use the LSUIElement key with a value of 1 in their application’s Info.plist to make their application “hidden”—it won’t appear in the Dock or the application switcher—but this doesn’t make an application a real background-only application; if the application has windows, those will still appear (for example, the Mac OS X crash reporter behaves like this), and applications like this can still steal focus. If you have an application that periodically launches and “does stuff,” like Camino’s feed handlers, there are lots of chances for unfortunate focus-stealing.
The solution to this is an alternate property list key, LSBackgroundOnly, for “faceless background applications.” Set this to key to 1 and all is well, right? In most cases, yes; all is well. However, if your application is an AppleScript, as Camino’s feed handlers are, you’ve just set yourself up for a world of random hurt. AppleScript has this old feature where applications configured not to show a “startup screen” (as faceless background applications would be) can still be forced to show the startup screen on launch (if your application does not have a custom startup screen because you never intended for it to show a startup screen, you get a startup screen like this gem 
).
This override-the-decision-not-to-show-a-startup-screen is triggered by whether or not the Ctrl key is pressed when the application launches. In an LSBackgroundOnly application, any UI displayed by the application is stuck in this limbo z-layer, where it is sort-of visible if you move other applications out of the way, but never focusable (on 10.3.9, the startup screen isn’t even visible at all!). As a result, if your LSBackgroundOnly AppleScript application launches when the user is pressing the Ctrl key (in any application: Camino, Finder, Terminal, etc.), the startup screen appears and can’t be dismissed, preventing your application from running or quitting. Yikes! The only way to terminate a stuck LSBackgroundOnly AppleScript application is to use a terminal command or Activity Monitor; neither is very user-friendly, and both assume that your users can figure out what’s happened in the first place.
As a result of this old AppleScript (pointless—why would you ever want to show a startup screen in an application you’d explicitly saved to not have one?) behavior, the user-friendly, impossible-to-notice faceless background-only application becomes a very visible, very unfriendly application staring your users in the face, taunting them because it can’t easily be closed—and, to top it all off, your application isn’t really running, so it can’t even perform whatever function it’s been designed to perform. Unless you can be perfectly sure that your users will never be pressing the Ctrl key when your application might launch, you will find that AppleScript is unsuitable for creating faceless background applications.
Ultimately, someone else will probably rewrite Camino’s feed handlers as tiny Cocoa apps, but for any Apple types out there, I did log this behavior as rdar://5962612 and suggest that LSBackgroundOnly AppleScript applications ignore the Ctrl-to-force-startup-screen behavior (though based on other, less painful, problems this causes, I don’t think many would cry if the Ctrl behavior were sent the way of Mac OS 9).
Permalink
05.26.08
Posted in History, Life at 3:52 pm by Smokey
I’m thankful that our family has not added any more headstones in the past year, despite a number of scares for our older generations. So today I bring you an image of the happy homecoming we wish every military family can have (though it is one that so many of them cannot).
In 1919, two Ardisson families gathered (probably on the family farm outside Delmont) to welcome John Ardison (center, between the two flags) home from his service with the American forces in World War I. The families of Steve Ardisson (my great-great-grandfather) and his brother, Tony Ardison, gathered around picnic tables, just as many of us do this day, for good food and family and to celebrate the safe return from war of John Ardison, Tony’s oldest.
I can’t tell you much more about this photo, only that it was probably taken sometime in the summer, as my own grandfather (born the beginning of May that year) looks to be several months old.
So as we sit at our own picnic tables today, let us remember those who have sacrificed for us and earnestly hope for a return like this one of 1919 for everyone still in harm’s way.
Permalink
05.21.08
Posted in Camino, Life at 1:06 am by Smokey
You may have noticed that we released Camino 1.6.1 today. It was a bit of a long day for me, so here’s a light “by-the-numbers” post.
- 41
- the number of files on caminobrowser.org added or modified in support of this release
- 18
- the number of characters added or changed to update all of our version-specific messages (by comparison, several hundred characters across four files were required for the 1.5 website; thanks, Sam!)
- 14
- the number of minutes it took Mozilla’s Nick Thomas to get Camino 1.6.1 into Bouncer after Mark filed the bug
- 13
- the number of update feed files Stuart generated
- 4
- the number of Camino 1.6.1 MultiLang disk image iterations that Marcello packaged and I QAed
- 3
- the number of disk images Mark staged
- 2
- the number of languages added in 1.6.1 (Czech and Spanish)
- 1
- the number of release candidate builds for Camino 1.6.1
- 0
- the number of things I forgot to change in the blog posts/feed (my favorite statistic!)
Thanks to the whole team for all of the hard work on this release, especially the localizers who came through with post-1.6 string changes, localized feed texts, and returned Spanish and Czech to the multilingual version. As always, we hope everyone enjoys the new version!
Permalink
05.13.08
Posted in Camino, Life, Software at 11:06 pm by Smokey
Flash is already ill-regarded by Mac users for its wretched performance, detested by Linux users for its proprietary nature, and disliked by millions of web users for its general annoyance factor.
The larger problem, though, is that Flash breaks the web and defies established conventions that make the web usable. There are no hyperlinks per se (only clickable spots), no way to determine where clicking will take you, and no way to get back there (that is, no URIs or URLs). Even worse—and one of the reasons Flash is so beloved by certain types of content creators—Flash is a black hole; nothing comes out, which makes Flash entirely inaccessible for reuse, collaboration, or whatever the next great idea on the web is.
Case in point: we’re headed to Oslo this summer for a wedding, and the happy couple are registered at (surprise, surprise) a Norwegian retailer of fine table- and kitchenware. Part of the registry website is plain-old HTML, which means the non-obvious Norwegian words and phrases I encounter can magically become mostly-intelligible English words and phrases thanks to the wonders of Google Translate.
The other part of the store’s registry website, unfortunately, is a series of Flash objects. These are completely opaque to anything that reads the web. Google Translate can’t translate the “button” labels, and I can’t hover over the buttons to see where clicking them will take me (or even inspect the page source to learn the destination, which slightly crazy people have been known to do in order to get useful information). I can’t copy and paste the “button” labels into Google Translate, because, for all intents and purposes, they’re bitmaps, so if I persist in my efforts to have Google Translate decipher the site for me, I have to manually enter some Norwegian text (no non-ASCII characters on these buttons, thankfully). It’s painful, and it’s frustrating that what would “just work” in standard HTML has become a chore that only the most crazed or desperate among us will actually stick with through completion. What’s worse, there seems to be no compelling reason for the “buttons” in question to be Flash; unless the site intentionally desires to obfuscate the destinations of each “button,” the only “functionality” provided by Flash is a hover effect. :hover, anyone?
Perhaps you’re thinking, “this is an unusual/rare/contrived situation; there’s no real-word applicability here.” Unusual or rare, sure, but why cut yourself off from the opportunity to be useful/profitable from every situation presented (Occasionem oblatam tenete —Cicero), when you could just as easily (or perhaps even more easily; surely HTML+CSS is easier than writing a Flash applet?) be open to them? Norwegian retailers don’t have to worry about making their sites accessible to non-Norwegian speakers; Google can do it for them, if only they would use real text, the real web, HTML. No expenditure at all would be required to get this added market, but the retailers could reap the benefits of a scenario they never expected.
Every day on the web, use-cases you haven’t thought of are appearing and becoming mainstream, and in the rapidly changing world of technology, do you really want to be left behind or have to spend extra time and money re-working your site to become compatible with the next great movement on the web?
Please, turn off the Flash.
Permalink
« Previous entries
