>> >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.
>>
>> Seems I was wrong about that...
I notice there is a kstyle/pixmaps/riscos directory of files
installed by tdelibs. My presumption then is the old pixmaps themes
remain supported in Trinity. I have no idea how to test other than
selecting the riscos theme in kcontrol.
Darrell
>I notice when grepping the sources some internal functions of
>kstyle* still exist. tdebase/kpersonalizer has cpp files with
>kstyle8.
kstyle8 should be kstyle*. :-)
Darrell
>> 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