tde-devels

devels@trinitydesktop.org

4 participants
3805 discussions

Re: [trinity-devel] kstyle-tdestyle renaming --- update
by Darrell Anderson 15 Aug '13

15 Aug '13

On Tue, 13 Aug 2013 19:48:37 -0500 "Timothy Pearson" <kb9vqf(a)pearsoncomputing.net> wrote: >>>>> 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. :-) >> >> Creating patches went surprisingly smooth. The final list is >short: >> >> tdelibs >> tdebase >> tdeartwork >> tdesdk >> tde-style-lipstik >> tde-style-qtcurve >> koffice >> tde-i18n >> >> I had no build errors. A superficial test of selecting the >styles >> in kcontrol resulted in no errors or problems. >> >> Caveat: The tde-i18n patch is huge. So huge that I will not even >> try to post the patch or try to push to git until I reduce to >> smaller patches and push piece-meal one at a time. >> >> That said, how do we want to proceed next? I can post the >patches >> online and somebody else could test. Or I could just push to git >> and listen for screams of pain and anguish. No problems noticed >> here, but I'm only one person with my own perspective. >> >> Darrell > >Slavek, can you handle updating the Debian/Ubuntu packaging files >for this change? Am I supposed to push the patch set to git? Darrell

2 1

Re: [trinity-devel] Valgrind
by Darrell Anderson 15 Aug '13

15 Aug '13

>Whenever an application misbehaves in an unusual manner (e.g. >platform >dependent, working one day and not another, etc.) I generally run >it under >Valgrind to see if there are any memory corruption issues. >Otherwise, for >fun I sometimes load applications under Valgrind, but that is the >extent >of the QA in this area. Is there anything we can do to supplement that kind of approach? I'm no valgrind expert at all. Just curious whether we can help Trinity with valgrind. Darrell

1 0

Automated qt3->tqt3 updates
by Darrell Anderson 15 Aug '13

15 Aug '13

I see some qt3 updates in the commit list web page for bug report 1350. I am able to pull those changes. I am not seeing any changes in tqt3 to pull. Is the automated tqt3 script functioning? Darrell

3 5

Valgrind
by Darrell Anderson 15 Aug '13

15 Aug '13

I read an article today abut using Valgrind to test software code. Do we perform any such tests for Trinity? If not then how could we start such a program? Darrell

2 1

Re: [trinity-devel] ktorrent and avahi
by Darrell Anderson 14 Aug '13

14 Aug '13

>I've attached it. If I'm reading it correctly, once it's applied, >you pass --without-avahi to disable the relevant code. I updated the patch for the tqt framework. I tested with avahi/avahi-tqt installed and not installed. Looks great. I'll push to git. Note to all: the defaults remain the same. As mentioned, --disable- avahi must be explicitly defined in the configuration. Otherwise nothing changes --- even the configuration warnings remain the same when avahi is not found and will not be compiled. Thanks! Darrell

1 0

Re: [trinity-devel] kstyle-tdestyle renaming --- update
by Darrell Anderson 14 Aug '13

14 Aug '13

>> >btw: haven't forgot to rename cmake variables? e.g. in >> >tdeartwork... >> >> Is that a question? To me? >> >Um... yes,,,, why are you so mush surprised? >During most of previous renames, I noticed, the cmake options were >left-behind, No, I wasn't surprised. I just did not understand the question. If you mean, did I remember to update the CMakeLists.txt files, yes. :- ) As I mentioned, everything built without error, everything installed to $PREFIX/share/apps/tdestyle, and there is no remnant $PREFIX/share/apps/kstyle after updating the packages. Typically though I tend to forget to run 'git add --all' before creating the commit message. I know better --- but there isn't a sufficiently hefty 2x4 here to sometimes remind me. :-) Darrell

1 0

Re: [trinity-devel] kstyle-tdestyle renaming --- update
by Darrell Anderson 14 Aug '13

14 Aug '13

>> Caveat: The tde-i18n patch is huge. So huge that I will not even >> try to post the patch or try to push to git until I reduce to >> smaller patches and push piece-meal one at a time. Woops! A typo in my diff command resulted in the large diff. The final patch is now MUCH smaller and sane. :-) >I don't feel that I'm one of core testers, but why not to push >them into >their own branch and let somebody test it? >IMO It's easier than mess with patch-sets and no mob of angry >developers or >testers will not want to broke your legs ;) Branch? Um, nope, ain't going down that road. :-) Git hates me and I hate git. I'm reasonably confident the patch set can be pushed to git as is because I'm seeing no problems here. I asked the question of posting patches for testing in case others don't feel confident, which I'm fine with. >btw: haven't forgot to rename cmake variables? e.g. in >tdeartwork... Is that a question? To me? Darrell

2 1

Re: [trinity-devel] kstyle-tdestyle renaming --- update
by Darrell Anderson 14 Aug '13

14 Aug '13

>>> 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. :-) Creating patches went surprisingly smooth. The final list is short: tdelibs tdebase tdeartwork tdesdk tde-style-lipstik tde-style-qtcurve koffice tde-i18n I had no build errors. A superficial test of selecting the styles in kcontrol resulted in no errors or problems. Caveat: The tde-i18n patch is huge. So huge that I will not even try to post the patch or try to push to git until I reduce to smaller patches and push piece-meal one at a time. That said, how do we want to proceed next? I can post the patches online and somebody else could test. Or I could just push to git and listen for screams of pain and anguish. No problems noticed here, but I'm only one person with my own perspective. Darrell

3 2

Re: [trinity-devel] ktorrent and avahi
by Darrell Anderson 14 Aug '13

14 Aug '13

>I've attached it. If I'm reading it correctly, once it's applied, >you >pass --without-avahi to disable the relevant code. Hey, thanks! I'll give that a whirl. >Note that I don't actually use ktorrent—I'm mostly just reading >old ebuilds. I don't either, but I build most of the packages simply to help the project. :-) Darrell

1 0

Re: [trinity-devel] ktorrent and avahi
by Darrell Anderson 14 Aug '13

14 Aug '13

>ktorrent proper doesn't depend on avahi, but it has an optional >plugin that does, and by default the build system checks to see if >avahi is present. There's an old Gentoo patch that I think is >intended >to provide support for explicitly disabling avahi (thus killing >the check >and just not building the plugin) via a configuration option, but >it >obviously won't apply if ktorrent has been converted to CMake. > >In other words, the warning is harmless if you're okay with >autodetects, >but we may be able to fix it anyway. Any chance you could find the patch? I should be able to massage into our tqt3/renaming framework. I realize there is no harm, but I like clean builds and a tad of "spit polish." :-) Darrell

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels