Message: previous - next
Month: August 2013

Re: [trinity-devel] Moving tdehwlib to a standalone library

From: "Darrell Anderson" <darrella@...>
Date: Mon, 05 Aug 2013 19:21:07 -0500
>Hi, as I claimed just now on the neighbor thread, I'm working on 
>the move
>tdehwlib out of tdecore.
>why so:
>1. it provides specific functionality.
>2. Only few apps are using it.
>3. It's not integrated into tdecore except of couple unnecessary 
>and ugly
>hacks to KInstace.
>4. It's code is too robust while it's located in a single file.
>What changes are introduced:
>1. TDEHW namespace for all exported classes.
>2. Some specific macros.
>3. Move includes to tdehw directory.
>4. Strip TDE prefix from classes and file names.
>What is already done:
>5. Split tdehardwaredevices.{h,cpp} into several headers
>6. repair tdebase according to the changes
>What is to be done before merging the changes:
>1. Repair any other modules. (Is there any?)
>2. Some repair is needed to tdenetworkconnections.{cpp,h} and to 
>which use it.
>3. Testing.
>Further plans:
>1. Introduce the backend framework. On first stage in the most 
>basic way.
>2. Split tdenetworkconnections.cpp in the same way it was done for
>The repositories are here:
>See libtdehw branch.
>!WARNING! It supposed to be built and work but my be broken in 
>some options.
>Some questions:
>Is there any ather modules outside tdebase which use tdehw?
>Is there anything what uses tdenetworkconnections?
>Any other thoughts?

I don't pretend to understand the programming reasons cited above. 
Yet seems to me this topic needs to be discussed here.

I've probably done the most user testing with Tim. I've been using 
GIT pre-R14 for many months and I am not seeing any serious 
problems with tdehwlib. Whether the sources need to be moved to a 
separate module ultimately gets decided by Tim as he is the owner 
of that code.

Even if Tim wants to move tdehwlib to a separate module, I vote not 
to do that until after R14.0.0 is officialy released. Simply 
because we have enough on our plate right now to get R14.0.0 out 
the door. Although we are planning regular maintenance updates for 
R14.0.0 (R14.0.1, R14.0.2, etc.), ABI changes mean a bump in the 
second part of the version number: R14.1.0. There is no reason we 
can't do that as long as there is consensus that is what we want to 

Just my two cents. :-)