>> Should the kstyle directories and files be changed to tdestyle?
>>
>Probably. How much would that break at this point though
>configuration wise?
I don't know. I'm not complaining. :-) I only noticed the
differences when I was responding to bug report 1609. Seems we have
moved far with so much renaming and of late we have continued some
mopping up of those efforts. :-)
A quick scan of modules that install files to
$PREFIX/share/apps/kstyle:
tdelibs
tdebase
tdeartwork
tdesdk
I don't have all packages installed right now so there might be a
few more.
Other loose ends include renaming $TDEHOME/share/apps/kstyle-
>tdestyle, where ever that is defined (tdelibs?), and r14-xdg-
update. Probably other loose ends too.
I notice when grepping the sources some internal functions of
kstyle* still exist. tdebase/kpersonalizer has cpp files with
kstyle8.
I could hammer out and test the patches. The grunt work of the
patches should go fine, but I'd need a some days of validating
build runs and usability testing. If I get overwhelmed I holler.
Probably first scream and cry, but eventually holler. :-)
Darrell
>I'm currently using keramik. it's a pixmap theme isn't it? It's
>part of
>tdelibs, so it supposed to be supported...
I don't know.
>Although, I must point out that tdelibs currently FTBFS for me on
>the stage
>of generating files for it for some strange reasons...
I've gotten through the core packages and tdebindings. So looks
like all is well at my end, but I build traditional KDE/TDE mega
packages not one package for each app.
Darrell
Tim,
I recall the various internal kstyle->tdestyle lib changes. I
notice themes are still installed in $PREFIX/share/apps/kstyle/ and
user configs still use $TDEHOME/share/apps/kstyle/.
$HOME/.qt/kstylerc was since renamed to tdestylerc.
Should the kstyle directories and files be changed to tdestyle?
Darrell
>> Is that your request for guinea pigs? :-) Rebuild everything
clean
>> starting with tqt3?
>Yes it is. :-) Go ahead.
I've gotten through the core packages and tdebindings. So looks
like all is well at my end.
Darrell
>you don't have to if you don't want to... Both API and ABI are not
>supposed to be changed....
I just updated my local git sources after Tim's post. I'm
rebuilding a full package set now and will report as soon as
practical. :-)
Darrell
Hello,
as I mentioned in another thread, I noticed that the calls using TDE hwlib
daemons are with condition to WITH_UPOWER. Because these options are
completely unrelated, I propose to add new option WITH_TDEHWLIB_DAEMONS and
fix pertaining conditions.
Any objections?
Slavek
>I just pushed a patch that should resolve the tdebindings failure.
I'll test shortly.
>The hardware library split has been merged and all should be good
>to go for rebuilding at this time.
Is that your request for guinea pigs? :-) Rebuild everything clean
starting with tqt3?
Darrell
>I would expect that two systems would be needed--one with HAL but
>not upower etc.) and one with upower and friends (but not HAL).
I don't have an older build system with HAL.
>I am somewhat concerned about cluttering up the tdehwlib files
>with
>conditionals and such, however this may not be an issue once the
>source
>files are split into smaller chunks (e.g. Fat-Zer's work).
>
>On a related note, please do not commit any patches to tdehwlib
>right now
>as I am in the process of merging Fat-Zer's splitting of the
>source files.
Hmm, all of these changes sound like "Stop the presses!" Please
post when the tdehwlib merges and tdebindings/libtqt-perl fixes are
complete. Seems otherwise things will break when attempting to
compile. :-)
Darrell
Using top on my dual core systems during idle periods, kicker,
kmix, and notification-daemon-tde are always at the top of the
CPU%. Typically the numbers hover about 2%. Other Trinity apps
bubble in and out of list yet typically average at 0%.
Are the kicker, kmix, and notification-da values normal for idle
periods?
Darrell