<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 15, 2014 at 4:33 PM, Harald Sitter <<a href="mailto:apachelogger@ubuntu.com" target="_blank">apachelogger@ubuntu.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Wed, Jan 15, 2014 at 3:54 PM, Achim Bohnet <<a href="mailto:allee@kubuntu.org">allee@kubuntu.org</a>> wrote: > On Mittwoch 08 Jan 2014 16:28:07 Aleix Pol wrote: >> On Wed, Jan 8, 2014 at 4:20 PM, Harald Sitter > <<a href="mailto:apachelogger@ubuntu.com">apachelogger@ubuntu.com</a>>wrote: >> > On Wed, Jan 8, 2014 at 2:42 PM, Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote: >> > > On Wed, Jan 8, 2014 at 1:03 PM, Jonathan Riddell <<a href="mailto:jr@jriddell.org">jr@jriddell.org</a>> >> > >> > 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 >> > >> <a href="mailto:kubuntu-devel@lists.ubuntu.com">kubuntu-devel@lists.ubuntu.com</a> >> > >> Modify settings or unsubscribe at: >> > >> <a href="https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel</a> >> > > >> > > 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 >> > <a href="mailto:kubuntu-devel@lists.ubuntu.com">kubuntu-devel@lists.ubuntu.com</a> >> > Modify settings or unsubscribe at: >> > <a href="https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel</a> >> >> 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. </div></div>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 <div class=""><div class="h5"> HS -- kubuntu-devel mailing list <a href="mailto:kubuntu-devel@lists.ubuntu.com">kubuntu-devel@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel</a> </div></div></blockquote></div> </div><div class="gmail_extra">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).</div> <div class="gmail_extra"> </div><div class="gmail_extra">Also we could use addons names as a search parameter, if you think it's appropriate.</div><div class="gmail_extra"> </div><div class="gmail_extra">Aleix</div> </div>