Silent Coding
For those of you who have been wondering why I haven’t pushed any revisions to Universal Applets lately, this video should be enough of an explanation. (Thanks to Qball for taking the screencast.)
No, that’s not a simple Applet/Screenlet. The bouncing ball is going to be integrated with Universal Applets in some extremely nifty ways.
Universal Applets Update
I’m reposting a shortened version of this email to the Gnome-love list. The bolded bit talks about the project’s current status.
…
I’m trying to fix the problem by creating a universal applets framework for GNOME that’s mostly based on Screenlets. The goal is to create a common applet format that can be easily loaded into any gtk (and even qt) application without forcing the applet developer to give up on specialized applet functionality.
The framework consists of two main parts- Screenlets and ScreenletContainers. Both are written in Python, but can easily be reimplemented in C or in any other language.
Screenlets contain a gtk.Layout. They can pack widgets into the gtk.Layout, draw on it, or do both. Screenlets support theming, editable options (options which save real time and can be edited with a gui), and DBUS services without any extra work on the developers part. They are completely scalable.
ScreenletContainers are responsible for loading and displaying Screenlets. The ScreenletContainer base class implements most of the functions necessary for loading and showing a Screenlet in a generic location. Any application can import the ScreenletContainer class and use it directly (or subclass it) to add on support for Screenlets.
There is a ToplevelContainer class which descends from ScreenletContainer and is responsible for embedding Screenlets in a toplevel window. ToplevelContainer adds on a few extra options for displaying Screenlets. (E.g. “keep above other windows”, “show on all desktops”, “show as a compiz fusion widget”, and so on and so forth.)
Right now, screenlets interact with their containers using hacked legacy code. Eventually, all communication will be done via DBUS and the screenlet will be embedded inside the container using GtkPlugs/Sockets. Dragging a screenlet from the desktop to Awn, Gnome-panel, or Kiba Dock will resize the screenlet and embed it in the dock/panel optionally only showing an icon sized preview.
Due to the way that things are going to be implemented, application developers will be able to wrap parts of their apps inside Screenlets. For example, if you have GIMP running, you’ll be able to pop the ruler screenlet out of GIMP and drag it on to your desktop. When you’re done using it on the desktop, you’ll be able to either dock it in the panel or drag it back into GIMP or even another app like Inkscape.
A few weeks ago I wrote up a post explaining the rationale behind the idea. You can find it here: http://theesylum.com/2008/02
The code is on launchpad here. One or two of the old screenlets may not work due to the major changes I’ve made lately. I’m going to push a revision in a few minutes fixing some of them.
Just to clarify, I’m (currently) the only developer working on this and (at this point) the code is independant of the Screenlets project. If anyone is interested in helping out then please email me.
Natan
Desktop 2.0
Update: Please see this forum thread for details.
What is “Desktop 2.0?”
“Desktop 2.0″ is to the operating system what Web 2.0 is to the Internet. The following are the key elements of Desktop 2.0 (unless you’re new to Linux, you may want to skip a large part of the following explanation and go directly to here):
- Mini programs that provide instant access to information. (E.g. Mac OS X Widgets, Vista Gadgets, Awn Applets, Screenlets, etc.)
- Instant access to information via “all in one” search applications. (E.g. Spotlight, Deskbar, Affinity, and Vista Instant Search)
- Web Desktops that try to close the gap between the Internet and the Desktop. In other words, applications that let you access online services (e.g. Facebook and email) without opening a browser. (E.g. The GNOME Online Desktop.)
- New “desktop shells” that have new designs and focus on ease of use. The term “desktop shell,” is explained here as: “The shell is what users interact with on their computer, and includes everything from how buttons look and window animations to where menus appear and how you browse through files on your hard drive.” The explanation is talking about Windows and things are slightly more complicated on Linux. Nevertheless, the explanation is good enough for out purposes. (Examples of new desktop shells are Gimmie, Awn, Plasma, and Cairo Shell)
- Design matters! All across the board, we’re seeing a new focus on aesthetics, design, and eyecandy.
Note that many of the above elements often overlap
The following are the GNOME Desktop 2.0 apps that show the most potential:
- Awn- Awn started out as a dock and rapidly developed until it had went far beyond its original goals. It is becoming a full desktop shell and its main feature (from a Desktop 2.0 standpoint) are Awn Applets. Awn Applets are mini programs that often connect the user to the web (for example, the Gmail, Digg, and Last.fm applets) and add on innovative ways of interacting with the desktop (for example, the Stacks applet).
- Gimmie- Gimmie is a unique desktop organizer for Linux. It’s designed to allow easy interaction with all the applications, contacts, documents and other things you use every day. (The above was taken from the Gimmie website.)
- Screenlets- Screenlets are small applications (written in Python) that can be described as “the virtual representation of things lying/standing around on your desk.” (E.g. Sticknotes, clocks, rulers, etc.) The goal of Screenlets is to simplify the creation of fully themeable mini-apps that each solve basic desktop-work-related needs and generally improve the usability and eye-candy of the modern Linux desktop.
- The Online Desktop- The goal of the GNOME Online Desktop is to adapt the desktop to become the perfect window for online applications like GMail, Photobucket, Facebook, EBay, and Wikipedia.
- Deskbar- Deskbar is a search bar for GNOME. It supports plugins (called handlers) that allow you to instantly search for anything including emails, local files on your computer, and webpages all with one click of the mouse.
The Problem
Due to Linux’s open nature, code should be easily reusable and developers should be able to work together and build on each others work. Unfortunately, that’s not at all what’s happening.
- The GNOME community is strongly against anything that can be thought of as “GNOME 3.0.” The GNOME philosophy is that slow gradual improvement is better than major change. In general, that’s fine. However, it has lead to a situation where there is no long term roadmap for a GNOME 3.0 and there are multiple GNOME Desktop 2.0 apps that are being developed independent of GNOME. There needs to be a common vision, goal, and plan.
- Most of the Desktop 2.0 apps that are being developed for GNOME share common goals and overlap in functionality. The communication between the different projects is virtually nonexistent.
- Many Awn Applets, Screenlets, Online Desktop “stocks”, and Deskbar search plugins do the exact same thing. There’s lots of duplicate code out there, and multiple developers are working on almost the exact same things without any collaboration. For example, there’s a Gmail Applet for Awn, a Gmail screenlet, a Gmail “stock” for the Online Desktop (I’m “guilty” of coding that one), and a Gmail search plugin for Deskbar. They all share common code and it’s extremely inefficient from a technical and practical point of view.
A Possible Solution
- There must be a universal applet format. Applets, Screenlets, and “Stocks” all do the exact same thing. Online Desktop Stocks support searche queries and many of them overlap with Deskbar plugins. (E.g. both of them have a plugin/stock to search for files.) There needs to be one applet format that can be loaded by or plugged into any of the aforementioned applications.
- It’s not enough to use the same format. There should also be a Global Applets/Services Server. The server should handle everything related to the applets (e.g. loading them, reading/writing preferences, etc.) except for actually drawing them on the screen. The drawing and positioning on the screen can be handled by apps like Awn and Screenlets.
- Applets should even be able to run without actually being drawn on the screen.
- Example: A Gmail applet should be able to run as a normal Screenlet, an Awn Applet, and a “Service.” If it is run as a “service”, it shouldn’t be displayed on the screen. (In that case, it would notify the user of new emails soley via DBUS and Gnome-Notifications.)
- The Deskbar should be able to query all currently running applets for information. For example, it should be able to connect to the already running Gmail service or applet and request all emails with the topic “This is a search.”
The logical place to begin coding a Applets Server would be Screenlets. It may make the most sense to split Screenlets (assuming the developers agree, of course) into a core server (like the one mentioned above) and a seperate application that actually draws the Applets/Screenlets on the screen. (I’ll write more about this in a later post, so sorry if it doesn’t make any sense now. The point of this post is to explain the why and not the how.)
Other Conclusions
The Online Desktop, Awn Applets, Screenlets, Gimmie, and Deskbar often overlap. There needs to be more reuse and sharing of code. Universal Applets is only a start.
This article focused only on the GNOME desktop. A comparison to how KDE does things would be interesting. In doing research for this post I ran into KDE Plasmoids. I haven’t tried them yet, but they seem to be a KDE equivalent
Awn-Terminal 0.4
For those of you that haven’t been following on the Awn forums, I wrote Awn Terminal, my first applet for Awn, last week.
I’ve put in some more work (and spent some time wondering whether its even possible to come up with a more unintuitive system than gconf), and version 0.4 is now done.
Instead of listing all of the new features, I’ll just throw in a few screenshots.
Repository For Ubuntu Updated
I’ve updated my repository for Ubuntu PowerPC. Its located here. It contains cutting edge versions of Compiz Fusion and Awn.
1) Adding the repository
Edit /etc/apt/sources.list and add the following line for Feisty:
deb http://repository.theesylum.com feisty eyecandy
For Gutsy:
# Compiz Fusion deb http://repository.theesylum.com gutsy compiz-fusion # Awn and other eyecandy goodness deb http://repository.theesylum.com gutsy eyecandy
Update your list of packages with
sudo apt-get update
2) Removing the old packages (Gutsy only)
If you’re on Gutsy then run this command first to get rid of the official packages:
echo "aptitude -y remove" `sudo dpkg -l | egrep '(beryl|emerald|compiz)'| awk '{print $2}'` | sudo bash
3) Installing Compiz Fusion
To install Compiz:
sudo apt-get install compiz # compiz-gnome AND/OR compiz-kde
To install CompizConfig configurator:
sudo apt-get install compizconfig-settings-manager # libcompizconfig-backends-* ?!
To install all of the assorted plugins:
sudo apt-get install compiz-fusion-*
4) Running Compiz Fusion
Eventually I’d like to package fusion-icon. Fusion-icon is a starter script that will pass different options to compiz depending on your configuration. Until I do so, you can simply start compiz with the following:
compiz --replace
5) Installing Awn
Run the following:
sudo apt-get install avant-window-navigator
I’m going to also add a package for awn-extras soon.
About Me
20 year old undergrad in CS & Physics, co-founder of Freeversation, faux CEO of Politician Market, and former software developer at Check Point.
I am interested in social startups, information security, and robotics. Read more about me
Contact
Email aantny [at] gmail [dot] com. If it's interesting, I can code it.