6 Aug
2013
6 Aug
'13
12:21 a.m.
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:
1-4.
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
modules
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
tdehardwaredevices.
The repositories are here:
https://github.com/Fat-Zer/tdelibs.git
https://github.com/Fat-Zer/tdebase.git
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
do.
Just my two cents. :-)
Darrell
6 Aug
6 Aug
1:49 p.m.
New subject: [trinity-devel] Moving tdehwlib to a standalone library
2013/8/6 Darrell Anderson <darrella(a)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.
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
do.
I agree, it won't get into R14.0 branch. But I glad to here that it's ok
to
make API changes in R14.1, so we won't have to wait until R15.
Just my two cents. :-)
Darrell
2:45 p.m.
New subject: [trinity-devel] Moving tdehwlib to a standalone library
2013/8/6 Darrell Anderson
<darrella(a)hushmail.com>
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. :-)
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
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.
7 Aug
7 Aug
8:04 p.m.
New subject: [trinity-devel] Moving tdehwlib to a standalone library
2013/8/6 Timothy Pearson <kb9vqf(a)pearsoncomputing.net>
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.
2013/8/6
Darrell Anderson <darrella(a)hushmail.com>
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. :-)
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. 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
4125
days inactive
4126
days old
3 comments
3 participants
participants (3)
-
Darrell Anderson -
Fat-Zer -
Timothy Pearson