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

List:       klik-devel
Subject:    Re: [klik-devel] Further improving klik idea (KDE Integration
From:       Filippo Pappalardo <filippo () email ! it>
Date:       2006-04-27 11:22:37
Message-ID: 1146136957.8352.21.camel () localhost ! localdomain
[Download RAW message or body]


> The idea is simple:
> When you right-click on a klik package, there should a new menu option
> appear "Add to KDE Menu" - so it will add the klik to the KDE KMenu
> (Start Button)

As stated in the wiki: klik is not an installer, the menu entries will
be automatically added/removed by watching a given directory (such as
~/Applications) for the presence of .cmg (soon to be .app?) files

> And we might also provide a simple uninstaller of such thing - like an
> Autopackage did.
> That is -- a simple KDE program, that remove those KDE menu (start
> button) entries (and *optionally* deletes the klik packages from the
> Hard Disk)

Klik in not an uninstaller, either :) don't want a package? simply
delete it, the menu-entries generator discussed above should take care
of the menu part.

> That way we will have few more features from the RPM.
> (that is: KDE Desktop Integration, pseudo-installation,
> pseudo-uninstallation and real un-installatiuon)

Again, i don't want to install/uninstall things. The whole concept of
installers is flawed: if want to use an app i download and click on it,
then i can save it if i want, or i can move it to another PC, or i can
simply remove it. We're not taling about core libraries here, they need
installation to be available for use by other software, we're talking
about apps we should be able to simply *use*

Don't baby sit software, just use it! :)

> RPM also allows people to query whole packages, single files, search
> the database, and verify the package. Also it allows to managing
> source code & many architectures at once. 

> From that whole salad - it could be good to implement klik query of
> packages. (try to use "rpm -qip something.rpm" to understand what I
> mean).

> I really believe that klik is better concept - and will be stronger
> than RPM - especially on the desktop. And copying a some RPM features
> will make klik only stronger.
> 

I don't care about source code: sure it's a great thing to have it, but
again, we're talking about *using* software. Also, klik2 will probably
have some of the feature you described - like querying packages
(firefox.app --app-list-files or something) - on a package basis, that
is: NO databases to suck the info from, so more reliability over what's
really on my filesystem.

RPM is a package manager, klik is a way to distribute binaries, with
almost no kind of "central" managing involved by the users' side. I
guess that's the real strength of klik. Klik can even (and does
actually) cohexist with RPM or DPKG in that it limits itself in
excelling in one thing: letting the user *use* software. Let's leave
system libraries to over engineered database driven RPM or DPKG, and
let's use klik to use apps.

Hope i got the whole concept right, it's all written in the wiki anyway

--
Filippo

 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Conto Arancio: 3.50% per tutto il 2006! Scopri come
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5043&d=27-4
_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel
[prev in list] [next in list] [prev in thread] [next in thread]