Re: [gnome-love] GSOC 2008 advice

["natan yellin" <aantny gmail com>]

The whole applets/screenlets/plugins/online-desktop-stocks/mini-programs infrastructure is currently a mess. Instead of adding new features, developers are rewriting
applets/screenlets/other so that they can be displayed in another place on
the screen with the exact same content.
For example, there's a gmail gnome-panel applet, awn applet, screenlet, online desktop stock, and deskbar search handler that essentially all do the same thing.

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. (Neil, Awn's lead developer, has already stated his approval of the idea and is interested in supporting it when it matures. Kiba dock's developer has also showed interest, but I haven't had the time to have a full conversation with him yet.)

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

On Tue, Feb 26, 2008 at 10:28 PM, John Stowers <john stowers lists gmail com> wrote:

On Tue, 2008-02-26 at 12:10 -0600, Benjamin Gramlich wrote:
> Greetings all,
>
> I am interested in applying to work on a project for Gnome during the
> summer of code 2008, and I have a few ideas.
>
> Idea #1) Re-implement the panel-applet library/interface to depend on
> DBUS.

I guess you are familiar with the hacking that desrt did on the panel
last year [1][2]. AIUI one consequence of this was a shift to DBus. It
would be cool if someone was to pick this up and run with it.

Here are some of my random notes about what a shiny new panel would look
like
* Some way to mix in and out of process applets, a C API that would
support this, might be a sensible for the default set of applets, saving
memory and startup time.
* See what can be taken/adapted from AWN[3]/Cairo-dock[4]. Should there
be another basic panel primitive that is more like a dock? Is there a
need for the two to be separated, or is AWN just what the panel would
look like if it was implemented again today, using current technologies?
* Pick a widget technology. Something that would allow people to write
widgets with less hacking mojo. We have seen other people facilitate
this by making widgets closer to the web. Jackfield[5] development seems
to have stopped, but webkit is the rage these days, and looking at , it
seems capable of making all our dreams come true[6].
* Also check out the amazing bling in aastro-desktop[7], using Clutter
and JSON.
* Is the management of desktop widgets by the panel a good idea? Should
the panel be like the vista sidebar, applets can be in it, or hovering
on the desktop.

Regards

John

[1] http://git.desrt.ca/gitweb/?p=panel;a=summary
[2] http://blogs.gnome.org/desrt/2007/02/18/panel-composite-bin/
[3] http://awn-project.org/
[4]
http://thedailyubuntu.blogspot.com/2008/02/cairo-dock-animated-launch-bar-for_03.html

[5] http://www.kryogenix.org/code/jackfield/
[6]
http://www.atoker.com/blog/2008/02/26/developing-hybrid-web-gtk-applications/
[7] http://svn.o-hand.com/view/clutter/trunk/toys/astro-desktop/

>
> Idea #2) Migrate the panel to GIO/GVFS and DBUS.
>
> Idea #3) Develop a tutorial for GIO/GVFS.
>
> Idea #4) Create more compositing effects for metacity and develop a gui
> configuration tool for the effects.
>
> Are these ideas any good? Are they in line with what Gnome needs at the
> moment? Would they duplicate the work of a Gnome developer? Lastly, (and
> probably most importantly) would there be a mentor available to help
> with any of these projects?
>
> I'm really excited about the possibility of doing SOC this year, and I
> would like to get studying and learning as soon as possible. Any
> feedback or advice is most appreciated.
>
> Thank you,
>
> Benjamin
>
>
> _______________________________________________

> desktop-devel-list mailing list

> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

_______________________________________________
gnome-love mailing list
gnome-love gnome org
http://mail.gnome.org/mailman/listinfo/gnome-love