Re: gDesklets in GNOME 2.5?

[Rob Adams <readams readams net>]

You can move them around.  middle mouse drag (same way as moving panel
applets)

On Thu, 2003-10-23 at 02:26, Rodrigo Moya wrote:
> 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
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list