RFC: Moving RSIBreak to KDEUtils?
Aaron J. Seigo
aseigo at kde.org
Fri Jul 24 02:57:42 BST 2009
On Thursday 23 July 2009, Friedrich W. H. Kossebau wrote:
> Jeudi, le 23 juillet 2009, à 22:53, Aaron J. Seigo a écrit:
> > On Thursday 23 July 2009, Friedrich W. H. Kossebau wrote:
> > > Hi Aaron,
> > >
> > > Jeudi, le 23 juillet 2009, à 20:00, Aaron J. Seigo a écrit:
> > > > what is the motivation for moving it into kdeutils, exactly?
> > >
> > > Toma gave release management as a reason, cmp. the email you replied
> > > to. Isn't this the only difference between the "normal" modules and
> > > extragear?
> > no; release management really ought to be extended to extragear, but
> > that's been only half-way managed properly at this point.
> Anyone can tell why?
mostly because of man power, partly because we haven't defined clearly how
this should be accomplished in all cases.
> > but if the issue is
> > release management, then we'll end up with hundreds of apps in the main
> > modules and there will be simply no way to communicate "these are the
> > core applications we recommend for basic functionality expected from a
> > desktop computer for <category>". at that point we may as well do it all
> > as extragear. i do think there is real value to having a clear set of
> > "basic apps", and the feedback received in past years about "kde's 3 text
> > editors" supports that.
> I think the "kde's 3 text editors" feedback was rather about a preselection
> of which program of a kind (if there are several) we deliver in the main
> modules, and not which kinds of program are part of a somehow "basic"
> desktop, no?
indeed; it wasn't the only place we ran into this, however, and making the
modules "free for alls" just causes problem when the next app of the same
category comes in. it's really important to keep a clear purpose to each
module for this reason.
another reason for keeping the module sane is that they provide a good
suggestion to distributions for the "the needed bits", in line with KDE's
original goals from 1997, while providing extragear as a nice buffet of
choices for them to add from to make their KDE offering full featured in a way
that makes sense for their users.
this way we (and our users) can count on a more consistent "base KDE" and
distros still have a great selection to choose from.
> And until there are really "hundred of apps" in extragear I cannot follow
> you. Especially for a category as broad as Utility.
yes, there are "only" a little under 50 apps in there right now. it'd be great
to see it grow a lot bigger .... there are many KDE applications out there
that would be great to bring in closer to the rest of the "KDE Universe", but
to do that we need to have a system that's ready for such a thing.
> BTW: Concerning the doubling of functionality, what to do with e.g. KCalc,
> KCharSelect, and KDF and their counterparts as plasmoids? Put them all
> together in one module, make separate modules plasma-utils or what else
> would fit into your vision of module organisation with basis app(lets)?
this is a slightly different topic, but relevant indeed.
i really don't want to see plasma components spread all over our svn unless
they are really tightly bound to a given application (such as some of the kde
edu ones) as it would make it far more difficult to manage them for the plasma
team and from the user perspective they are all "just widgets".
for the specific examples, KDF is really a subset of what one gets with the
system monitor widget which in turn is just a simplified front end to the
ksysguard libs. KDF could probably be fairly easily replaced if we wanted with
something like `plasmoidviewer sm_hdd` (though plsamoidviewer would need a
bit, though not a lot, of work to really provide a nice user experience in
replacing KDF), but really the end goal IMO is to provide nice tools that
integrate well with the desktop as well as full featured applications.
kcharselect offers a number of features over the charselect plasmoid. the
plasmoid could be extended to be as featureful as kcharselect, but that would
start to make it uncomfortable as a canvas component (from an interaction POV)
kmix would probably be better served as a plasmoid: it's simple and really
"system shell" kind of stuff.
but i don't think we should in general go around trying to replace apps with
plasmoids which should be much simpler and purpose specific and work as small
components with each other.
i do think that kdeplasma-addons really belongs in extragear where it started
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel