Re: gDesklets in GNOME 2.5?

[Seth Nickell <seth gnome org>]

Quoth http://gdesklets.gnomedesktop.org:
> gDesklets provides an advanced architecture for desktop applets --
> tiny displays sitting on your desktop in a symbiotic relationship of
> eye candy and usefulness.

Esp. with the current set of widgets, I think gDesklets are more
eye-candy and less usefulness. If you look at Konfabulator
[http://www.konfabulator.com] some of the widgets are reasonably useful,
so I'm not saying there is no possible use for these things... but...
being on the desktop means they have some strong limitations. Most of
the time, they aren't going to be visible.

Eye-candy is not a bad thing. Nifty things that get people excited about
software are nice. Splashy fun things increase "subjective
satisfaction". So overall, I'm in favour of gDesklets even though I
might not use them myself. So here are some issues that I think are
raised by gDesklets candy nature:

1) To be worth including in GNOME, gDesklets needs to appeal to more
than the k3wl-modder crowd. I think it can! But the barrier to use needs
to be extremely low (and its not right now). People will customize their
computer (and have fun at it too), but only if its extremely simple and
straightforward to do. 

The problem right now is "installation" and "adding new objects to the
desktop". The distinction between displays and sensors is totally bogus,
a technical detail that I assume was pulled in from *Karamba. As a user,
I shouldn't have to know the difference, I should never hear about the
difference, and I shouldn't have to separately install all the sensors a
display requires to run it. Do NOT add more dependency hell. There are
two possible installation models (and it would actually be nice to
support both):

   - Tarballs/Packages using auto* and make that install a bunch of
desklets that can be accessed from some standard menu (ala panel
objects, aka "applets"). Basically the standard Unix install model.

   - Little executable bundles you can double click on in Nautilus to
start running.

The existing gDesklets model is a confusing mish-mash of the two that
produces the worst of both worlds. You have to "install" all the sensors
needed for a display, and then you have to launch the .display file as a
little bundle in user-realm. There's no standard list of installed
desklets (that I can find). Its a usability nightmare.

I would suggest providing a little window that has a list of gDesklets
installed on the system (perhaps done as a VFS uri and viewed through
Nautilus, but you still need to add something to a menu somewhere,
perhaps somewhere in Nautilus or the panel, so its discoverable). Then
make gdesklets-extras have a real auto*/make system so we can do system
installs of standard desktops.

Secondly, I like the idea of having totally per-user desklets that you
could easily grab off the web and run (security people can now cringe).
Basically you need to have a package format with a distinct MIME type
that the gdesklet executable can understanding. Double clicking on the
package (which includes both the display AND the sensor) will start the
desklet running. No install, no muss, no fuss. I don't know if python
supports custom "class loaders" (sorry, Java language), but you'll
probably need that to load python code "out of a file" without doing a
major ugly hack like unpacking to /tmp first (don't do this, it will be
flakey and prone to problems).

I think fixing the install/running aspect of gdesklets is critical to
its inclusion in GNOME.

2) Another aspect of being primarily (imo) eye-candy, is that getting in
the "market" early is comparatively important. Eye-candy is only
marginally cool if you have seen it a hundred other places. So whereas
for a more functionally oriented feature (depending on how important it
was, of course) I might suggest waiting another GNOME iteration for
inclusion to get everything perfect, I think with gDesklets its worth
striking while the metal is hot even if we don't get a perfect version
into GNOME.

3) Esp. if we don't put a "perfect version" in GNOME, but even if we did
have a fully polished first pass, its important that gDesklets be low
impact. That means it doesn't introduce confusing terminology (FYI the
word "applets" has been retired from being user visible). gDesklets is
pretty good in this area now in the way that it integrates with
Nautilus.

-Seth

> 
On Tue, 2003-10-21 at 02:12, Martin Grimme wrote:
> Hi,
> 
> in #gdesklets, we have discussed about inclusion of gDesklets in
> GNOME 2.5. What do you think about it?
> 
> We would depend on James' PyGTK and gnome-python bindings.
> 
> 
> Bye, Martin Grimme
> 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>