Archive for November, 2009

Reference content from chrome in Mozilla Firefox

November 28, 2009

This is a snippet of text from Working with windows in chrome code:

In case of <browser type="content-primary" />, you can use the content shortcut property to access the Window object of the content document. You can use content.document in a browser.xul overlay to access the web page in the selected tab in a Firefox window. For example:

//alerts selected text in the main content
// alerts the title of the document displayed in the content-primary widget

There is no shortcut for accessing document in the sidebar. You need to use





like when Accessing content documents

Works in Firefox 3.5.5.


chrome.manifest cannot be encoded in UTF-8

November 27, 2009

I am following the awesome 2X45 minute video tutorial on the Firefox “helloworld” extension bootcamp (with copy-and-paste code).

The error console kept giving me the following warning:

“Warning: Ignoring unrecognized chrome manifest instruction.
Source file: file:///D:/Profiles/smallbug1960/Projects/hellowrold/chrome.manifest Line: 1”

(There was a couple of other messages/warnings/errors underneath this one which I failed to duplicate.)

I spent “significant amount of time”- a couple of hours, to be more precise – before finally figured it out. It turned out that I had the chrome.manifest encoded in UTF-8; once I turned it in ANSI, the errors/warnings went away and the long expected “Hello world!” button finally showed up under the status bar!

BTW, I am on Windows XP Professional/Firefox v3.5.5, if that matters.

ListView and ListActivity Demo

November 26, 2009

This is a slightly modified version at apiDemo. It demonstrates how you select multiple items on a ListView and display the results on a TextView.

main.xml layout (Note that the ListView has “choiceMode” set as “multipleChoice” and that the ListView has an id of “@android:id/list”):

<?xml version=”1.0″ encoding=”utf-8″?>
<LinearLayout xmlns:android=”;
android:text=” ”

Main java class:


import android.os.Bundle;
import android.util.Log;
import android.util.SparseBooleanArray;
import android.view.View;
import android.widget.ArrayAdapter;
import android.widget.ListView;
import android.widget.TextView;

public class ListAdapterTest extends ListActivity {

String[] items= {“lorem”, “ipsum”, “dolor”, “sit”, “amet”,
“consectetuer”, “adipiscing”, “elit”, “morbi”, “vel”,
“ligula”, “vitae”, “arcu”, “aliquet”, “mollis”,
“etiam”, “vel”, “erat”, “placerat”, “ante”,
“porttitor”, “sodales”, “pellentesque”, “augue”, “purus”};

TextView selection;

public void onCreate(Bundle savedInstanceState) {
setListAdapter(new ArrayAdapter<String>(this,
selection = (TextView) findViewById(;
protected void onListItemClick(ListView parent, View v, int position, long id) {
// Clear the TextView before we assign the new content.
selection.setText(” “);
// get array of booleans for which positions are selected in the items.
// This SparseBooleanArray object contains an array of boolean values paired with keys,
// which can be accessed using valueAt(index) and keyAt(index) respectively.
SparseBooleanArray chosen = parent.getCheckedItemPositions();
for(int i=0; i<chosen.size(); i++) {
Log.d(“selection”, “index: “+i+”; key: “+chosen.keyAt(i)+”; value: “+chosen.valueAt(i)+”; “+items[chosen.keyAt(i)]);
// if the item is selected by the user, we display it on the TextView.
if(chosen.valueAt(i)) {
selection.append(items[chosen.keyAt(i)]+” “);


November 26, 2009

I am always confused by the word “focus” (in the context of user interface, which embarrasses me very much since I am making a living as a “user interface designer”.)  Now I think I am a little clear about the meaning of it so just a note for myself.

In the WIMP environment, for a pointing device such as a mouse, it’s always clear where the “focus” is: it’s always where you point your mouse towards. In this kind of paradigm, the spatial input is continuous.  But in the context of a non-desktop environment where you use a D-pad; or in the WIMP if you use the keyboard as your current input, it’s not always clear where the input is. The concept of “focus” is used to indicate where the spatial input is currently in the GUI. If a UI element has the focus, I guess it depends on what kind of control it is, it can behave slightly differently. For a button, it means it will react as if it “received a mouse click” if the user presses the enter key; For an editable text field, it means it has a caret cursor inside it and is ready to take keyboard input (if you type something they will go into the text field in focus); For a hyperlink, it does the same thing if you press the enter key as if you click directly on it (normally load the page it links to:).)

Note that the visual feedback and behavior for the keyboard input/”discrete spatial input” paradigm is normally different from that of the mouse input/”continuous spatial input” (and also different from that of the touch input — more on this later). In the picture below, it shows the “Go” button is in focus while the “Search” button has a mouse hover.

Fig 1.

Focus on tab vs. mouse hover

Focus on tab vs. mouse hover

Here is some notes:

1. A UI element can be “disabled” but still receives focus. See figure 2-4.

Fig 2.

"Ok" button is disabled

"Ok" button is disabled

Fig 3.

"Cancel" button is in focus

"Cancel" button is in focus

Fig 4.

"Ok" button is in focus

"Ok" button is in focus

2.  In MSDN glossary, it says “input focus” means “The location where the user is currently directing input. Note that just because a location in the UI is highlighted does not necessarily mean this location has input focus.” I guess the scenario is when you are hovering the mouse over an UI element?

3. Touch screen paradigms. As in iPhone, Android opt not to deal focus (showing highlight or any other visuals) in “touch mode“. An interesting reflection is about potentially different interaction paradigms for capacitive touch vs. resistive touch. Can the level of pressure be reflected as whether the UI receives the focus as opposed to take a “click”? Will the “80 percent” of the users be surprised and/or confused?

4. Design guideline for “Input focus location” at MSDN.

5. Besides the keyboard, D-pad, mouse and touch, there is another scenario where the focus can be acquired: that is by code. When a focus is acquired programmatically, the UI behaves as if it’s acquired by a user tabbing the keyboard/D-pad.

6. It’s safe to say for now, the rationale for designing co-existent interaction paradigms is that you should treat the UI as if the user has multiple input/pointing devices at hand (mouse, d-pad, keyboard tabs/arrow keys, fingers). UI shall give feedback respectively to each of the input mechanisms. One input device shall not interfere with the behaviors of the others. For example, tabbing to get another UI element in focus should not result in your mouse cursor changing its current location.

Refer to component in Flex with curly braces

November 3, 2009

Always use curly braces/brackets to refer to your component by id. Like this:

<mx:Panel …

<pg:ShakeEffect id=”shake”/>


You can probably do without the curly brace to refer to an effect component if you are in the main application mxml; but it won’t work for a component.

See also:

Curly Braces in Flex Control Properties