tde-devels

devels@trinitydesktop.org

2 participants
3854 discussions

Re: [trinity-devel] What happed to checkbox to show/hide shutdown dialog on exit?
by Darrell Anderson 19 Jan '14

19 Jan '14

> I recall a protracted discussion about whether to show the >shutdown dialog >with all of the options or just logout. IIRC out of that >discussion the >following patch was born 'tdebase-feedbackdlg.diff' I cannot find >where it is >applied in the code. Do you recall what happened to this issue? KControl->TDE Components->Session Manager->Show logout status dialog Darrell

1 0

Re: [trinity-devel] Filename change kfileividesktop.cpp -> tdefileividesktop.cpp (but patch not applied)
by Darrell Anderson 19 Jan '14

19 Jan '14

> In working tdebase patches, I note that one of the traditional >patch files to I don't know what you mean by traditional patch files. If you are still applying patches from years ago, then likely you will make a mess. :) The only patches I apply these days are patches in the queue from the bugzilla or patches I create for testing. There are no more traditional patch files. Those days are long gone. Check the git history for patches: http://git.trinitydesktop.org/cgit/ You can narrow your search to specific cpp files. If you find no evidence a patch was applied --- and that includes remembering to check against all of the renaming and rebranding, then check the bugzilla. There remain many open bug reports with patches that have not been merged into git. When you check the bugzilla remember to use the ALL keyword to search closed and resolved reports too. If you come up empty, then file a new report and attach the patch, updated for renaming. Darrell

2 2

What happed to checkbox to show/hide shutdown dialog on exit?
by David C. Rankin 19 Jan '14

19 Jan '14

Darrell, I recall a protracted discussion about whether to show the shutdown dialog with all of the options or just logout. IIRC out of that discussion the following patch was born 'tdebase-feedbackdlg.diff' I cannot find where it is applied in the code. Do you recall what happened to this issue? -- David C. Rankin, J.D.,P.E.

1 0

Filename change kfileividesktop.cpp -> tdefileividesktop.cpp (but patch not applied)
by David C. Rankin 19 Jan '14

19 Jan '14

Tim, Darrell, In working tdebase patches, I note that one of the traditional patch files to the kdebase source (existing in patches.tar.bz2 - 08-kip_kdesktop_rounded_icon_text_corners.patch) is not applied in the current git source, and fails to apply due to the file name change. I think it is probably a good idea to keep the patch. The patch is: diff -Naur kdebase-3.5.8.orig/kdesktop/kfileividesktop.cpp kdebase-3.5.8/kdesktop/kfileividesktop.cpp --- kdebase-3.5.8.orig/kdesktop/kfileividesktop.cpp 2007-10-08 15:58:03.000000000 +0200 +++ kdesktop/kfileividesktop.cpp 2007-11-20 13:57:09.000000000 +0100 @@ -100,6 +100,13 @@ // draw the pixmap as in KIconViewItem::paintItem(...) paintPixmap(p, colors); + if ( isSelected() ) { + p->setBrush( TQBrush( cg.highlight() ) ); + p->setPen( TQPen( cg.highlight() ) ); + p->drawRoundRect( textRect( FALSE ), + 1000 / textRect( FALSE ).width(), + 1000 / textRect( FALSE ).height() ); + } My question is did all the code class names change as well?? I guess it doesn't matter here, but I've grepped and the only thing I come up with is: tdefileividesktop.cpp:87:void KFileIVIDesktop::paintItem( TQPainter *p, const TQColorGroup &cg) So I think the comment above is wrong as well. Do we want to try and apply the traditional KDE patches that remain in patches.tar.bz2 to the code before R14 release (fix them once and for all)? the only patches that remain are: patches/08-kip_kdesktop_rounded_icon_text_corners.patch patches/03-kcontrol_advbg_step.patch patches/06-nspluginscan-xdgcompliance.patch patches/01-kicker-lockout-applet-button-order.patch Let me know. I'll keep tweaking these for now. -- David C. Rankin, J.D.,P.E.

1 0

Arch - good news - R14 builds through tdelibs nohal (tdebase is a patch issue)
by David C. Rankin 19 Jan '14

19 Jan '14

