On Wed, Jan 15, 2014 at 4:33 PM, Harald Sitter <[email protected]>wrote:
> On Wed, Jan 15, 2014 at 3:54 PM, Achim Bohnet <[email protected]> wrote: > > On Mittwoch 08 Jan 2014 16:28:07 Aleix Pol wrote: > >> On Wed, Jan 8, 2014 at 4:20 PM, Harald Sitter > > <[email protected]>wrote: > >> > On Wed, Jan 8, 2014 at 2:42 PM, Aleix Pol <[email protected]> wrote: > >> > > On Wed, Jan 8, 2014 at 1:03 PM, Jonathan Riddell <[email protected]> > >> > > >> > 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 > >> > >> [email protected] > >> > >> 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 > >> > [email protected] > >> > 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 > [email protected] > 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
-- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
