the Design Experience Weblog Archive

I have been looking at the XOTcl Object Oriented extension to Tcl, in relation to OpenACS. I don't have any other OO experience so it can be a little confusing. The trickiest concept for me is metaclasses. I found this explanation of the class/metaclass structure in Smalltalk and thought it might help me. The concepts are a little different. As far as I can tell, in Smalltalk every class automatically has a metaclass. In XOTcl it appears you need to define a class as a metaclass and create instances of it. That's about as much as I know, so far, I'll have to revisit this page and reread it.

Another good article I found is Reading Smalltalk which tries to show how to read Smalltalk code, compared to Java or C++.

Joe Gregorio, a very good article describing REST and WDSL 2.0. That is he explains REST in a very detailed way, with some excellent ideas for what REST is and how you could actually use it.

When using REST you need to think about all the nouns in your application. REST allows a limited set of operations on a basically unlimited set of nouns. Nouns are URIs to resources. The operations are GET, PUT, POST, DELETE, those defined by HTTP. Next of course, you need to define what format you'll be sending back and forth. The most common format last year was probably XML. These days folks might use JSON. Both have libraries to parse and build them in most langauages so its not a big deal. Further steps include defining what HTTP status codes will mean, and how to handle other HTTP semantics such as E-Tags to define when a resource has changed.

I am finishing up a web site that needs to exchange data with a Java application running on a user's desktop. We defined a very simple, REST style interface for the exchange. Based on my experience, defining the formats and nouns are the most challanging aspects.

He goes on to examine if WDSL 2.0 could be used to describe a REST service. It appears there are some aspects of a REST service that could not be described with WDSL 2.0. This part is interesting, but I have not learned enough about WDSL to understand it yet.

Ian Piumarta of Viewpoints Research Institute discusses the design priciples behind the system proposed for the Reinvention of Programing in a video presentation (slides). VPRI is where Alan Kay, inventor of Object Oriented programming works.

From the talk, it looks like they are trying to combine the best aspects of objects and functions into a incredibly flexible system. Their goal is a complete desktop system in 20,000 lines of code.

One quote at the beginning, before the whole thing went totally over my head, left an impression.

make things to know, not just to have, because when you do someting really, you don't just understand, you believe

I like the idea of building things to learn something. That is pretty much why in SICP, for example, you write a scheme intepreter, because there is no better way to understand an interpreter.

I have been thinking about Quicksilver, and Gnome Launch Box, apps that make it quick and painless to find what you want, wherever you might have stashed it. I am looking for better ways to take advantage of my computer to get my work done. The idea is to have the least distraction when finding something and acting on it. This might be a web page bookmark, and email, a document you need to work on, an mp3 you want to listen to, so anything else you computer knows what to do with.

Flow is

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing, characterized by a feeling of energized focus, full involvement, and success in the process of the activity.

Applying this to working with the contents and applications of my computer, when I have a task, I don't want to stop, think of which application to open, navigate to a menu, possibly several menus deep, click on the applicaiton, then File, then Open, then navigate the tree structure of my hard drive to find the file before I begin working.

What I want to do is type the first words the come into my head regarding the thing I want to work on. The computer will have indexed my hard drive for full text search, and the most interesting results will come up first, perhaps the files I most recently opened that match the search. I will click the mouse one time, or type one to two keys on the keyboard to begin working with the item.

This means I don't have to lift my hands from the keyboard.Most meaningful interaction with computers still happens from the keyboard. I am a programmer so most of my work is typing. If you aren't a programmer, you are still probably typing documents, spreadsheets, emails, or filling out web forms. All done with the keyboard. Keeping your hands on the keyboard and getting what you want with minimal effort increases flow and minimizes distractions.

This is the reason many people try to do everthing in emacs, for example. You don't have to switch modes of thinking, everything is right there in front of you. I think perhaps there is a way to get closer to that type of interaction without having to keep quite everything inside one application. I have great hopes for the future of tools that let you interact with the computer in a more concise way, that remember what you were doing and make intelligent suggestions.

The fun is just beginning.

Doonald Norman predicts the command line is the future of user interfaces, and discusses some places where the command line has already returned. The two most obvious places, the URL bar in your browser, and the search box on your search engine.

Web app developers, plus many other folks, but I know web hackers best since I am one, have depended on typing URLs to get where they want to go. The URL is one of the interfaces to a web application. Most people just start at one page and click around, but there are power users who will type a URL to get exactly where they want to go.

Another place I see command line like facilities, in a new way, is desktop search. I use Gnome on Unbuntu Linux, so I'll mention what I know about that. There is the deskbar-applet, which lets you type a word or search query, and it will search all kinds of things, including files on your hard drive, google, your email, and many other things. Once you find the item you want, it'll open it in whatever application makes sense for that object.