Darrell, Tim, All, Job well done. I've build tde through tdelibs on bleeding-edge arch without issue (ok - well giant PITA rearranging dependencies, inventing systemd services files, etc. -- but NO TDE CODE issues) The current dependency and packages successfully built are: apetag-git-1.13-1-x86_64.pkg.tar.xz libkarma-0.1.2-1-x86_64.pkg.tar.xz libnjb-2.2.7-3-x86_64.pkg.tar.xz libutempter-1.1.6-2-x86_64.pkg.tar.xz mt-daapd-0.2.4.2-7-x86_64.pkg.tar.xz musepack-tools-svn-r484-1-x86_64.pkg.tar.xz tde-arts-14.0.0-1-x86_64.pkg.tar.xz tde-avahi-tqt-14.0.0-1-x86_64.pkg.tar.xz tde-dbus-1-tqt-14.0.0-1-x86_64.pkg.tar.xz tde-dbus-tqt-14.0.0-1-x86_64.pkg.tar.xz tde-libart-lgpl-14.0.0-1-x86_64.pkg.tar.xz tde-libcaldav-14.0.0-1-x86_64.pkg.tar.xz tde-libcarddav-14.0.0-1-x86_64.pkg.tar.xz tde-python-tqt-14.0.0-1-x86_64.pkg.tar.xz tde-sip-14.0.0-1-x86_64.pkg.tar.xz tde-sip4-tqt-14.0.0-1-x86_64.pkg.tar.xz tde-tdelibs-14.0.0-1-x86_64.pkg.tar.xz tde-tqca-tls-14.0.0-1-x86_64.pkg.tar.xz ** I split tqt3 into 2 packages ** tde-tqt3-14.0.0-1-x86_64.pkg.tar.xz tde-tqt3-docs-14.0.0-1-x86_64.pkg.tar.xz tde-tqtinterface-14.0.0-1-x86_64.pkg.tar.xz wv2-0.4.2-3-x86_64.pkg.tar.xz xmedcon-0.13.0-1-x86_64.pkg.tar.xz tdebase builds TONIGHT! -- David C. Rankin, J.D.,P.E.

1 0

Re: [trinity-devel] Konversation (IRC) question
by Darrell Anderson 18 Jan '14

18 Jan '14

> If you have konversation installed, just run it, the first >screen pops up and >tells you which channel is the default. You can cancel then. Okay, thanks. Incredibly, the defaults are hard-coded rather than as part of a ui file or default rc file. applications/konversation/konversation/src/config/preferences.cpp:72 -79 serverGroup->setName("Ubuntu IRC"); server.setHost("irc.ubuntu.com"); channel.setName("#kubuntu"); Is the following correct to patch the defaults for Trinity? serverGroup->setName("Trinity IRC"); server.setHost("irc.freenode.net"); channel.setName("#trinity-desktop"); Darrell

2 1

Re: [trinity-devel] Konversation (IRC) question
by Darrell Anderson 18 Jan '14

18 Jan '14

>Only way to check is to fire it up and see if you have an active >connection to >kde. We should really change it to open #trinity-desktop on >freenode :-) I don't do IRC. If I did I would not have asked the question. :) Darrell

2 1

Konversation (IRC) question
by Darrell Anderson 18 Jan '14

18 Jan '14

All, I don't use konversation. The following is a konversation What's This popup: "When Konversation is started for the first time, the Freenode network and the <i>#kde</i> channel are already entered for you." The po files repeat the same text. Is that statement true? Darrell

2 1

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

18 Jan '14

>Grrr. I knew I missed out of something important. I'm still >putting everything >in /opt/tde and all my packages are tde-appname-ver-minver.tar.xz. >At least >changing the prefix= will be a snap, picking through the build & >conf files may >be a bit of fun ;-) I don't know that /opt/tde won't work. I haven't tried. The 'trinity' tag was agreed upon for package names. Using /opt/trinity would make your builds consistent with the package names. Also, the default profile directory is ~/.trinity, therefore /opt/trinity would match that too. Consistency tends to makes us bipeds warm and fuzzy. :) If you have a working copy of tdewebdev installed, even 3.5.x, give tdefilereplace a whirl. Fairly slick tool for performing multi-line search and replace operations. I've used the tool several times to perform mass updates of my build scripts. Darrell

2 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels