Color Reactiveness on the Desktop
For the seven-month period spanning July 1997 to late January 1998, I was involved in an OS development project called InSight. Part of my role within the InSight development group was to study interface designs in an attempt to further understand which aspects would still be viable and useful for users for the next five to seven years. In addition to the interface, I had the opportunity to collaborate on the design of the underlying OS, since much of what we were doing on the visible aspects of the system was tied very heavily to the underlying workings of the OS. Bringing together the design of the desktop and the underlying mechanics of the OS, we hit on what we believed to be a good idea—the concept of color-reactive destop elements.
A lamp is a window element in which the color is tied directly to the operational status of the application using that window. Simply put, it is like a status LED for that particular application. As you use the program, its lamp changes color depending upon what is happening and what you'd like it to reflect—CPU usage, program status, etc.
Let's assume you have an e-mail checker which checks your mailbox every two minutes for new mail. Most of the time the lamp in the window remains blue, meaning it is just sitting around waiting for something to do. Every two minutes it turns yellow to indicate it is busy checking your mailbox for new mail. If no mail is found, it goes back to blue. If new mail is found, it turns yellow or begins flashing.
Beacons are like miniature lamps, meant to be used only when applications are in an iconified state. If you have a window open on your desktop, it has a lamp in one corner of the window. Now, when you click the iconify button, the entire application is collapsed into an icon on your desktop. If you still want to monitor that application, collapse it to a beacon instead of an icon. In that way, you will be able to see what is going on with the application without having to constantly open and close it.
For example, suppose you are downloading five different RPMs via FTP. You can collapse each one down to a beacon with a color that reflects whether or not the download is proceeding without problems. At this point, you have five little beacon icons at the bottom of your screen and you can monitor their progress by checking if they are all still glowing a nice shade of green. You could even set it up so that the color was a function of transfer speed. Bright green could indicate a fast transfer; red could indicate a slow or dead transfer.
In order to fully understand how lamps and beacons behave, keep in mind the fact that the color of the lamp (or of the beacon) can be tied to a variety of “behavior sets” such as CPU usage, process status, or specific events which may occur within specific applications. A “behavior set” dictates what actions will produce what colors. Here are a few practical examples.
Suppose one of the above-mentioned FTP transfers begins to stall. One of the beacons begins to glow red and stays red for several minutes. Simply pop the window back open, kill or restart the transfer. The instant you kill that process, the other four beacons begin to glow more brightly, since you have just improved the speed of the other four by freeing up some bandwidth.
Beacons make the task of babysitting multiple applications a breeze. An entire 3-D rendering package could be collapsed down to a single beacon—one that will turn green when the rendering of a scene was complete, for example. There is no longer any need to continually pop the application back open to see what is going on.
Since the behavior of color-reactive elements should be consistent throughout the desktop, a centralized point of control is needed (in the form of a control panel, for example) to allow the user top-level control. From there, it would also be wise to allow the applications, if permitted by the user, to dictate their own behavior sets. Ultimately, the user must have total and complete freedom to dictate the appearance and behavior of color-reactive elements on his or her desktop.
There are two ways to go about changing the appearance of a lamp or beacon on the desktop. With InSight, the plan was simply to change the icon on the fly by loading the appropriately-colored icon in its place. The second way, which takes considerably more CPU time to accomplish, involves hue-shifting the image data within the icon +/- 180 degrees to achieve the desired color.
The first method requires a small cache of colored icons to be present and ready to be loaded. About eight different colored lamp icons (and eight beacon icons) are usually enough to handle most situations. On the FTP site (ftp://ftp.linuxjournal.com/pub/lj/listings/issue58/) is a file called 3039.zip, containing a small archive of example lamps and beacons in different colors for you to look at and experiment with. The eight colors are clear, blue, aqua, green, yellow, amber, red and purple. That's right—the raw image data has already been provided for you. These icons are, in all respects, ready-to-use.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
- BASH script to log IPs on public web server
1 hour 42 min ago
5 hours 17 min ago
- Reply to comment | Linux Journal
5 hours 50 min ago
- All the articles you talked
8 hours 13 min ago
- All the articles you talked
8 hours 17 min ago
- All the articles you talked
8 hours 18 min ago
12 hours 43 min ago
- Keeping track of IP address
14 hours 34 min ago
- Roll your own dynamic dns
19 hours 47 min ago
- Please correct the URL for Salt Stack's web site
22 hours 58 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?