So I need to update my website a bit. After a bit o reorganization and backend rework. But, in the spirit of Useful Information Now, I’m going to make it easy for people to see my reputation online. For right now it’s just wxWidgets links, because I’m out of time (and I do have a decent sized presence in the wx community), but I’ll add more links to categories eventually.

wxWidgets Community:

• wxWidgets mailing list/newsgroup: Search “Ryan Wilcox”. I’m not as active here as I used to be, opting usually for the web based forums (since they have an RSS feed that I can narrow down just the topics I’m interested in.)
• WxWidgets Web Forum: Search “Ryan Wilcox”
• WxWidgets Developer List: Most of my posts here either concern wxMac, or are patches for wxMac. Mostly little tweaky bug fixes here and there, to make the user experience better. Search “Ryan Wilcox“
• wxWidgets posts on my blog: search wxWidgets. You might also want to try wxWindows, since I’ve been around since before the project’s name changed to wxWidgets.

I use appscript - a Python module letting me talk to scriptable applications on the Mac - everywhere I can. It means I can write less in the verbose, cranky, sometimes read-only AppleScript.

Appscript is nice, but in earlier versions seemed very… verbose. Where AppleScript did all kinds of magic behind the scenes, appscript made you do a lot of that stuff yourself.

Today I was working on getting an object’s reference’s value from appscript. In Applescript this is easy:


tell app "Microsoft Word" to get selection's selection start

(Maybe Word isn’t the best example of this, but it’s what I’m working in now…)

In appscript I’ve always struggled with how to get and set values in appscript. Not today, since I’ve discovered there are three ways of doing it (shown here from the Python Interpreter, one of the great tools for appscript: piece together things line by line interactively!)


>>> msw = app("Microsoft Word")
>>> msw.selection.selection_start.get()
48
>>> msw.selection.selection_start()
48
>>> msw.get( msw.selection.selection_start )
48


The first get() call is the one I’ve been using since early in appscript’s development. Entire reference (the subject), than the verb. It’s very OOP smelling, OBJECT then VERB. You see this everywhere, including Python.

The second get() call is one I didn’t know about until I read the appscript manual just today: once you have a reference, call it like a function and you’ll get its value. That’s a great shortcut, and feels somewhat OOP too.

The third get() call is one I just discovered, and probably the most familiar to AppleScript programmers. Much of Applescript works on VERB then OBJECT, because it could be considered not a class based object oriented programming language. So here we are: GET the selection object’s selection start).

It’ll be a toss-up for me whither I’ll use the second or the third form of the “get idiom”, but I’ve always found the first to be too literal, personally. I’m glad there are other forms.

Oh, and PS: appscript has had addressing by creator code, bundle identifier, path, as well as name and eppc URL since very early in its development. Thanks for catching up, Applescript. <nudge />

Steven Frank: Betas and Testing

Lots of truth in the article, from both ends (running a beta cycle, being in QA, and also giving some advice to people in a beta testing program. My advice for the latter group would be: test, let people know that you’re testing, even if you haven’t found any problems in the areas you’ve explored. Basically, let the people running the beta cycle that you’ve gone fishing in this part of the application and haven’t caught anything.)

But I have to point this out:

I’ve researched automated testing with products like Eggplant, with mixed results. I’m a big advocate of unit testing, but in practice, it always seems to get back-burnered, and is not easy enough to do with predominantly GUI-driven applications.

You can have all the unit tests in the world, but if the logic connecting your view component to everything else doesn’t work, the program doesn’t work. I know this point all too well. So testing (internal QA and beta testing) are very useful.

The beta testing being a check on internal QA: making sure the internal QA does its job well, and also going above internal QA, trying oddball stuff that internal QA wouldn’t think of. When you work with a product day in and day out it’s easy to test and use the app only the way that makes sense to you - or to the development group - but people may use the app differently in the real world. People will zig when you are expecting them to zag. Which is also why you need beta testers, even if you have automated tests.

For the last 2 weeks I’ve been down to only one machine, from my usual two development machines. Mishap with the power connector when replacing the hard drive in my iBook. Thanks to the good folks at DT&T Computer Services (who fixed, vs replaced, my motherboard), my machine is back up and running. Service from them was great (although they were having email sending issues so I had to call them to get my RMA number, and it seems like you have to send them an email to check the status of your machine).

