Desktop issues discussion proposal

[Razvan Corneliu C.R. "d3vi1" VILT]

On Thu, 2004-04-22 at 13:33 -0400, Havoc Pennington wrote:

> On Thu, 2004-04-22 at 09:43, Gene C. wrote:
> > 
> > Should kdenetwork be split so kmail is not included but instead moved to 
> > Extras?  This has to be a management nightmare.
> > 
> 
> For end-user apps (i.e. those in the menus), it will almost always be
> desirable to maintain a 1 .desktop file to 1 RPM mapping. And in fact we
> should be syncing the name of the package displayed in the package tool
> (including translations) with the .desktop file name. Or even making
> package management happen in terms of .desktop files. From a single-user
> standpoint, "menu editing" (at least in terms of add/remove items) and
> "package management" really have no reason to be different.
> 
> The ideal user experience might be to effectively refcount each RPM by
> the number of users that have it in their menus, and when nobody has the
> item in their menus the package gets removed. And similarly you'd
> install a package by choosing what items to add to your menus. Unclear
> if there's a sane way to implement this, but this is a nice way for a
> desktop user to see things.
> 
> Obviously it only works for desktop-app type of packages. You need
> another approach to deal with servers, though you could perhaps imagine
> a similar approach (when you enable the service, it automatically gets
> the required packages and punches the firewall to make the service go).
> 
> Also, even if package add/remove were combined with menu editing, you
> still need an "update" or "get patches" kind of UI... though judging by
> the number of Windows viruses out there, perhaps the default should be
> to run this thing automatically every night unless the user opts out ;-)
> 
> Anyway, we really should think about the issue much more broadly and not
> assume that the task at hand is "write a single tool that does package
> management." How can we get it smoothly integrated into the desktop?
> Maybe there are multiple tools for different tasks or kinds of user.
> 
> There are related problems too, such as making it really easy for third
> parties to provide a set of RPMs with comps file on a CD or in an http
> directory, and handle that really nicely with an install wizard.
> 
> Just some brainstorm ideas. Let's start with what the user should see
> though, and then figure out how to implement our closest approximation.
> 
> Havoc

That sounds soo nice for the end user. But what about me? I've been
using linux since 1996. I was 12 by then and I'm not sure I'm ready for
such radical changes. I just love being in control of things. First I
WANT to be able to select the rpm packages one-by-one, whether it's in
anaconda or system-config-packages, we should not forget those users
which want to be in control. It's nice to have an easier way, but lets
not give up the power of rpm.