2013/8/6 Timothy Pearson <kb9vqf@pearsoncomputing.net>
> 2013/8/6 Darrell Anderson <darrella@hushmail.com>
>
>> 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.
>>
> Everything I wrote is my plans and view of the situation. I've just
> intended to start a discussion...
> Sorry if it was sound too strongly.

No problem.  I personally would like to keep the hardware module in
tdecore (at least for now), as part of the original idea was to make
hardware functions extremely easy for TDE applications to access.  In my
experience, unless something is easy to access, very few people will use
it. :-)
The only two difference (if we won't count cosmetic changes like new namespace and removing TDE prefix from names) is that instead TDEGloval::TDEHarrdwareDevices() the user will call HarrdwareDevices::instance() and add tdehw-shared to LINK (for cmake). so I don't see any problems with that.

Here are some reasons to have tdehw in a separate library:
1. It provides specific functionality. Really specific: you can count on fingers (maybe even on fingers of one hand how much apps are using it).
 2. the only thing witch bundles it to tdecore is hacks to TDEGlobal/KInstance. I don't know why you could resort to them rather than just to make TDEHardwareDevice an ordinary singleton. All in all they looks quiet ugly.
3. If you split tdehardwaredevices.h you'll get more than a dozen of headers. If you install them to the general include dir they will look quite ugly there, so it's good idea to install them to a subdirectory. Of course that can be done without a separating the library, but in such case it's a little confusing IMO.
Otherwise, I am fully in agreement with splitting up the monolithic
tdehardwaredevices.cpp file into a number of smaller files (this could be
theoretically be done for R14.0.0 as it is a cosmetic change), and also
adding pluggable module support (this will likely have to wait for R14.1.0
though).

Tim