I develop different projects on different machines, so when one machine goes down I have to set up the project on the other machine. Sometimes this is easy… sometimes not. One project quickly moved over (aside from some productivity hits), one project moved over except for talking to some hardware (which I just didn’t bother to set up), and one project I couldn’t compile the support libraries for ( first wxWidgets compile/link oddities, then wxWebKit link errors. Big C++ libraries are quite a pain sometimes).

The iBook is back up and running, so progress can move forward at a slightly faster (and portable!) pace once again.

On the machine front, yesterday I spent a good chunk of time updating my Debian server to the latest of everything. That did mean the blogs and the wiki were flaky yesterday, but they’re back to normal today.

My blog now looks like the rest of my site, almost a year after I moved to Wordpress.

Thanks go to my sister, who, thanks to a bit of HTML knowledge from high school, was able to piece together this WordPress theme for me (while I was making money other places). Thanks Mara!

Given Apple’s 64 Bit Carbon plans, a lot of people are wondering if Carbon is dead (or not). (See one example of this over at Michael Tsai’s blog entry on 64-bit Carbon).

All I have to say here: there’s an advantage here that wxWidgets brings me: one can hope that the wxCocoa port of wxWidgets will step up to the plate. If it does (and I’ll probably pitch in here), then I just recompile my wxWidgets apps with wxCocoa, and I’ve made a major shift already. No rewriting all of my view (or controller) code, just recompile the underlaying library. Since wxWidgets is an abstraction, it just abstracted the API change away from me.

The only thing I would need to rework in my apps would be the places where I’ve called Carbon routines directly to provide Mac OS specific features, or where I’ve modified wxWidgets and now need to rewrite my modifications.

Every once in a while I have to write some Core Graphics code. (Lately it’s been code to draw custom HIView subclasses, but I digress).

I only do this once in a while, so I always spend some time fighting with primitives and coordinates and just drawing. In C based languages a change in a source file means a whole new compile-link-run cycle, and if your application is big this could mean a minute or two waiting, and a minute getting to the right spot - just to find out that “nope, that doesn’t work”.

There’s a better way: Python. DrawBot and NodeBox.

The drawing API of DrawBot (and NodeBox, which is based off DrawBot code) feels a lot like Core Graphics’ NSGraphicsContext/CGGraphicsContext APIs (thanks to their OS X and Quartz heritage, no doubt). Meaning that you can try CoreGraphics code out (almost) interactively.

Using DrawBot’s thinly veiled CoreGraphics API you can type some code, run your Python code, and the result is displayed in a little pane beside the code browser. No compile cycle, no making a New Project in XCode so you can test your code quickly: just type, run look. Nothing could be simpler.

The March Issue of Linux Journal has one of my articles in it: MochiKit By Example. The article shows off MochiKit by working through 3 examples of increasing complexity, with the final example being a totally dynamic login screen!

This experience is extra cool for me because the full article is available online for free. I’m very proud and grateful to the Linux Journal people for the distinction.

So if you work with JavaScript, love it, hate it, or don’t know enough about it, pick up Linux Journal at your neighborhood newsstand!

The Oompa-Loompa trojan has caused a bit of stir in the Mac community. Our first, self-replicating “virus”. (Although technically it requires multiple user actions, as opposed to say, simply inserting a floppy disk or reading an email).

Oddly enough, there was recently a hubub in the Mac community about Smart Crash Reports, an Input Manager that will send crash logs to developers if their app crashes on you. Some of this information can be used to combat Oompa-Loompa, an Input Manager based trojan.

Smart Crash Reports is useful for developers because, while Apple provides a nice “Do you want to submit a report to Apple?” third party developers who write many of the apps you use every day don’t see these reports. The people who can fix the problems never actually see the reports. Smart Crash Reports is a useful, if maybe overly aggressive, tool for software developers to use. It also had a habit of being silently installed by some applications (although the latest beta of Smart Crash Reports is much better about asking the user’s permission to install.)

Input Managers fundamentally change the environment of running applications. Like most things, this is usually used for good. Just not in the case of Oompa-Loompa.

Read more to find out various ways to make for a safer Input Manager experience, and combat applications installing them behind your back.

(more…)

I spent a few hours with MochiKit, getting a feel for this neat JavaScript framework, and doing some dynamic HTML (aka: AJAX) programming too.

For a simple example of these technologies I created a demo of a Dynamic Shopping Cart. The sample dynamically recomputes the price of a line item (and the total of the bill) in response to user events.

Check it out!