<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 13, 2014 at 3:50 PM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Aleix, can you please explain to us why Mion Discover and Apper are two<br>
different things in principle?<br>
<br>
Seems the Apper guys disagree.<br>
<br>
Cheers,<br>
  Albert<br>
<br>
El Dilluns, 6 d'octubre de 2014, a les 22:46:49, Matthias Klumpp va escriure:<br>
<div class="HOEnZb"><div class="h5">> 2014-10-06 19:57 GMT+02:00 Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</a>>:<br>
> > El Dilluns, 6 d'octubre de 2014, a les 01:30:47, Aleix Pol va escriure:<br>
> >> [...]<br>
> >> I don't expect to compete with Apper. Muon Discover is a software center<br>
> >> and that's the main solution I'm pushing here, as I explained in Plasma.<br>
> >> Apper is a package manager. That is, a way where we can display to our<br>
> >> end-users what software there's available and also lets us a couple of<br>
> >> tricks to get biased.<br>
><br>
> I (as Apper contributor) would disagree with that - Daniel renamed<br>
> KPackageKit to Apper years ago to stress that Apper is not about<br>
> packages, but especially about applications. Unlike Muon or GNOME<br>
> Software, the goal for Apper is to manage packages and apps in one UI<br>
> though - and of course, Apper provides the session interface for<br>
> PackageKit, which Muon does not (yet?).<br>
> Does Muon work well with PackageKit on !Debian-based distros? I had<br>
> lots of trouble with porting the Ubuntu Software Center to PK, since<br>
> PK uses a completely different paradigm and API, compared to the<br>
> Aptdaemon interface the USC used, so it would have required a complete<br>
> rewrite.<br>
> Last time I looked at QApt, it looked slightly more similar to Aptd<br>
> compared to the PK API.<br>
> (I'll soon test Muon on Fedora by myself, but more from an "what can<br>
> be improved in AppStream?" PoV)<br>
><br>
> >> I think this is very important, because it opens an opportunity to offer<br>
> >> the end-user the full KDE experience we've been talking about. So far,<br>
> >> the<br>
> >> way everyone had to expose software was by creating a (usually spin-off)<br>
> >> distribution where there was tons of software pre-installed. By providing<br>
> >> a<br>
> >> software center we open channels to communicate with the user where he<br>
> >> can<br>
> >> leverage on previous' users experience, as well as our own.<br>
> ><br>
> > I'm not sure I understand the difference between a "Software Center" and a<br>
> > "Package Manager", can you elaborate what is the difference?<br>
><br>
> Software Center almost always means that it shows GUI apps instead of<br>
> packages, where "app" is more tightly defined as "stuff which ship a<br>
> .desktop file in share/applictions with Type=application".<br>
> Package Managers display all kinds of packages on the system,<br>
> including debug symbol packages and e.g. header packages.<br>
> The Software Centers are generally thought to be more end-user<br>
> friendly, while package managers have a technically advanced user as<br>
> target audience.<br>
> Cheers,<br>
>     Matthias<br>
<br>
</div></div></blockquote></div><br></div><div class="gmail_extra">There's 2 main differences:</div><div class="gmail_extra">1. Muon Discover has historically used OS metadata to define what are applications an what's relevant to the users (AKA end-user applications). Although they claim it will be done eventually on Apper as well. In any case Muon Discover doesn't aim to manage packages, it aims to provide a library of resources for the user to enhance his KDE/Plasma experience.</div><div class="gmail_extra">2. Muon has different backends, so we're not solely relying on PackageKit which means it can act as a frontend to different technologies other than packagekit, currently bodega, KNS/OCS and Apt (the last one for historic and practical reasons).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Aleix</div></div>