Proposed new kdelibs time zone classes

Dominik Haumann dhdev at gmx.de
Mon Oct 17 10:13:04 BST 2005


On Monday 17 October 2005 12:54, Benjamin Meyer wrote:
> On Sunday 16 October 2005 7:07 pm, David Jarvie wrote:
> > Here is my proposed new code for the kdelibs/kdecore time zone classes.
> > I've attached new code rather than diffs since the changes are very
> > substantial (although some parts of the existing code is still
> > retained). The aim of the changes is to provide base classes to use for
> > deriving non-system time zone classes. In particular, this will form a
> > basis for implementing time zone classes for iCalendar time zone data,
> > which should allow some long standing bugs in kdepim to be fixed. The
> > current time zone implementation is only really suited to dealing with
> > system time zones, not time zone information from other sources.
> >
> > See the discussion on 29th and 30th September in this mailing list
> > (http://lists.kde.org/?l=kde-core-devel&m=112800361918888&w=2 etc.) for
> > more details.
> >
> > Note that I haven't yet tested the KTzfile* classes - I'm in the
> > process of doing that now. The system time zone handling doesn't depend
> > on them, so they aren't so important.
> >
> > Can I commit?
>
> Docs and tests!  Yah :)

Also note, that he uses @defgroup and @ingroup for grouping. I think this is 
a very good approach and we should use it all over KDE (where it makes 
sense).

Groups coming into my mind for kdecore are fox example:
 - Core Classes
   KApplication etc
 - DCOP (DBUS) Architecture
 - Localization
   KTimezone, KLocale, etc.
 - Calendar System
   Contains *Calendar* classes
 - Configuration Management
   KConfigBase etc.
   maybe even subgroups for KGlobal*, KStandardDirs
 - Completion System
   KCompletion etc.
 - Launching Processes
   KProcess, KShellProcess etc.
 - NET Window Manager Specification
   NET*, KWin, etc.
 - Loading Libraries at runtime
   KLibLoader etc.
 - Network Support
   KSocket etc.
 - Icons and Themes
   KIcon*

This list was created by just looking over what classes exist. I'm sure it's 
possible to bring it in a good shape ;) At some points subgroups make 
sense.

cu,
-- 
Dominik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051017/82f8d1d5/attachment.sig>


More information about the kde-core-devel mailing list