The even higher performance version of this is Quicksilver for Mac OS X and the Gnome Launch Box which implements a subset of Quicksilver functionality. The ideal of this type of quick search and launcher would be an app that let you chain together a bunch of objects and actions the same way you can use pipes on the command line. Of course there is the new Yahoo Pipes which works for web apps, but isn't really a command line. It a graphical interface. It would be interesting to see a search box command line that let you work with search results in a similar way that Yahoo Pipes does.

I figured out a way to serch inside a directory with gnome-launch-box. Unfortunately, for now, it duplicates the search/query code in lb-window.c and lb-module-files.c. I am sure I'll figure out a way to improve it once I understand what it is doing a little more.

Right now I implemented a window_perform_children_search which will try to find the module implementation for get_children. module_files_get_children is just a copy of module_files_query that takes the URI of a file_item and starts the search from that base directory instead of the users Desktop or home directory.

I also added a feature to the search while typing. Once you descend into searching within an item (directory), i reset the search string, and I check if the browse_history is populated. If it is, we call get_children with the search string instead of query.

I sure hope someone out there is listening, I am interested if I am going in the right direction. The next idea I had was allowing getting children from inside a tar or zip file.

Wow, neat. If you type in a band name (mostly popular US bands?) into google it'll offer more info. When I searched smashing pumpkins, it gave a list of results showing their albums, with cover images, links to track listings, reviews, artistis web site, news, and of course, links to buy the music. It seems to have been around since 2005 according to the google blog.

I added a thread on the forums associated with the original gnome-launch-box developers and asked for advice, and perhaps someone to collaborate with. If anyone is interested in adding features to gnome-launch-box, reply there, or let me know by emailing dave AT thedesignexperience.org.

gnome-launch-box is a nifty application launcher. It is loosely modeled after Quicksilver for Mac OS X.

It basically has a two step process. First search for an item, second choose an
action. For the "files" module, it searches the Desktop by default. It does not descend into subdirectories, so is limited in utility for me. QS has a "browse" feature where you can descend into a subdirectory.

I decided it would be fun to build this feature into gnome-launch-box. Too bad I am not a Gnome hacker or C programmer. I never let that stop me before, and today isn't any different!

I poked around the source code and found lb-module.c which defines the interface for a module. A module is a specific search type. Two examples are files, which searches the Desktop, and bookmarks, which searches Firefox bookmarks. Either one of these could support a browse feature, directories for files, or folders for bookmarks.

Each specific module has its' own C file. lb-modules-files.c for the files module. I added a browse_up and browse_down function for modules. Luckily the module dispatcher checks if a function is implemented before calling it, so I don't have to implement it for every module before testing.

The next thing I needed to edit was lb-window.c where the user interface is implemented. Here is where all the action occurs. I added a handler for the right and left arrow keys. First I just had it display the text "Right!" or "Left!" in the window to prove it was capturing the keys. Next I added a new data structure called browse_history. This is a GList. Luckily GLib implements a nice doubley-linked list so I don't have to learn how that works, just access the nice API.

The next step was adding or removing an entry from the list. My first instinct was to append the entry, but reading the GList documentation, that is slow since it must traverse the whole list. It makes sense to just prepend the item, since in a history we always are only interested in the ends of the list and it works the same to start at the beginning or the end.

That's where I am now. Next I need to figure out a way to notify the user that we are in browse mode, and a way to perform a search "inside" an item. Right now it is not clear the current module interface allows this, but what do I know?

I sure hope I can find some more hackers to help out improving gnome-launch-box, it has great potential. It is not more powerful than the plain old command line, but the potential to keep you in "flow" while working is very good.

I finally got gnome-launch-box to build on Ubuntu 6.10. Here is what I did:

sudo apt-get intsall automake

sudo apt-get install libtool

sudo apt-get intsall intltool

sudo apt-get install libebook1.2-dev

sudo apt-get install libgnome-menu-dev

sudo apt-get install libgnome-vfs-dev

autogen.sh

Copy codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4

  progtest.m4 from /usr/share/aclocal to /usr/share/autoconf/autoconf
wget http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub

wget http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess
I put those last two in the gnome-launch-box source tree root, but I think they might go in

/usr/share/autoconf/autoconf also. It built anyway.

Next I found there are errors in tests/search-home.c. I just skipped running make in that directory for now. I did make install under /src /data/ /extras and gnome-launch-box will now run.

I read about Blanchard's Law

When in the course of developing software, the growing feeling that code generation would be a great idea actually means that the environment or language in which you are working isn’t powerful enough for the task at hand.

from Todd Blanchard and it seems to make sense. I always felt weird writing code to generate a bunch of bolierplate code, It seems if your language, or platform requires you to write a whole bunch of boilerplate code, maybe it needs to be fixed, instead of adding code generation tools.