Re: gDesklets in GNOME 2.5?

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2003-10-22 at 03:26, Seth Nickell wrote:
> 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.
> 
I might also add:

4) add the possibility to move the desklets around. For me, starting 4
or 5 desklets make 2 or 3 of them be below the others, so not at sight.

5) It seems to me a gDesklets script (and so, a python interpreter) is
started for each display. I'm not sure if I'm wrong or not, but if not,
then, would it be possible to just run one interpreter for all the
displays?

cheers