Applet Languages

At the GNOME Summit, Owen suggested the following:

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.


Going to Boston

I’ve been invited to the GNOME User Experience Hackfest in Boston, and I’m going! (Thanks to the GNOME foundation who offered to cover the expenses.)

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!


UA News Roundup

There’s a lot going on in the Universal Applets community at the moment, so I’ve decided to start writing semi-weekly wrap-up posts summarizing everything that’s happened. Here goes news roundup #1:

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 and let 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.

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.


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/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.


Pages ... 1 2