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.
I did not read your posts that way. :-) I realize English is not the native language of many people. I try to read posts with the benefit of doubt. I try to read posts with the presumption that people are trying to improve existing conditions too.
I agree a discussion is relevant and important. Now that a discussion is started, let's see how things unfold. :-)
Darrell
2013/8/6 Darrell Anderson darrella@hushmail.com
I did not read your posts that way. :-) I realize English is not the native language of many people. I try to read posts with the benefit of doubt. I try to read posts with the presumption that people are trying to improve existing conditions too.
I agree a discussion is relevant and important. Now that a discussion is started, let's see how things unfold. :-)
Darrell
That was my mistake as well... I was a little on emotions than wrote those
lines =) Also I've already came with some workaround and that was a bit confusing too... For me it seems a bit easy to show what I want to be done rather than to describe it...
2013/8/6 Darrell Anderson darrella@hushmail.com
If you split tdehardwaredevices.cpp please post a note here in the list so we are aware during rebuilds. :-)
Darrell
If it would be done carefully no changes will be required to other
modules... at least on first stages.
PS: sorry, accidentally pressed «send» last time.
Tim, so, at least, what about of spliting the tdehardwaredevices.c? It even won't break any API.
I can adopt my current workarounds and provide the patch in an hour.
2013/8/11 Fat-Zer fatzer2@gmail.com
Tim, so, at least, what about of spliting the tdehardwaredevices.c? It even won't break any API.
I can adopt my current workarounds and provide the patch in an hour.
Ok, I,ve pushed to my repository (https://github.com/Fat-Zer/tdelibs.git) branch tdehardwaredevices-splited
If you decide to commit it you supposed to merge the branch to not to loose the history of moved files. The history of newly created files will be loosed in any case...
2013/8/11 Fat-Zer fatzer2@gmail.com
Tim, so, at least, what about of spliting the tdehardwaredevices.c? It even won't break any API.
I can adopt my current workarounds and provide the patch in an hour.
Ok, I,ve pushed to my repository (https://github.com/Fat-Zer/tdelibs.git) branch tdehardwaredevices-splited
If you decide to commit it you supposed to merge the branch to not to loose the history of moved files. The history of newly created files will be loosed in any case...
So this is functionally identical to the tde hardware library sources currently in GIT?
Thanks!
Tim
2013/8/11 Timothy Pearson kb9vqf@pearsoncomputing.net
2013/8/11 Fat-Zer fatzer2@gmail.com
Tim, so, at least, what about of spliting the tdehardwaredevices.c? It even won't break any API.
I can adopt my current workarounds and provide the patch in an hour.
Ok, I,ve pushed to my repository (https://github.com/Fat-Zer/tdelibs.git
)
branch tdehardwaredevices-splited
If you decide to commit it you supposed to merge the branch to not to loose the history of moved files. The history of newly created files will be loosed in any case...
So this is functionally identical to the tde hardware library sources currently in GIT?
Thanks!
Tim
Yes. At most you should recheck changes you commited on the last week. I tried to merge them carefully, but it was pain-in-ass because git doesn't handle it automatically.
Tim, great thanks for commiting the changes... Now forward-porting changes to the spitted-library branch would be much more easier...
Now so what about splitting tdehw to shared library. Reasons to do so I've already listed above.
Here are what changes will be required and why: 1. Remove hacks from tdecore (TDEGlobal and KInstance) Reasons: - It's just necessary part to move it away from tdecore. It's the only structural change. Others are just cosmetical renames... What to use in place of TDEGlobal::HardwareDevices() described above as weel.
2. Install includes to tdehw subdirectory and strip tde prefix from file names; Reason: - follow the behavior of other tdelibs libraries.
3. Introduce TDEHW namespace and move to it all exported classes. Reason: - The same.
4. Strip TDE prefix from classes. Reason: - The same, follow behavior of other libraries. - follow behavior of files ( from the second tip). - It useless with namespace. - Increase readability of files which are heavily using the library.
Any thoughts/comments/ideas?
2013/8/12 Fat-Zer fatzer2@gmail.com
Tim, great thanks for commiting the changes... Now forward-porting changes to the spitted-library branch would be much more easier...
Now so what about splitting tdehw to shared library. Reasons to do so I've already listed above.
Here are what changes will be required and why:
- Remove hacks from tdecore (TDEGlobal and KInstance)
Reasons: - It's just necessary part to move it away from tdecore. It's the only structural change. Others are just cosmetical renames... What to use in place of TDEGlobal::HardwareDevices() described above as weel.
- Install includes to tdehw subdirectory and strip tde prefix from file
names; Reason: - follow the behavior of other tdelibs libraries.
- Introduce TDEHW namespace and move to it all exported classes.
Reason: - The same.
- Strip TDE prefix from classes.
Reason: - The same, follow behavior of other libraries. - follow behavior of files ( from the second tip). - It useless with namespace. - Increase readability of files which are heavily using the library.
Any thoughts/comments/ideas?
So... any resolution on the idea? I can come back with patches in two days if I'd be given the green light and somebody would provide the list of tdehw-using modules.
-
Darrell Anderson -
Fat-Zer -
Timothy Pearson