RFC: Moving RSIBreak to KDEUtils?

[Aaron J. Seigo]

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 
off, though.

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090723/047f02b8/attachment.sig>