I think the best solution is to fall back to Tracker and other search engines for all text searches. This is especially important if we index things like GMail emails where we can’t possibly handle all searches ourselves without downloading and indexing all emails. (Instead, we would just index each email’s title and sender. If the user performs a search, we would use GMail’s API to find results on the fly.)

On that note, I’m planning on adding Google Documents and Flickr support. This probably wont happen until later this week or the beginning of next week

I’m sitting at the Coffee Bean with a large Ice Mocha. Things that I’ve been working on include:

1. The GNOME Journal article on Zeitgeist which is due today.
2. An improved version of the mockup which I posted last night. (The new mockup is still only on paper.)
3. I discussed this bug with Ketil.
4. I’ve been thinking about how to handle fulltext searches in Zeitgeist. I’ll post about that later.
5. I’ve bought the domain name natanyellin.com last week. I’m going to start redirecting theesylum.com to natanyellin.com later this week.

Time to get back to work. One large Ice Mocha down and one salad to go.

Comments are welcome. If enough people find it interesting, I might write some code for it this week.

Zeitgeist Mockup

Rodney Dawes wrote an interesting post that I saw on Planet GNOME a few weeks back. Here’s one excerpt that I found noteworthy:

The Future is not your desktop. It is mobile devices. It is tablets. It is holographic displays and interfaces. It is flexible transparent screens. It is your television, your appliances, your home, your car. It is all the things we haven’t even scratched the surface of, for sensible user interface design. It is networked storage, with your content being accessible wherever you are, be it in your living room, kitchen, hotel 5000 miles away, or a boat in the middle of the ocean. If we want to move into the future, and not get left behind, we need to start thinking about this, not what new shiny method of accessing a 50 year old 2D desktop is best. None of them are best.

The bolded bit is particularly interesting. Cloud computing is not simply a phenomena that we’re likely to see at some point in the future. It’s already here. Today. Every time that someone uploads a photo to Flickr, they’re going out onto the cloud. Every blog post, Google Document, and even email is a little whisp in the clouds. This is where people are working, playing, living, and- most of all- sharing.

The Problem

Lets take a step back for a moment, and look at normal computer users. For most normal computer users, each computer that they use stores a different set of documents. For example, their home computer might store their photo library, and their laptop might store their presentations and Tomboy notes.

No matter how hard people try to keep things organized that way, over time it breaks down. After going on a trip with only their laptop and their small-storage camera, their laptop becomes an extension of their photo library. After working on a presentation on both their home computer and laptop, they find that they suddenly have multiple versions of the same presentation all of the place. As time goes by, it gets worse and worse. Each computer still contains unique set of documents, but more and more pieces from those sets get smeared onto all of their other computers.

Solutions appear, but as even more time goes by they only make things worse. Is that file BlahFINAL in my email more recent than BlahREALY_FINAL on my laptop? Is the other BlahFINISHED in my email even more recent? Or OMG! I’m giving a presentation in five minutes and I accidentally copied FooLAST_COPY#2 onto my laptop, but FooREALLY_SUPER_LAST_COPY#3 is at home on my desktop!

While users and their file naming conventions never fail to make me smile, the situation gets even worse when clouds enter the picture. Suddenly, Joe has found what he thinks is a solution to all of his problems. He innocently uploads every one of his files to the web and deletes them from his computer. Little does he realize it, but F-Spot, Joe’s favorite application, has become useless. Joe can still do much of what he wants with Flickr, but that becomes exceedingly painful when he tries to drag and drop his pictures into the movie that he’s making. When it comes time for his opening words at Great Grandma Beth’s 100th birthday, Joe is dismayed to find that the restaurant doesn’t have a wifi network. Even if he had known ahead of time, Joe knows that there’s no way for him to download all 1,000 of his pictures of Grandma Beth onto his laptop.

Solutions

This is the challenge that we need to rise up and answer. Syncing has to be easy and complete, and it needs to work out of the box. The second that the user turns their computer on, all of their documents need to be displayed in from of them (even if they’re not actually present on the hard drive) and they should be openable with one click. If they need to be downloaded from a server, let the app worry about that and not the user. Just as importantly, if the documents only appear after the user bends over backwards and digs through five settings dialogs, then we’ve already lost.

Implementation

With regard to synchronization, Conduit is an important start but it’s not a complete solution in and of itself. When the user opens up F-Spot, they need to see all of their photos in front of them, and not just the ones on the computer. (Microsoft’s Live Essentials seems to be an early implementation of this.) Let the user choose which- if any- of their photo albums they’d like to sync to their computer. However, all of their and albums and their friends’ albums need to be available right in front of them. If they need to open up Conduit to make this happen, we’ve lost again.

A lot of what’s mentioned above is already being implemented in a watered-down form on several other platforms. We need to embrace that and that and work with their standards when applicable. However, we can also do better. We need to- and can- provide an open solution that works everywhere. Just like users plug in cameras and the cameras work with every platform and every photo application, we can make their applications work with any online service that supports uploading photos. Our goal should be compatibility with all online services in order to create one open and intercompatible mesh of services. Which website is hosting the user’s photo should- and eventually will- become irrelevant. Instead of simply following in the footsteps of others, let’s lead with a clear vision. Now is the time to code, and not five years from now after everyone else has already done it.

If we deliver a GNOME 3.0 that fulfills the above requirements then we’ll have won a major victory. At the end of their day, people don’t use their computers because they like the eyecandy. People use their computers because they need to accomplish a job, and that job usually involves documents. This is what Dave Richard’s talk at the GNOME Hackfest was all about, and this is what’s going to create a buzz. A new panel, desktop widgets, and a composited desktop are all crucial if we want to compete with other platforms and keep our users. However, if we want to pull into the lead and actually win over new users then this is what we need to focus on. We need people to see a demo of GNOME 3.0 and say “Wow! I need that! Where can I get it?” If we create an experience that makes peoples’ lives easier- and not just shinier- to the point where they can’t remember how they even synced their files successfully beforehand (most likely they didn’t) then we’ve won. I know I wouldn’t settle for any less from the amazing people that form the GNOME Project, and I don’t intend to ask users to settle for less either.

