At the GNOME Summit, Owen suggested the following:
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:
- Software should be easy and simple to use for new users.
- Software shouldn’t have a large learning curve.
- 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:
- There should be GNOME frameworks that allow developers to easily write applications, even if they have no prior experience with GNOME.
- 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.
- 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.
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!
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:
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.
NOTE: Some of this post is no longer relevant. Please use Universal Applet’s internal documentation.
At the moment, there’s very little documentation for developers describing the Universal Applets architecture. I’m hoping to roll out a stable release within the next week or two, and I should have the time to write up some docs after that.
In the meantime, this post should provide adequate installation instructions and a quick developer overview for those of you who have been asking. If you haven’t already done so, please read this article first.
Installing Universal Applets and Getting the Server to Run
1. Grab a copy of the branch off of bzr with the following command:
bzr co http://bazaar.launchpad.net/~aantny/screenlets/universal-applets
2. Install Universal Applets with the following:
sudo make install
3. Start the server with the following: chmod u+x src/share/examples/server.py src/share/examples/server.py
4. Start any screenlet or applet. There’s a non-screenlet-based test applet in src/share/examples/test-applet.py
The Universal Applets architecture is heavily built on XEmbed and DBUS. Any application can create an applet using a GtkPlug (or the equivalent widget in any X toolkit) and any application can display an applet using a GtkSocket. All communication between the applet (the process containing the GtkPlug) and the server (the process containing the GtkSocket) is done over DBUS.
There can be multiple servers running at any time. Each server can display applets in different places on the screen (e.g. in a sidebar or in a panel). In other words, the same applet can be displayed in different applications without requiring any modifications to the original applet. Accordingly, an applet server can easily display any applet without knowing or caring what language the applet was written in. Again, applets do not run in the same process as the applet server.
The Ten Second Component Overview
At this point, the only server is the aptly named server.py application that’s contained in my branch. server.py displays applets in toplevel windows. It runs a DBUS service and holds an array of GtkWindows and GtkSockets. (The toplevel windows are commonly referred to as “applet containers.”) Any application which would like to function as an applet server can do so by implementing similar DBUS code. Yes, it’s really that easy.
The AppletWrapper class implements all of the basic code necessary for an applet. It can be used to make any part of an app’s gui function as an applet. It handles the DBUS communication with the applet server and automagically takes care of all the nitty gritty XEmbed details. AppletWrapper is currently written in Python but I’m planning on reimplementing it in C.
In the layman’s terms: By using AppletWrapper any part of your app can gain toggleable applet status with about three extra lines of code. Nifty.
The Screenlets base class contains code for applets that need to implement custom drawing. It’s not absolutely necessary, but if you’re planning on writing a python applet you should probably subclass the Screenlets class. It supports theming and editable options (options that can be edited with a GUI) and will make your life simpler. Screenlets uses AppletWrapper for the magical DBUS and XEmbed ‘stuff’.
The session class is used by Screenlets to handle multiple instances. If you’re writing your own applet using AppletWrapper (or if you’re implementing your own equivalent to AppletWrapper) you can ignore it.
Other Important Notes:
There’s still some ugly and outdated legacy code from Screenlets in several places. In particular, I wouldn’t even try to understand the screenlets-manager.py file. It’s a coding nightmare and will be rewritten by the Universal Applet’s 0.1 release.
The server.py application (the name will change to something more original with the release) is the only currently the only applet server. There are plans to add support to Awn in the coming weeks.
There are still several features missing in Universal Applets that are present in the Screenlets. I’ve tried to focus on improving the stability and performance instead of adding new features. If someone wants to test the speed of my branch against screenlets’ trunk, I’d be interested in the results.