munky.net

Since I’m starting to use a laptop more frequently these days, I decided to reconfigure my home network a bit so as to centralize my work files. Previously I had kept my work files on my desktop PC and used the Offline Files feature built into Windows 2000 and XP to synchronize a small number of files with an older laptop that I used only occasionally. That scheme worked fine at the time, but since I’m now planning on doing an increasing amount of work on my laptop instead of my desktop I didn’t want to require that my desktop machine be turned on to synchronize files.

Since I have a third machine running linux and MythTV that is on all the time anyway, I decided to set up a Samba share on that machine and make that my work files’ primary repository. An added advantage of the Samba configuration is that I can use rdiff-backup for easy remote backups of the repository. Configuring Samba was relatively painless, and far simpler than I remember it being from a few years ago.

Problems arose when I attempted to set up Offline Files on my laptop to create a local mirror of the files on the Samba share. (more…)

Now that I’ve been using my linux laptop with its new wireless connection, I wanted a way to switch between configurations for home (specific ESSID with encryption) and school (various ESSIDs with no encryption). I struggled with this for awhile using the system-config-network tool, which shows up in xfce as “Network Device Control” under the System menu and used to be called redhat-config-network in the RedHat days. However, I was having trouble getting multiple profiles to work, and the documentation wasn’t helping.

Finally I figured it out with the help of this guide on LinuxPlanet. Apparently settings in the default “Common” profile actually affects all profiles, which is why I was unable to get my Common (home) and School profiles to maintain separate settings. The key is to ignore the Common profile and create discrete new profiles for each actual set of settings you want to use.

(more…)

I’m posting this with the hope that someone in a similar situation might come across it on a Google search and find some helpful information.

This evening I managed to get a cheap ($10 after rebates at Fry’s) Buffalo WLI-CB-G54L wireless PCMCIA card working in my aging Sony Vaio PCG-F540 (Pentium III) laptop, which I just upgraded to Fedora Core 3. This card is based on the Texas Instruments ACX 111 chip, which lacks any sort of official Linux driver support from the manufacturer. Although there is an open-source project to create a native Linux driver for this device, that driver in its present state does not support WEP encryption, and I wasn’t about to run an unsecured wireless network. My only other option was to use the ndiswrapper package, which basically allows binary Windows XP wireless drivers to work in Linux. Amazingly enough, it ended up working.

(more…)

Ever since Flash MX 2004 Pro was released, I’ve been struggling with the question of how to create a lightweight preloader for movies that use v2 components. The basic problem is that the v2 components come with a large ActionScript class library that can add a substantial amount to even small movies that use even one component.

For awhile I’d been using an approach that involved a small preloader movie that displayed a loading animation and progress bar, and used loadMovie() to load the content movie (with components) into an empty clip. This worked in many cases, but it turns out that there are some v2 components, such as ComboBox and Window, that don’t work properly when they’re loaded into a sub-clip in this manner. Basically, those components contain code that makes explicit references to the _root timeline, which is a no-no. The Macromedia docs suggest using the _lockroot property on the target clip in order to trick the components into seeing the proper timeline as _root, but in my experiments I have found that this does not always work.

Recently, thanks to an entry in Jesse Warden’s blog, have been able to create a preloader that works with movies that use v2 components. As an added bonus, the preloader does not need to reside in a separate swf file, and thus doesn’t need to mess with _lockroot — it can be implemented as part of the main movie. I’ll describe the steps needed to accomplish this below, if for no other purpose than to remind myself of what I did!

Start with a movie that uses v2 components. Open up the library and identify these two types of symbols:

1. all component symbols (Button, ComboBox, Label, Window, etc.)
2. all compiled clips and/or movie clips that will be dynamically instantiated at runtime; this includes View symbols for window and accordion contents, component skin symbols, etc.

I usually keep these types of symbols in a separate folder in the library. For each of these symbols, right click and open the “Linkage…” dialog, and deselect “Export in first frame”. This prevents the code and assets for those symbols from being loaded at the very beginning of the movie, which means we’ll be able to put up a preloader before those start loading. It’s very imporant to indentify all components and dynamically instantiated symbols used in the movie and edit their library symbol entries in this way.

One important exception to this is the DataBindingClasses symbol that gets added to the library automatically whenever you use a v2 component in a movie. This symbol needs to have “Export in first frame” checked. I think the reason for this is that it needs to load before any components do. At any rate, even though we’re leaving it as one of the things that gets loaded at the very beginning of the movie, it’s not very large so it shouldn’t affect the preloader loading time too much.

The next step is to add three blank keyframes to the very beginning of the main timeline. There should initially be nothing at all on the stage on these frames; in other words, all your main movie content needs to be shifted three frames to the right. At this point I also usually add a new movie layer called “preloader”, and I’m also assuming that you already have a “script” or “code” layer that contains only frame actions.

