[kubuntu-devel] Muon Discover

[Harald Sitter]

On Wed, Jan 15, 2014 at 3:54 PM, Achim Bohnet <allee at kubuntu.org> wrote:
> On Mittwoch 08 Jan 2014 16:28:07 Aleix Pol wrote:
>> On Wed, Jan 8, 2014 at 4:20 PM, Harald Sitter
> <apachelogger at ubuntu.com>wrote:
>> > On Wed, Jan 8, 2014 at 2:42 PM, Aleix Pol <aleixpol at kde.org> wrote:
>> > > On Wed, Jan 8, 2014 at 1:03 PM, Jonathan Riddell <jr at jriddell.org>
>> >
>> > wrote:
>> > >> On Tue, Jan 07, 2014 at 02:25:27PM -0800, Scarlett Clark wrote:
>> > >> >    Is this the default package manager? Or Muon?
>> > >> >
>> > >> >    I need all ways to bring this up eg.. command line. I have so far
>> >
>> > in
>> >
>> > >> > a
>> > >> >
>> > >> >    search from KickOff and KickOff->Programs->Muon Discover
>> > >>
>> > >> We have both Muon and Muon Discover installed by default.  Arguably
>> > >> this
>> > >> is application duplication and very un-ubuntu.
>> > >>
>> > >> Does anyone have an opinion of whether Muon Discover is mature enough
>> > >> to
>> > >> stand along and for Muon to be removed from the images?
>> > >>
>> > >> You can access it by KickOff -> Computer -> Software Centre too which
>> >
>> > I'd
>> >
>> > >> expect to be the primary method.
>> > >>
>> > >> Jonathan
>> > >>
>> > >> --
>> > >> kubuntu-devel mailing list
>> > >> kubuntu-devel at lists.ubuntu.com
>> > >> Modify settings or unsubscribe at:
>> > >> https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>> > >
>> > > I would say that the decision is not really about maturity but about
>> > > user
>> > > target. I don't think an end-user should understand all the semantics
>> >
>> > that
>> >
>> > > Muon Package Manager exposes. If a user has the knowledge to use Muon PM
>> >
>> > he
>> >
>> > > has the knowledge to install it from Discover or even apt-get.
>> >
>> > Indeed. The argument never was that software center or discover
>> > weren't mature enough, but that they do not deal in packages. They
>> > deal in applications (read: in things that have a desktop file). So if
>> > you want or need to install a package (say 'bzip2') you won't be able
>> > to do that with discover because of the way it is designed.
>> >
>> > Personally I always found this argument silly because it implies that
>> > a user knows the difference between Muon and Muon Discover and will
>> > choose the correct tool for the job at hand <- so very very very
>> > unlikely...
>> >
>> > Really there are three groups of people we have to consider:
>> > a) the user who only wants to installation an application and will not
>> > ever want to install a package (by himself, support cases excluded
>> > becasue those usually will offer concrete apt-get commands anyway)
>> > b) the user who perhaps could be called a sysadmin and wants to
>> > explicitly manage packages, but likes to do it in a GUI
>> > c) the user who likes direct control but feels that a GUI slows him down
>> >
>> > And here is the thing.
>> > A user of group a) won't be able to graps the concept of either b) or
>> > c) and have a very hard time trying to manage 'apps'.
>> > A user of group b) will be able to deal with the usage paradigm of a)
>> > but might not be able to do what c) does.
>> > A user of group c) will be able to do manage 'apps' and 'packages' given a
>> > gui.
>> >
>> > Looking at the presented use cases there is no reason why muon (the
>> > package manager) needs to be part of the default install. You could
>> > technically even remove apt-get itself. Because b) will be able to use
>> > muon-discover to install muon and c) will be able to use muon-discover
>> > to install muon to install apt-get. Of course latter is not very
>> > convenient so one can make an argument for keeping apt-get regardless
>> > (plus I doubt you could remove it anyway ;))
>> >
>> > Long story short: if someone wants a gui package manger, they can
>> > manually install muon via discover or apt-get, absolutely no reason
>> > why we'd need it in the default install.
>> >
>> > HS
>> >
>> > --
>> > kubuntu-devel mailing list
>> > kubuntu-devel at lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> > https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>>
>> FWIW, bzip should probably be installable from Discover, since it's an
>> end-user application.
>> What the user won't be able to find in discover is libbz2. Arguably, -dev
>> packages should be available in discover as well.
>
> FWIW I would disagree here.  People using the command line with bzip or
> compiler&co, using -dev pkgs, can be expected to use muon or apt-get.
> (let's call muon the export-mode of muon-discover ;-) Start muon and exit
> muon-discover when the tobe-done 'Export Mode' button is pressed ;-) )
>
> On the other hand: try to search for android or kdeconnect or 'network
> management' in muon-discover: it finds nothing, but that's wrong IMHO. The
> target group of muon-discover doesn't know if it's a plasma/kded plugin or a
> application (aka binary in /usr/...bin with desktop file).
>
> IMHO as it is, muon-discover misses an important group of 'looks-like-an-
> application' that's important for newbies, so there is still a need for muon.

I absolutely agree.
This is however a two folded issue actually.

There is those things that expand a thing, but on their own they do
not make sense/may not be an application. This includes for example
amarok's moodbar plugin, if you navigate to amarok and select the
addons tab you'll get it listed there. If you however simply search
for moodbar nothing shows up. It is not an application, but it is an
addon feature that a person should be able to search for, however the
result ought not be an own page, but instead take you to Amarok's
addon page.

And then there is the things you mentioned. Things that on a technical
level are addons/plugins to the actual application but ought to be
searchable on their own.
This includes just about everything that has a desktop file in
usr/share/kde4/services (minus a whole bunch of other stuff ;))...
incomplete list:
plasma applets
plasma wallpapers (?)
plasma runners
plasma themes
KCMs
kipi-plugins

To express those groups more clearly: there are addons that expand
*one* application and there are addons that expand *multiple*
applications. Plasma* can be used in either
plasma-desktop/plasma-netbook/plasma-active. KCMs can be used in
systemsettings/kinfocenter/applications. And so on.

The former of the two has no visual identity, they provide abilities
to the application. Latter has a visual identity and supply additional
features within an application.

Now why would one search result lead to the application's addon and
the other not? For one, because one group can have multiple
applications they add on to, so that would look silly; and for another
KCMs for example make sense on their own. As an application. The
example I hit the other day was the colord kcm. If you search for
color correction in discover you get nooothing. Now people might argue
that it should list colord, and I agree with that. colord is the means
for the technical part of color correction. The KCM is the actual user
facing frontend for it.

Since I started rambling somewhere half way through the mail I am
going to stop now :P

HS