tde-devels January 2014

devels@trinitydesktop.org

16 participants
197 discussions

Re: [trinity-devel] Placing the Release Notes on the Desktop

by Darrell Anderson

>"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote: > >> On 01/17/2014 12:26 PM, Darrell Anderson wrote: >> > All, >> > >> > The eventual release of R14 will mark a turning point in >Trinity >> > history. The R14 release is significant because of the many >class >> > and branding renaming changes. While we have drafted a README >> > document to explain such changes, we have no mechanism for >users … [View More]to >> > read the document. >> > >> > I would like to see us patch the sources such that a Release >Notes >> > document is always placed on the user's desktop when updating >to a >> > new release. That practice would continue with maintenance >releases >> > too. >> >> Darrell, >> >> I usually always agree with you, but here I don't. It >absolutely burns me up >> when an install places things on my desktop that I haven't told >it to put there >> and I don't want. I just think of windows and all the worthless >links you had to >> delete off the desktop just to see a clean desktop. >> >> I agree it would be good to give that information to users on >install, but >> can't we find a better place for it? Why not do it in: >> >> a small systray app that is run on first use after install; >or >> a button in the about:tde dialog access from every help menu; >or >> as an entry in tmenu -> README - R14 Release (opening in >kwrite) >> >> Anything, I mean anything, except a whopping big icon planted >on the desktop >> >> > Thoughts? >> >> You asked ;-) >> >> Where else do you think we could put it that would accomplish >what you are >> trying to do? > >A handbook entry or plain webpage, optionally force-opening it in >Konqueror >the first time a user logs into a new version of TDE? I know that >the handbook >is the first place I would probably look for the release notes if >I wanted them and >had no access to the website. > >I agree with David on not liking random things placed on my >desktop--it disrupts >my icon grouping and I would probably junk an involuntarily >installed icon without >checking to see what it did. I am open to ideas. I like the idea of a one-time autostart. Whether through the help handbook or just a text file in kwrite is fine. If we choose the help handbook then we need to convert the Release Notes into a docbook file and compile as bz2 html file, just like all other help handbooks, along with the same background theme. In that respect, a one-time auto-start of kwrite is much simpler. On the other hand, a one-time autostart of the help handbook is slick and polished, and we also can add the Release Notes into the main handbook table of contents for longevity. With the next maintenance release we update the document and reimplement the one-time autostart. We already track something similar every time the r14-xdg-update script runs. We could use a similar date tracking key in kdeglobals to ensure the one-time autostart. I see this as a basic courtesy to users as well as a nice touch of professionalism. As we plan to implement a 90 maintenance release schedule after R14.0.0, I believe now is a good time to discuss options for ensuring users have an opportunity to be informed. Darrell [View Less]

11 years, 1 month

Re: [trinity-devel] Python help please to fix help handbook installation

by Darrell Anderson

>>Python newb, and not really familiar with SCons as a build >>system, but my *guess* would be that you need to add: >> >>myenv.KDEinstall( 'KDEDOC', lang+'/'+destination, >>folder+'/index.docbook' ) >> >>right after: >> >>myenv.KDEinstall( 'KDEDOC', lang+'/'+destination, >>folder+'/index.cache.bz2' ) >> >>Make sure that the indentation of the two lines matches >>*exactly*, because leading whitespace is … [View More]

11 years, 1 month

R14 - install to /opt or /usr ?

by David C. Rankin

All, Darrell, I have traditionally installed tde in /opt, but if tqt3 is safe to install along side of qt4, then should we install everything in /usr now instead of /opt? Pros? Cons? I think for Arch, the powers-that-be would probably prefer and /opt install until it can be verified that an install in /usr will not conflict. Are all the tqt3/qt4 and tde/kde4 conflicts eliminated? -- David C. Rankin, J.D.,P.E.

11 years, 1 month

Placing the Release Notes on the Desktop

by Darrell Anderson

All, The eventual release of R14 will mark a turning point in Trinity history. The R14 release is significant because of the many class and branding renaming changes. While we have drafted a README document to explain such changes, we have no mechanism for users to read the document. I would like to see us patch the sources such that a Release Notes document is always placed on the user's desktop when updating to a new release. That practice would continue with maintenance releases too.… [View More]

11 years, 1 month

Seeking a Russian-to-English translator

by Darrell Anderson

All, The ksquirrel help handbook is written in Russian. We would like to have an English version. Please contact me if you want to help translate and need help with English. Or, just hack the Russian to English as best as possible and we'll coordinate the English later. Here is a link to the git version: http://git.trinitydesktop.org/cgit/ksquirrel/tree/doc/ru Don't worry about html or docbook. Plain text files will suffice. :) Thank you! Darrell

11 years, 1 month

Uugh! Arch! - Calvin - what changed in makechrootpkg?

by David C. Rankin

All, Calvin, Building in a clean chroot has changed significantly on Arch. My TDE build relies on being able to create and index a 'local' repo in $CHROOT/root/repo and add packages and update the index as each package is built. The appropriate entry is in $CHROOT/root/etc/pacman.conf: [local] Server = file:///repo The files are copied to $CHROOT/root/repo and the index built with: repo-add local.db.tar.gz *.xz A stub PKGBUILD is then created with: depends=('apetag-git' '… [View More]

11 years, 1 month

Seeking a kstreamripper user

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, 1 month

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 … [View More]

11 years, 1 month

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 … [View More]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 [View Less]

11 years, 1 month

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 … [View More]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. [View Less]

11 years, 1 month

← Newer
1
...
10
11
12
13
14
15
16
...
20
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels January 2014