[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-debian-devel
Subject:    Re: [devel] Another idea
From:       Dominique Devriese <dominique.devriese () student ! kuleuven ! ac ! be>
Date:       2004-01-12 19:08:29
Message-ID: 871xq5ugr6.fsf () student ! kuleuven ! ac ! be
[Download RAW message or body]

Peter Rockai writes:

> [snip the proposal]
>> Anyway, what do you think of this ?
> Well, i think this sucks. 

Exactly what do you think sucks ?

> There is the planned IconView aka EasyView... This is the place
> where to play with these things.

So you agree that it should be added ?  I am still a bit wondering
whether it is a good thing to put the package manager you would like (
basically, a synaptic or kpackage clone with some more features ) with
what I would like it to become ( a clone of an app like Lindows'
warehouse, or Red Hat's package installer ) in one and the same
application.

> Also, i plan to abstract over pkgDepCache from apt-pkg, so we can
> add short-desc there, on startup. This will increase the footprint,
> but d'oh.  

That may be a good idea, yes.

> The hierarchy you talk about in another e-mail: there are
> the debtags. You just write a grouper for them, using external
> hierarchy description, like this: 
> Section: office/kde-office
> GenericName: KDE Office Suite
> Name: KOffice 
> Required-Tags: Desktop::Office KDE::Koffice

> Section: office/openoffice
> GenericName: The OpenOffice.org Office Suite
> Name: OpenOffice.org
> Required-Tags: Desktop::Office::OpenOffice.org
> ...  

> The packages not satisfying criteria for any section get discarded,
> ie hidden. Voila, easy and nice *and* distribution friendly (they
> only override one file). And uses mostly in-place technology, no
> wheel-reinventing.  

This is interesting.  I have looked at debtags several times, and not
found any good documentation about it.  I have downloaded the source
code, and I haven't found a library that could be used.  Can you
perhaps point me to some better sources of information about this ?

> The problem here is with getting rid of individual packages. But if
> you implement PkgDetails equivalent for PkgSubTrees, then you can
> make this feasible -- just make your PkgView disregard individual
> packages but instead let the user select the groups. Etc, etc. 

I don't understand what you are talking about here.

> Just please don't screw with power-user's interface this way. We
> decided to have the advanced view for those who need it. 

First of all, personally, I don't really care about a power-user's
interface, because of the following reasons:
1. There are already enough tools for power user's.  Dselect, apt-get,
   aptitude, and even synaptic and kpackage for those power users who
   like GUIs.  I am yet to see the first user-oriented software
   manager that gets even close to other distribution's offers.
2. For some reason, you take it as a given fact that power user's like
   an ugly tree-based look like KPackage.  I'm not sure whether this
   is true, and whether a lot of user's wouldn't be perfectly happy
   with a simpler interface.  It is always possible to add an
   "advanced" menu item, containing some functions like "install a
   package by internal package name".
3. As I see it, what an enterprise admin needs are some functions to
   define configuration sets, which he can push to a big set of client
   machine, this does not imply any sort of interface.  I'm sure this
   can be provided within an easy, user-oriented interface, and I
   would like to try it out.

These are of course all my opinions, you don't have to agree with
them.

We did indeed agree to have an advanced view for those who need it,
but I'm not sure anymore this is indeed a terribly good idea.  Maybe
we should try to split up kapture into two separate programs that both
use some of the libcapture library ?  

"My" front-end will also need the code to install, upgrade, and remove
packages, so there is quite some common ground there imho.

> Within enterprise, everyone who would want to touch package manager
> is going to (sooner or later) need the advanced interface anyway.

> Also about the "Kapture UI" email: with this code you essentially
> nuked all the ways to make this kmdi-powered and to use forward/back
> buttons. Ie, i'd say no, no good. 

As I said in that email, it was meant more as an idea to discuss, not
code that was ready to move into CVS.  The patch wasn't that big
anyway, and I don't see how it nuked your kmdi approach.

cheers
domi
_______________________________________________
kde-debian-devel mailing list
kde-debian-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-debian-devel
[prev in list] [next in list] [prev in thread] [next in thread]