Redefining kdelibs and kdebase

[Aaron J. Seigo]

On Saturday 27 August 2005 02:45, Benjamin Meyer wrote:
> -Biggest issue facing KDE is portability

i actually disagree completely. the biggest issue is not portability but code 
modularity and maintenance. these result in negative *effects* on things such 
as documentation and portability, but those are the consequences. i see in 
this thread man people have obsessed over the portability side of things and 
what that might mean for KDE, but it's hardly the root of the issue IMHO.

> [KDE Workspace]  [KDE Base]
>         \                           /

as i mentioned when we first went over this (i missed the subsequent group 
meeting, sadly), this is slightly inaccurate. really Workspace will depends 
on KDE Basics to be fully functional. this produces a much more 
straightforward and obvious "pipeline" starting with Qt and ending up with 
Workspace.

> KDE Components
> Consisting of portable, self contained classes that have unit tests.
> That classes should have as little dependancies upon other classes as
> possible.  Like Qt this should be divided up into core and ui
> libraries. 

for 3rd party developers it will be *critical* that we make it obvious what 
belongs where otherwise it will appear random from the outside world (e.g. 
3rd party open source developers and ISVs) and will become yet one more 
hurdle to using these tools. this is my only real concern is that we will 
start sorting out our classes based on implementation details rather than an 
API strategy.

> The maintainer should typically be the only commiters for
> each component.

i think this needs to be stressed a bit more:

	every item in Components *must* have a maintainer at all times

yes, this would be a restriction we are placing upon ourselves, but it's time 
we took true responsibility for our base environment. right now we treat 
kdelibs so poorly that it's a joke, and most of that is because of lack of 
stewardship over these critical bits. a bug or an error in Components effects 
every single KDE app. that said, maintainers SHOULD:

	- triage defect reports
	- manage community input (patches, primarily) to keep things moving forward 
in a non-chaotic method
	- keep up with the state of the art outside of KDE (e.g. if you are doing 
KWebService you need to be aware of what's happening with SOAP, AJAX, etc)

> KDE Frameworks
> Consisting of portable interfaces and classes.  The frameworks are
> the infrastructure that is used to create applications.   It only has
> a dependancies to Desktop through C++ interfaces or dbus

you mean dependencies to Workspace ;) and really there should be next to NO 
dependencies/assumptions on Workspace. this is doable as long as we don't 
stuff KFileDialog and KDEPrint into Workspace.

> KDE Workspace
> Consisting of what is the desktop.  Libraries and applications don't
> need to be portable and probably will only work with X11.  On other

> -System Settings (KControl or whatever it will be)

and just to be perfectly clear, this does not include the KCM classes, but 
just the ++KControl application.

> -KDEPrint
> -KFileDialog

IMHO these belong in Framework, not Workspace. they are not part of the 
desktop area and certainly are of interest to those running KDE apps on other 
platforms. just as we have XMLGUI in Framework, so we should KDEPrint and 
KFD.

> KDE Base
> Consisting of what runs on the desktop.  This packages is the basic
> set of applications beyond the desktop that KDE applications can
> assume are installed. 

s,desktop,Workspace,g

> These applications should have no problem 
> running on Windows, OS X or Gnome as stand alone applications is the
> user wanted them to be. 

i don't think this is a base requirement for these applications. it should 
happen organically if there is interest, but i'm not sure i see the benefit 
to making this an expected/required attribute of this layer.

> They would be useful applications in OS X etc. 

remind me why i care if the KDE File Manager runs on OS X again? or Konsole? 
or KWrite? Help Center i can understand, but for the others this makes very 
little sense, which makes this requirement a very poor part of the Basics 
definition IMHO.

> This module might not contain everything that a user would 
> expect a basic desktop to have (no calculator, spreadsheet etc) as
> those are in the rest of the modules (kdemultimedia, kdeutils etc)

this seems to miss the most obvious requirement for these apps: they are the 
ones that are needed to run Workspace without problems. we need a file 
manager to launch when someone clicks on an icon, we need a web browser to 
launch web pages from plasma, we need the help center to show user manuals, 
etc, etc... that makes it very obvious why these applications are bundled in 
this manner

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050829/2620eb26/attachment.sig>