Redefining kdelibs and kdebase
Aaron J. Seigo
aseigo at kde.org
Mon Aug 29 09:38:41 BST 2005
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
> 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
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
> 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.
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
> 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.
> 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
> 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
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel