tde-devels

devels@trinitydesktop.org

2 participants
3755 discussions

by Darrell Anderson

All, Currently the kstreamripper help handbook is only a handbook template. We could use a basic English handbook. The app does not look complicated or involved. A single window interface. Probably won't take long to describe the basic features. As with kquirrel, don't worry about html or docbook. Plain text files will suffice. :) Thank you! Darrell

11 years

Re: [trinity-devel] hal & 3.5.13-sru - future -> argument to bring hal in-house

by Darrell Anderson

> All, what is the consensus? Will you need hal and if so, would >you help update it if Tim set it up here? Me personally? No. :) How many Trinity users are still using HAL based distros? Does Trinity build on those older releases? The oldest Slackware release upon which I can build Trinity is 13.1, which is HAL based. Trinity won't build on older releases for other reasons but HAL is not one of those reasons. Rather than supporting a full blown HAL git branch, how about just uploading upstream patches? Nothing more. For example, we don't have a wv2 branch, but we do need knowledge where to find wv2 patches. Likewise for HAL. Right now we already have a git module called thirdparty. The only submodule now is libreoffice. Add appropriate submodules as needed: wv2, HAL, etc. Add the necessary patches there. Post a wiki article with links to the thirdparty patches. Darrell

11 years

Re: [trinity-devel] Final inspection for KDE-TDE/kde/tde rebranding issues

by Darrell Anderson

>I'm not really clear on what it is you want to search for. Here is a sample of the type of multiple line strings I want to search: TQWhatsThis::add( clickRaiseOn, i18n("When this option is enabled, the active window will be brought to the" " front when you click somewhere into the window contents. To change" " it for inactive windows, you need to change the settings" " in the Actions tab.") ); The important point is the string is multiple lines. The only known constants are the first line contains a call to TQWhatsThis and the end of the string is a semi-colon. More than likely, the last two characters are known: a closing parentheses and a semi-colon. I want to run a comprehensive check against the entire source tree looking inside these types of strings for references to "KDE" or "kde." For branding purposes we want to update most of those references to "TDE" and "tde" respectively. This example string does not contain a KDE/kde reference. I would not want this particular string to bubble up in my search. Only those multiple line strings that contain "KDE or "kde." There are legitimate strings where KDE/kde should be left as is, such as accreditations to past developers. I don't want to perform a search-and-replace. I only want to perform a search. I want to manually read any remaining KDE/kde remnants in context to decide whether to update to TDE/tde. grep won't do the job. Something likely could be wrangled out of the -A option. but I suspect that kind of script would be slow, needing to continually test whether the last line contains a closing parentheses and a semi-colon. I presumed somebody skilled in perl would be able to see the light but I am not a perl user. I also want to perform the same type of search against TQTooTip multiple line strings. There are also multiple line strings in *.ui files containing What's This and Tooltip strings. There the usage is different: <property name="whatsThis" stdset="0"> <string>Enter the command you wish to execute or the address of the resource you want to open. This can be a remote URL like "www.kde.org" or a local one like "~/.tderc".</string> </property> <property name="toolTip" stdset="0"> <string>Slow processors perform poorly with effects</string> </property> In the *.ui files the known constants are <property name=xxx > and </property>. Darrell

11 years

hal & 3.5.13-sru - future -> argument to bring hal in-house

by David C. Rankin

Slavek/Tim, All, I don't know what the lifetime plans for 3.5.13 are, but given upcoming automake 2.0 issues facing hal, if 3.5.13 will be around for more than a year or so, it would make sense to bring hal/hal-info in-house while the updates to the source tree are still manageable. (as done with Qt3) As of automake 1.14, hundreds of warnings are generated regarding 'subdir-objects' being disabled in automake and build fails due to obsolete macros. I have added the subdir-objects option to AM_INIT_AUTOMAKE in configure.in for Archlinux builds and added 'autoupdate' to correct the obsolete macro build failure. Hal then builds fine. Currently there are over 1M of patches applied to the hal 0.5.14 source. When 6 patch files encompassing over a megabyte of diffs are required, the chance for subsequent patches breaking prior patches poses a real problem. If 3.5.13 will be around for a while and still need hal/hal-info, it may make sense to bring hal in-house and clean it up/apply the current patch sets and make it available to those still working with 3.5.13. The last updates applied to the hal code date back to 2011 - centuries ago in Linux terms. Hal and hal-info presently exist in a git repository. That may make it easier to bring the code in-house for update. These are just thoughts I had after going though the process to update and build hal yesterday. Here are the locations of the two git repositories. Git repositories: git://anongit.freedesktop.org/hal git://anongit.freedesktop.org/hal-info It may not be worth the effort, but for those distros on automake 1.14 that will be moving to automake 2.0 when released, I doubt hal will build without some significant updates. If 3.5.13 will continue to need hal and will be around for a while, some planning and effort now (after R14 is out the door) may pay dividends in the future... Apparently automake 2.0 will force object files to be produced in the current directory deprecating the multiple subdirectory Makefile source references that hal currently uses. E.g. from partutil/Makefile.am: libpartutil_la_SOURCES = partutil.h partutil.c ../hald/logger.c ../hald/logger.c produces the subdir-objects warning that from my understanding will cause failure in automake 2.0. If the AM_INIT_AUTOMAKE([subdir-objects]) option will take care of this problem in 2.0, then it isn't that much of a problem, but if not, then a bit of work will be needed on hal. I am still not very clear on all the implications, but from working through the build on automake 1.14, this was the impression I got. Think about it, you all decide, I'm going to try R14 and nohal and see how it goes... -- David C. Rankin, J.D.,P.E.

11 years

Re: [trinity-devel] Final inspection for KDE-TDE/kde/tde rebranding issues

by Darrell Anderson

>> >I would like to inspect source tree text strings for instances >of >> >KDE/kde rebranding issues and update to TDE/tde. Mostly in >> >tooltips >> >and What's This help strings. My challenge is being able to >> >efficiently grep only those strings, which often in the sources >> >are multiple lines. >> > >> >I would appreciate shell scripting advice to find such text >> >strings. >> >> Nobody knows? > >It would help to search whole words - grep option '-w'? I don't understand how that helps. For example, I want to find all TQWhatsThis strings, which often are multiple lines, and ensure I am searching the entire string, which includes all the multiple lines. About the only thing I know is the search will key on something like TQWhatsThis and the entire glob of text to search will end with an apostrophe (;). All of that constitutes the entire string that must be searched for 'KDE/kde'. Darrell

11 years

Darrell - Build Script Updates - go bys online?

by David C. Rankin

Darrell, I am having to go one-by-one through my build scripts for each tde package and remove old patches, etc. I don't know which ones are still needed. Eg (for tdebase): msg "Patching - tdebase patch set...." for patch in ${srcdir}/patches/*.patch; do _p=`basename $patch` msg "Applying patch $_p..." patch -Np0 -i $patch done Do you still have your build scripts online? I see you closed humanreadable.nfshost, so I'm looking for a current set of "go bys" to prevent repeated build failures figuring out which current patches I need :) Help a brother out? -- David C. Rankin, J.D.,P.E.

11 years

Re: [trinity-devel] Need debian help - what fixed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707417

by Darrell Anderson

>That fixed the FTBFS - Why the FILE_OFFSET_BITS=64?? There is no >way file size exceeds (2<<31)-1 bits?? I don't know. I only remember seeing the same build failure as you described. What I shared is the result of my repairs. Darrell

11 years

Re: [trinity-devel] Need debian help - what fixed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707417

by Darrell Anderson

>Will do, I also just built it with: > > cmake ../${pkgname}-${pkgver} \ > -DCMAKE_BUILD_TYPE=Release \ > -DCMAKE_SKIP_RPATH=ON \ > -DCMAKE_INSTALL_PREFIX=/usr \ > >-DLIBGSF_INCLUDE_DIR="/usr/include/libgsf-1;/usr/include/glib- >2.0;/usr/lib/glib-2.0/include;/usr/include/libxml2" My build script configuration: SLKCFLAGS="$SLKCFLAGS `pkg-config libgsf-1 --cflags`" SLKCFLAGS=" -D_FILE_OFFSET_BITS=64 $SLKCFLAGS" mkdir -p build cd build cmake \ -DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \ -DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \ -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_BUILD_TYPE=Release \ -DLIB_SUFFIX=${LIBDIRSUFFIX} \ .. Darrell

11 years

Re: [trinity-devel] Need debian help - what fixed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707417

by Darrell Anderson

>but for some reason cmake doesn't find it. I'm too dense to find >out where/why it isn't being use. Where do I look? I vaguely recall encountering the same failure about tree.h. After I found the patches I previously attached I then was able to compile wv2. Head to this URL: http://snapshot.debian.org/package/wv2/0.4.2.dfsg.1-10/ Download the file in the first link, which is a tar.gz. Open the tar.gz and notice the directory of patches. Use those patches to build wv2. That should resolve wv2 concerns. Darrell

11 years

Re: [trinity-devel] Need debian help - what fixed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707417

by Darrell Anderson

>Debian fixed a bug with wv2 I need to patch/fix for tde. The bug >was: > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707417 > >How in the heck do you find out what debian did? I have never figured out how to find patches mentioned in Debian bug reports. I'm sure there is a method to their madness. Attached are two patches I use to build wv2. The patches only allow me to build wv2. I have no way of knowing whether wv2 is actually providing kword the necessary support because wv2 has been unsupported for a long time. Probably should be Yet Another Bug Report. Darrell

11 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels