tde-devels

devels@trinitydesktop.org

4 participants
3805 discussions

Re: [trinity-devel] Placing the Release Notes on the Desktop
by Darrell Anderson 18 Jan '14

18 Jan '14

>>> 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 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. I now recall an enhancement request that is similar to this dicussion: http://bugs.trinitydesktop.org/show_bug.cgi?id=832 Another option for the Release Notes is to add a special menu item that is enabled with each new release. The Release Notes would remind the user how to disable the menu item. Another option is a special device icon. The effect would be the same as that described in the original proposal, but is easily disabled in Configure Desktop->Behavior->Device Icons. This option could result in the previously described effects of modifying the user's desktp, but perhaps this special device icon could be coded to be placed somewhere on the desktop where icons normally are not placed. Then again, I have seen user desktops that are filled almost completely with icon shortcuts. In that case, the Release Notes icon would get lost. I think a one-time autostart might be best. That would cause only one one-time "intrusion," and I suspect with new package updates, user's would not mind the one-time intrusion. Darrell

3 2

Re: [trinity-devel] R14 - install to /opt or /usr ?
by Darrell Anderson 18 Jan '14

18 Jan '14

> 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? Nope. Not at all. Just the ones we thought would cause direct conflict during run-time. Although there was a lot of infrastructure and class renaming, many app names remain the same. If you install both desktops to /usr then one installation will overwrite the other with respect to the apps of the same name. Run-time conflicts are also avoided by the way we wrote starttde to ensure $PATH is always correct for a Trinity environment. Unless you are in total control of the target systems, or releasing your own distro where KDE4 never will be an option, just keep installing to /opt/trinity. I have been doing so now for two years and never have problems running from /opt/trinity. I keep KDE4 installed. Partly to test, partly to test potential conflicts between the two desktops. The only package I install to /usr is tqtinterface. I install all other packages to /opt/trinity. In my build scripts I install nominal docs, such as the traditional AUTHORS, COPYING, INSTALL, NEWS, TODO, jibberish documents to /usr/doc but that is all. As you have been a way for a while, we also decided as a team to name our packages using 'trinity' as part of the package name. The placement is not as important as including the name. I name all of my packages as trinity-${module}-i486-blah-blah.txz. Works for me nicely because those jibberish documents are easy to find in my /usr/doc because every single directory is named trinity-${module}. Also in my /var/log/packages history directory, I can type ls trinity-* and quickly find all of my Trinity packages. Darrell

2 1

Does tde need opt/tqt3/lib/libtqt-mt.la installed by tqt3 (or do I just remove it from package?)
by David C. Rankin 18 Jan '14

18 Jan '14

All, Running namcap package validation on tqt3, it lists opt/tqt3/lib/libtqt-mt.la as a libtool file that should be removed. I don't know why, but I think I recall that being something that tde actually needs or is somehow used by something else. If it isn't needed, then I'll remove it from my package, but how do I confirm nothing else needs it in tde? (other than learning no '.la' files are needed for anything?) What say the experts? -- David C. Rankin, J.D.,P.E.

2 2

Re: [trinity-devel] Placing the Release Notes on the Desktop
by Darrell Anderson 18 Jan '14

18 Jan '14

>>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. I'm now thinking we could add a link in the "Welcome to TDE" help handbook. We auto-start the handbook just once with the handbook opening directly to the Release Notes. The next time a user opens the main handbook, the "Welcome to TDE" handbook contains a link to the Release Notes. The one-time autostart would function much like this command: khelpcenter help:/khelpcenter/index.html?anchor=welcome To see the effect, copy and paste that command into the Run dialog (Alt-F2). Darrell

1 0

Re: [trinity-devel] Placing the Release Notes on the Desktop
by Darrell Anderson 18 Jan '14

18 Jan '14

>"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 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

2 1

Re: [trinity-devel] Python help please to fix help handbook installation
by Darrell Anderson 18 Jan '14

18 Jan '14

>>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 syntactically >>significant in Python. > >I tried that. No luck. No build failures or complaints, but no >index.docbook in the package. Still seeking a python wizard for this. I'm sure the problem is fixable in about two minutes. Thanks! :) Darrell

1 0

R14 - install to /opt or /usr ?
by David C. Rankin 18 Jan '14

18 Jan '14

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.

1 0

Placing the Release Notes on the Desktop
by Darrell Anderson 17 Jan '14

17 Jan '14

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. While the drafted README for R14.0.0 lists many changes, subsequent copies would only list bug and security fixes in that release and will not be large documents. Of course, the user is free to delete the document from the desktop at any time. The document reappears on the desktop only with new releases. We would need to update the document before officially releasing each subsequent release, but this simple mechanism would ensure users are updated with changes. Thoughts? Darrell

3 2

Seeking a Russian-to-English translator
by Darrell Anderson 17 Jan '14

17 Jan '14

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

2 1

Uugh! Arch! - Calvin - what changed in makechrootpkg?
by David C. Rankin 17 Jan '14

17 Jan '14

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' 'libkarma' 'libnjb' 'libutempter' 'mt-daapd' 'musepack-tools-svn' 'tde-tqt3' 'wv2' 'xmedcon') Now 'sudo mkchrootpkg -c -r $CHROOT' results in the following error: 21:25 phoinix:/dat_f/tde/stub> sudo makechrootpkg -c -r $CHROOT ==> Creating clean working copy [david]...done ==> Making package: tde-stub 0.1-1 (Thu Jan 16 21:25:34 CST 2014) ==> WARNING: Using a PKGBUILD without a package() function is deprecated. ==> Retrieving sources... ==> Making package: tde-stub 0.1-1 (Thu Jan 16 21:25:34 CST 2014) ==> WARNING: Using a PKGBUILD without a package() function is deprecated. ==> Checking runtime dependencies... warning: database file for 'local' does not exist ==> Installing missing dependencies... warning: database file for 'local' does not exist error: target not found: apetag-git error: target not found: libkarma error: target not found: libnjb error: target not found: mt-daapd error: target not found: musepack-tools-svn error: target not found: tde-tqt3 error: target not found: wv2 error: target not found: xmedcon ==> ERROR: 'pacman' failed to install missing dependencies. ==> ERROR: Build failed, check /dat_e/ch14/david/build Calvin, do you know what changed in chroot building on Arch that causes the local repo to no longer be found? I've posted on arch-general as well. -- David C. Rankin, J.D.,P.E.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels