I'm (re)forwarding this to the list because I don't think it got sent the first time.
On Thu, Feb 28, 2008 at 5:13 PM, natan yellin <[EMAIL PROTECTED]> wrote: > 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/.<http://theesylum.com/2008/02/01/desktop-20/>There > is also a forum thread on the idea > here<http://awn.planetblur.org/index.php?shard=forum&action=g_reply&ID=1496&page=1&isLive=true>.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.<https://code.launchpad.net/%7Eaantny/screenlets/universal-applets>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.<http://theesylum.com/2008/02/01/desktop-20/> > > Natan > > > On Tue, Feb 26, 2008 at 10:28 PM, John Stowers < > [EMAIL PROTECTED]> 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 > > > [email protected] > > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > _______________________________________________ > > gnome-love mailing list > > [EMAIL PROTECTED] > > http://mail.gnome.org/mailman/listinfo/gnome-love > > > >
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
