<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 24, 2014 at 10:57 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">El Dijous, 24 d'abril de 2014, a les 12:02:38, Aleix Pol va escriure:<br>
<div><div class="h5">> On Wed, Apr 23, 2014 at 11:49 PM, Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</a>> wrote:<br>
> > El Dimarts, 22 d'abril de 2014, a les 11:31:02, Mario Fux va escriure:<br>
> > > Proposal:<br>
> > > Reduce the amount of KDE Core Apps according to a definition and release<br>
> ><br>
> > the<br>
> ><br>
> > > other apps in independent groups or suites like e.g. KDE Edu, KDE Games,<br>
> > > KDE PIM, Amarok or the Calligra Suite.<br>
> > ><br>
> > > Details:<br>
> > > We could decide on a group of KDE Core Apps (for the Desktop) based on a<br>
> > > definition like this:<br>
> > > - Allows you to manage your files and documents (e.g. => Dolphin, Ark,<br>
> ><br>
> > K3b?)<br>
> ><br>
> > > - Allows you to view documents and pictures (e.g. => Okular and<br>
> ><br>
> > Gwenview) -<br>
> ><br>
> > > Allows you to watch movies and listen to music (e.g. => Dragon and Juk)<br>
> > > -<br>
> > > Allows you to administrate and manage your system (e.g. =><br>
> > > print-manager,<br>
> > > ksane, systemsettings)<br>
> > > - Allows you to do this in an accessible way*: (e.g. => Simon, Jovie and<br>
> ><br>
> > Co)<br>
> ><br>
> > > - Allows you to write some notes and find them again (e.g. =><br>
> ><br>
> > Kate/Kwrite)<br>
> ><br>
> > > * A really nice promo argument. And as we as a community are inclusive<br>
> ><br>
> > this<br>
> ><br>
> > > is the only thing the makes sense. Make our (core) apps accessible by<br>
> > > default.<br>
> > ><br>
> > > About the current modules [1] we have and released it's a very<br>
> > > unbalanced<br>
> > > thing. Just compare KDEAdmin or KDEToys with KDEEdu or KDEPIM.<br>
> ><br>
> > There's no such think as "KDEAdmin" from a releasing point of view, we<br>
> > just<br>
> > release tarballs of some apps that happen to be in that "virtual" module<br>
> > in<br>
> > <a href="http://projects.kde.org" target="_blank">projects.kde.org</a>, but besides that, it's just single apps.<br>
> ><br>
> > > So I think a<br>
> > > reduction and rearrangement is the best thing. About the release of<br>
> > > these<br>
> > > Core Apps, Edu Suite, PIM Collection and Co see one of the next<br>
> ><br>
> > proposals.<br>
> ><br>
> > > These suites or groups could then decide on their own if they want<br>
> ><br>
> > include<br>
> ><br>
> > > new apps like e.g. KBibTeX or Rkward in KDEEdu or Trojita in KDEPIM.<br>
> ><br>
> > Which is what they already do, no?<br>
> ><br>
> > > But I think these core apps (or call it differently) should be very well<br>
> > > maintained, probably team maintained, have good unit and regression<br>
> > > tests<br>
> > > and good bug triage and bug handling. Reduced to the core and let it<br>
> ><br>
> > shine.<br>
> ><br>
> > I don't think "team maintainance" makes much sense beyond basic bugs, I<br>
> > don't<br>
> > think I can fix a non trivial bug in Ark (fwiw i've tried [though not very<br>
> > hard] :D)<br>
> ><br>
> > > Next steps:<br>
> > > - Work on the definition for the KDE Core Apps (for Desktop).<br>
> > > - Decide on the applications that fulfill this definition.<br>
> > > - Define the minimum requirements these core apps need to fulfill to be<br>
> > > released.<br>
> > > - See what other suites or groups are logical and possible.<br>
> > > - Discuss and agree an development and review work for these core apps.<br>
> > > - Decide on a name for the "core apps".<br>
> ><br>
> > Sincerely I don't see the point of this proposal, we're already releasing<br>
> > those core apps, and yes, they need better unit tests, and they need more<br>
> > manpower, but I don't see how creating an this "Core Apps vs Suites" is<br>
> > going<br>
> > to help with these issues.<br>
> ><br>
> > Moreover I'm sure someone will be pissed off because his app is not<br>
> > considered<br>
> > to be core.<br>
><br>
> I think that what Mario meant here, is that we need to provide hints to the<br>
> distributions regarding what applications should be shipped with a Plasma<br>
> Desktop installation.<br>
><br>
> What we currently call Plasma Desktop is not a full desktop suite because<br>
> it lacks many applications that, arguably, are not related to Plasma but<br>
> Plasma depends on, again like Dolphin.<br>
<br>
</div></div>Why does Plasma depend on Dolphin? I can use any other file manager just as<br>
well, no?<br>
<br>
Cheers,<br>
Albert<br>
<div class="im HOEnZb"><br>
><br>
> > Cheers,<br>
> ><br>
> > Albert<br>
> ><br>
> > > Now please tell me your opinion in a short, constructive and polite way.<br>
> > > Details can be discussed in Randa and/or at Akademy. So let's<br>
> ><br>
> > concentrate on<br>
> ><br>
> > > the bigger ideas.<br>
> > ><br>
> > > Thanks and best regards<br>
> > > Mario<br>
><br>
> Aleix<br></div></blockquote><div><br></div><div>That is definitely a good question, I would like to hear the thoughts from Plasma and Dolphin maintainers.</div><div>I know it's not from a technical point of view, but from a mission/vision of the different projects point of view.</div>
<div><br></div><div>I think the Plasma project will probably want to have a greater control on what experience the user is receiving further than the shell itself. But maybe not.</div><div><br></div><div>Aleix</div></div>
</div></div>