When trying to decide on a language for applets/widgets, just about everyone will suggest their own favorite language along with reasons why that language is appropriate. However, one thing that needs to be considered is choosing nobody’s favorite language- Javascript.

Owen, I see your point but have to disagree. One of the key purposes of an applet/widget framework should be to allow new and inexperienced developers to easily write their first GNOME application with the smallest learning curve possible. Because of all the people familiar with it, Javascript is an appropriate language, but so are Python and C#.

Before I focus on the advantages of using multiple languages for applet development, I’d like to review a few of the key philosophies that drive GNOME Development:

1. Software should be easy and simple to use for new users.
2. Software shouldn’t have a large learning curve.
3. Different pieces of software for the same platform should use consistent interface elements and share design decisions. Users shouldn’t need to learn new skills in order to use new applications.

When these same philosophies are applied to development and placed in a GNOME specific context their implications are:

1. There should be GNOME frameworks that allow developers to easily write applications, even if they have no prior experience with GNOME.
2. Developers shouldn’t have to learn many new skills in order to develop their first GNOME application. When possible, they should be able to use their existing knowledge from other platforms.
3. Different pieces of software for the same platform should use the same technologies. A developer working on one GNOME application should be able to quickly jump in and contribute to a fellow GNOME developer’s application without needing to learn anything new.

The implications of 2 and 3 are problematic and contradictory. If we allow developers to jump into GNOME Development using all of their existing skills (including intimate knowledge of languages and toolkits), how can we still create a united platform that uses one set of standard and familiar GNOME technologies? More importantly, how can we create a platform with an interface that’s consistent for users?

The solution that’s been followed for the past 11 years is a simple one- Wherever giving developers extra freedom will not hurt the user experience, freedom should be given. In other words, development in multiple languages is fine, but using multiple toolkits is not fine.

This strategy has worked amazingly well. There are a wealth of applications that have been written in C, C++, Python, Mono, and a few other languages. If GNOME had begun with an ironset rule that applications may only be developed in C, we would still be in the dark ages of desktop development with all development done by a few hardcore C junkies. Heck, even if applications were allowed to be written in one “high level” language like Perl- or even the fledgling Python of 1997, for that matter- we would still never be where we are today. All of the goodness that has come out of Mono- and most likely everything that uses pygtk, as well- would have been lost in the curves and twists of a what-if history of GNOME.

The reason GNOME is so diverse and powerful today is because of it’s flexibility with regard to languages and even technologies. We’ve always embraced the new and hot, most recently with Clutter. We’ve also always allowed developers to use as many of their existing coding skills as possible. We’ve taken in developers from just about everywhere- Windows, Mac OS X, the Web, etc- and they‘re the reason that GNOME rocks so much today.

Owen, I’d love to support simplified Javascript applets/widgets, but I can’t imagine doing so without still supporting other types of widgets. There are no statistics regarding how many developers come to GNOME from other platforms, and whether most of them come from web development or desktop development. The one fact is that we do have developers from both ends of the spectrum, and our job is to get as many of them as possible involved with GNOME development. A framework that will alienate half- or even a quarter- of them is not the right answer.

One of the main topics of the hackfest is collaboration throughout the desktop. Universal Applets 0.1 should be out by the time that the hackfest begins, so it’ll be a good opportunity to get some feedback and share ideas with the rest of the community.

Anyway, thank you again to the GNOME foundation for making this possible! I’ll see some of you in Boston!

(Thanks, Kwaanens)

Forking

I know the news is already out all over the forums, so I’ll try to keep this short: There’s been some tension between myself and Whise lately, and the situation has not been fun. Instead of staying around the Screenlets project and doing development in a small hidden corner, I’ve decided to fork the project. I don’t have anything personal against Whise or the Screenlets project, and in the long run, I’m confident that a fork will be the healthiest option for both sides.

That said, Whise is responsible for bringing Screenlets all the way from the buggy version 0.0.10 to this month’s stable 0.1.2 release. I know version numbers don’t excite most people, but, whether you’re running the Universal Applets or Screenlets codebase, Whise does deserve your thanks along with RYX, so I suggest that you head over to the forums or gnome-look andlet him know that.

IRC Channel… Phoenix, Melange, Paragon, and Lizard

Until the community decides on a new name for Universal Applets, there’s a temporary irc channel at #universal-applets on freenode with a looong list of names in the channel topic. Head over there and let us know what you think, or suggest a name of your own.

New mockup icons by Przemo and Some-guy

Screenlets-Extras and New Central Repository 

Moving on to something a bit more cheerful than forks, we recently moved all of the individual Screenlets out of the core Universal Applets branch and into Kwaanens’ new-ish Screenlets-extras branch. (Based on the abandoned 3rd party screenlets project.) At the moment, there’s nothing too exciting going on over there, but I suspect that’ll change by my next post

In other long-overdue news, Some-guy recently pulled off some magic with OpenSuse’s Build Service and is now running a central repository for both Universal Applets, Screenlets, and Screenlets-extras.  Kwaanens and Gilir also helped out, yet again proving that they’re worth their weight in gold.

When Bling Starts Bouncing

Yesterday, I committed some hacky code into Melange (the main Universal Applets server) for a shiny new physics engine. Words really just don’t do it justice, so go over and get it while it’s hot.

…

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

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

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