From kde-core-devel Mon Aug 29 08:38:41 2005 From: "Aaron J. Seigo" Date: Mon, 29 Aug 2005 08:38:41 +0000 To: kde-core-devel Subject: Re: Redefining kdelibs and kdebase Message-Id: <200508290238.49634.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=112530668731479 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart3457175.zpaIJMDbG5" --nextPart3457175.zpaIJMDbG5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 co= de=20 modularity and maintenance. these result in negative *effects* on things su= ch=20 as documentation and portability, but those are the consequences. i see in= =20 this thread man people have obsessed over the portability side of things an= d=20 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= =20 meeting, sadly), this is slightly inaccurate. really Workspace will depends= =20 on KDE Basics to be fully functional. this produces a much more=20 straightforward and obvious "pipeline" starting with Qt and ending up with= =20 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.=20 for 3rd party developers it will be *critical* that we make it obvious what= =20 belongs where otherwise it will appear random from the outside world (e.g.= =20 3rd party open source developers and ISVs) and will become yet one more=20 hurdle to using these tools. this is my only real concern is that we will=20 start sorting out our classes based on implementation details rather than a= n=20 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 ti= me=20 we took true responsibility for our base environment. right now we treat=20 kdelibs so poorly that it's a joke, and most of that is because of lack of= =20 stewardship over these critical bits. a bug or an error in Components effec= ts=20 every single KDE app. that said, maintainers SHOULD: - triage defect reports - manage community input (patches, primarily) to keep things moving forwar= d=20 in a non-chaotic method - keep up with the state of the art outside of KDE (e.g. if you are doing= =20 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= =20 dependencies/assumptions on Workspace. this is doable as long as we don't=20 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= =20 just the ++KControl application. > -KDEPrint > -KFileDialog IMHO these belong in Framework, not Workspace. they are not part of the=20 desktop area and certainly are of interest to those running KDE apps on oth= er=20 platforms. just as we have XMLGUI in Framework, so we should KDEPrint and=20 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.=20 s,desktop,Workspace,g > These applications should have no problem=20 > running on Windows, OS X or Gnome as stand alone applications is the > user wanted them to be.=20 i don't think this is a base requirement for these applications. it should= =20 happen organically if there is interest, but i'm not sure i see the benefit= =20 to making this an expected/required attribute of this layer. > They would be useful applications in OS X etc.=20 remind me why i care if the KDE File Manager runs on OS X again? or Konsole= ?=20 or KWrite? Help Center i can understand, but for the others this makes very= =20 little sense, which makes this requirement a very poor part of the Basics=20 definition IMHO. > This module might not contain everything that a user would=20 > 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 th= e=20 ones that are needed to run Workspace without problems. we need a file=20 manager to launch when someone clicks on an icon, we need a web browser to= =20 launch web pages from plasma, we need the help center to show user manuals,= =20 etc, etc... that makes it very obvious why these applications are bundled i= n=20 this manner =2D-=20 Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 =46ull time KDE developer sponsored by Trolltech (http://www.trolltech.com) --nextPart3457175.zpaIJMDbG5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBDEsmZ1rcusafx20MRAhvvAJ9xQ0ZmOvLX+YGPgFRTd1y4iXaOqwCgmFxi nbauvWIUIc8y75KrvaHASOs= =sFHE -----END PGP SIGNATURE----- --nextPart3457175.zpaIJMDbG5--