[kubuntu-devel] Muon Discover

Thu Jan 16 01:43:14 UTC 2014

On Wed, Jan 15, 2014 at 4:33 PM, Harald Sitter <apachelogger at ubuntu.com>wrote:

> 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
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>

Actually, improving the visibility of Addons is indeed very interesting. I
would suggest you to take a look at the "reviewsOnOverview" branch in muon,
where you'll find a redesigned version of the application page. Maybe we
can push it for 2.2, last time I played with it was ready but I didn't
merge it for lack of feedback (and being busy with different issues, of
course).

Also we could use addons names as a search parameter, if you think it's
appropriate.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20140116/bc06db77/attachment-0001.html>