The first two of the three new frames will be used for the preloader loop. Frame 1 actions should look like this:

// Frame 1 actions
trace(getBytesLoaded()+" of "+getBytesTotal());
if (getBytesLoaded() > 0 && getBytesLoaded() >= getBytesTotal()) gotoAndPlay(3);

Of course the trace is optional, and could be replaced with a line that sets the percentage loaded value on a progress bar or other indicator. Next, set this line as the frame 2 action:

// Frame 2 actions
gotoAndPlay(1);

These two frame actions are just the typical way to “pause” a movie until the whole swf file has loaded on the client machine. Once the entire movie has loaded, the playhead is allowed to proceed to frame 3. Your lightweight preloader animation and/or loading indicator can be put on the stage on the “preloader” layer spanning frames 1 and 2, so that they are visible during the preloading process.

The next step is to create a special frame on frame 3, which contains instances of all the symbols for which we unchecked “Export in first frame” in the first step (this is why we organized them into a special library folder earlier). Create a blank keyframe at frame 3 on the preloader layer and drag one instance of each such component onto the stage but outside the movie’s viewable area. What we’re doing here is telling the Flash compiler that it will indeed need to load these assets for use on frame 3 and beyond (since it’s not going to load them at the beginning of the movie as usual). These component instances don’t have to stay on the stage past frame 3; a brief appearance on this single frame is enough to tell the compiler when they need to be loaded.

The observant reader will note that it’s not actually necessary for each and every one of these clips to be instantiated on frame 3, since many of them probably appear on the timeline later on past frame 3 anyway. Technically this is true — all we really need is for each symbol that gets dynamically instantiated by application ActionScript code, and therefore isn’t statically placed on the timeline in the authoring environment — to be instantiated in this way on frame 3. This includes some components, namely Window, which tends to be instantiated at runtime using the PopupManager class. However, it doesn’t hurt just to instantiate everything on frame 3, so I’m recommending that as a less error-prone approach.

The final — and quite critical — step is to tell the compiler that ActionScript classes should be loaded on frame 3 instead of frame 1. This can be done by going to the dialog at File Publish Settings… Flash (ActionScript) Settings… and setting the “Export Frame for Classes” value to 3. This prevents the huge chunk of ActionScript class code that comes along with the v2 components from being loaded at the beginning of the movie and thus trumping the preloader. The important thing is that the class export frame be no later than the frame on which the symbols that use those classes first appear.

At this point your timeline should look something like this:

In the above image, the frame colors correspond to:

• orange: the two script frames with the preloader loop actions described above
• green: any lightweight preloader animation and/or loading indicator clips
• yellow: the special frame on which any dynamically instantiated symbols are manually instantiated on the stage but outside the viewable area
• blue: the main movie that is being preloaded

You should be able to verify that the loading sequence is working as intended by selecting “generate size report” on the Flash Publish Settings dialog, and examining the report to ensure that the bulk of the movie doesn’t get loaded until frame 3.

Some design patterns require the use of a static initializer, a block of code that should execute once and only once the first time a class is referred to. The typical use for this pattern in ActionScript programming is when a mix-in class needs to be used, as in the case of the mx.events.EventDispatcher class. EventDispatcher contains a static method, EventDispatcher.initialize(), which can be invoked to add the event framework methods to any arbitrary class.

Say we have a class called ActionManager that needs the event handling mix-in methods. One approach would be to invoke EventDispatcher.initialize(this) in ActionManager’s constructor method; however, this approach suffers from the drawback that the EventDispatcher initializer could be invoked multiple times (each time a new ActionManger instance is created), when it really only should be invoked once.

If we were programming in Java, we’d be able to do something like this, using the static initializer syntax:

public class ActionManager {
static {
mx.events.EventDispatcher.initialize(ActionManager.class);
}
public ActionManager() {
...
}
...
}

Now, ActionScript doesn’t have this sort of static block syntax, but fortunately there is a way to accomplish the same thing:

class ActionManager {
private var staticInitialized:Boolean = staticInitializer();
private static function staticInitializer(Void):Boolean {
mx.events.EventDispatcher.initialize(ActionManager.prototype);
return true;
}
public function ActionManager(Void) {
...
}
}

The ActionScript pattern illustrated above does the same thing as Java’s static initializer block syntax — the staticInitializer() method will only be called once, the first time the class is referenced, and before the constructor method is invoked.

Although this pattern is typically used to set up mix-in classes such as EventDispatcher, it is also useful for setting up arbitrary static class memebers such as lookup tables, etc., which only need to be calculated once across all instances of a class.