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/01/desktop-20/. There is also a forum thread on the idea here.Please note that much of the information in the first few posts about implementing the idea is no longer relevant.

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

I just pushed the first real commit of my branch of Screenlets to Launchpad.

It’s still a regression from the end users perspective. Don’t bother looking at it unless you’re a developer.  There’s a slightly longer explanation here.

Quick side note: I really need to write a whole post about GHOP. For now, I’d just like to (publicly) give my thanks to everyone who participated and made it happen. You know who you are, and my email to the GHOP mailing list will have to suffice until I have the time to write a post here.

I’ve created a new branch of Screenlets on Launchpad for Universal Applets. Right now the branch is just the same as trunk, but I’ll be pushing a revision soon.

Here’s a screenshot of how things are looking right now:

See this for an explanation of what Desktop 2.0 is.

Here’s a quick mockup of a Growl-like notifications server for GNOME.

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

Check it out: The original Sim City’s source code has been released under the GPL. I’ll probably give it a look once GHOP is over.

Source.

I’ve been doing GHOP tasks for the Gnome Online Desktop. My most recent task was to code an email stock for Bigboard. There’s a snapshot at the bottom of the post.

I’m about to begin working on a new app soon to edit and “remix” fdo iconsets. It’ll be the Linux equivalent of CandyBar. If you’re interested in helping out, leave a comment or just ping me on irc.

In order to work on my latest task for GHOP, I need to do some coding in Python. I’m attempting to learn the language in under two days while I’m on vacation at the Dead Sea with limited internet access. So far, its gone (going?) surprisingly well.

I’m reading over Dive Into Python (a free book for programmers who are experienced with other languages) and I just got up to the following section on Python’s garbage collecting:

As a former philosophy major, it disturbs me to think that things disappear when no one is looking at them, but that’s exactly what happens in Python. In general, you can simply forget about memory management and let Python clean up after you.

The number of Linux users reading this blog has gone up lately (yippee!), so I’m pretty sure that I won’t be the only one to get a kick out of that.

I know the name sounds a bit awkward and geeky, but GHOP is a masterpiece move by Google in the endless game against Microsoft. I may just be a pawn, but that doesn’t bother me one bit.

For those of you that missed it, Google announced GHOP (Google Highly Open Participation) about two weeks ago. The contest works something like the following:

1) High school students sign up and work on tasks for open source projects. (A google account is obviously a requirement.)

2) Google pays the students up to $500 and gives all participants (as the google website says) “the all important t-shirt.”

3) GHOP ends in January and the top ten contributers win a trip to Google hq.

4) Students continue to work on open source projects and are a pain to Micro$oft.

I’m working with GNOME for the contest. So far I’ve just written an article for Gnome Journal on GConf, but hopefully I’ll get to do some coding soon.

Anyway, its time for me to get some sleep…  If you’re a high school student, go head over to the website and check it out!