tde-devels March 2025

devels@trinitydesktop.org

12 participants
11 discussions

Update for atavistic beginners link in the KDE3/TDE Tutorials page

by David C Rankin

All, Dead pages come back to life sometimes... The TDE wiki at https://wiki.trinitydesktop.org/KDE3_Tutorials lists the original link as dead for: Development/Tutorials/KDE3/Qt Designer and KDevelop 3.0 for Beginners It has been resurrected under: https://techbase.kde.org/Development/Tutorials/KDE3/Qt_Designer_and_KDevelo… I just happened to run across it and I thought I would pass it along. It appears a bunch of the KDE3 docs are in mediawiki form (not that they were all that complete at the time). Anyway, there may be one or two more that are helpful from those listed at: https://techbase.kde.org/Category:KDE3 Keep up the good work! -- David C. Rankin, J.D.,P.E.

2 weeks, 2 days

kicker misplaced after xrandr display position alteration

by Felix Miata

On most boots, I have 2 or 3 displays connected out of 4 normally available. It is unusual when more than one are same resolution as others. The only matched pair are 1680x1050. Most commonly it is 2560x1440 or 1920x1200 as primary, and 1680x1050 as other, or 2560x1440 as primary, and 1920x1200 and 1680x1050 as other. I keep an xrandr miniscript, in e.g. in Debian and *buntu /etc/X11/Xsession.d/, for the purpose of having the positions and primary as I usually want them with the particular PC involved, as among the PCs, available GPU outputs vary in number and type. On any given boot, I may either connect them differently, or want different positions than usual. Bug?: I cannot remember a time when the behavior was any better than now. When I run xrandr to make a change that should result in Kicker moving to a different display, it generally gets the resulting position wrong, sometimes above the (expected) bottom, sometimes misplaced horizontally. The only case I remember that it gets it right is if the change moves primary below another display instead of horizontally. Occurrance just observed resulted from: xrandr --output HDMI-1 --primary --output DVI-I-1 --right-of HDMI-1 This shifted side-by-side's primary as desired from 1680x1050 display to 1920x1200 display. Kicker moved from smaller display to larger, correctly positioned vertically, but off by 1680px horizontally to the right, thus mostly invisible. Only fix to this I've found without opening arandr or KControl (both of which I rarely open for such a purpose) is to alter the script, log out, and log back in. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

2 weeks, 5 days

Slackware build environment

by Darrell Anderson

I want to restore my old days of having a full Slackware TDE build environment. To my knowledge there is no full scale build tools for Slackware. I remember when I did this years ago I had some complex build scripts and environment variables to decide whether to build official releases from tarballs or from git. How are you folks supporting both environments? Complex build scripts? Separate but similar build scripts? Anything else to recommend before I venture down this road and likely go nuts? P.S. I have seen the wiki. My eyes still hurt -- been away from this kind of thinking too long. Thanks.

2 weeks, 6 days

DCOP fails to maximize a Konsole window

by J Leslie Turriff

In a particular script, I'd like to maximize the Konsole window, and DCOP seems like the way to do this, but though the DCOP interface for Konsole provides a maximize() function, it doesn't seem to do anything. Using KDCOP I found in Konsole-16415 => konsole-mainwindow#1, void maximize(), but it doesn't seem to do anything. Entering the equivalent command in Konsole, | @15:30:39 leslie@pinto | wd=~ | $ dcop --user leslie --session .DCOPserver_pinto__0 konsole-16415 konsole-mainwindow#1 maximize | rc=0 completes successfully, but the window does not become maximized. Is this DCOP function's purpose not what it seems, or perhaps I have found a bug? Leslie -- Platform: Linux Distribution: openSUSE Leap 15.6 - x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.1.3 tde-config: 1.0

1 month

tdepowersave dcop interface not working

by deloptes

Hi, does someone know why tdepowersave is not working with dcop or kdcop I am trying to change the scheme via dcop but get false and no change $ dcop tdepowersave tdepowersaveIface currentScheme Powersave $ dcop tdepowersave tdepowersaveIface do_setScheme Presentation false $ dcop tdepowersave tdepowersaveIface currentScheme Powersave but it is possible to change the scheme via the applet in the taskbar thanks -- FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

1 month

Cannot talk to TDE Launcher #224 in TDE 14.1.3.

by Alec Destry

About a week ago, I reported this bug in TDE 14.1.3 at https://mirror.git.trinitydesktop.org/gitea/TDE/tde/issues/224 but, so far, nothing has happened. Is that where bugs should be reported?

1 month

A new game

by Denis Kozadaev

Hi guys! I would like to offer you a new game called "Knight's tour" We palyed it 40 years ago on paper. About the game: https://en.wikipedia.org/wiki/Knight%27s_tour How it looks like right now: https://apt.tambov.ru/knighttour/ If you want to see it in the repo, just say commit and make a PR :)

1 month

Fwd: Re: Re: Cannot talk to TDE Launcher #224 in TDE 14.1.3.

by Alec Destry

Also, a root file manager, if not a full root GUI session, is necessary to compile programs and build RPMs from that, and that's also something I do. *Again, **I'm requesting this bug be researched and fixed.* -------- Forwarded Message -------- Subject: Re: [tde-devels] Re: Cannot talk to TDE Launcher #224 in TDE 14.1.3. Date: Fri, 7 Mar 2025 01:40:28 -0800 From: Alec Destry <xode(a)techccu.com> To: Dr. Nikolaus Klepp via tde-devels <devels(a)trinitydesktop.org> "/...Don't open root file manager windows. It's a bad idea in the first place to use a GUI filemanager as root. Can't tell you how often I've seen users trashing their system that way.../and complaining that it's what you do on M$ and the DE has to hande that..." TDE has that capability installed and for good reason. This has nothing to do with "M$" (Microsoft). *I'm requesting this bug be researched and fixed.* There are times when the system needs custom configuration and a root file manager is the way to do that, especially when you want to be able to set up your system so it can be restored from scratch without having to depend at all on the internet. On 3/7/25 01:09, Dr. Nikolaus Klepp via tde-devels wrote: > Anno domini 2025 Thu, 6 Mar 23:37:03 -0800 > Alec Destry via tde-devels scripsit: >> About a week ago, I reported this bug in TDE 14.1.3 at >> https://mirror.git.trinitydesktop.org/gitea/TDE/tde/issues/224 but, so >> far, nothing has happened. Is that where bugs should be reported? > Should be the right place :) > > Anyway, I just commented there: Don't open root file manager windows. It's a bad idea in the first place to use a GUI filemanager as root. Can't tell you how often I've seen users trashing their system that way ... and complaining that it's what you do on M$ and the DE has to hande that. But this is the unix way of livey: you are free to shoot yourself if you feel like it. > > Nik > >> ____________________________________________________ >> tde-devels mailing list --devels(a)trinitydesktop.org >> To unsubscribe send an email todevels-leave(a)trinitydesktop.org >> Web mail archive available athttps://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinityde…

1 month

Problem with TDE 14.1.3 ARK timestamp for files in ZIP archive.

by Alec Destry

On 26 July 2021, I reported that KDE 3.5.10 ark shows a messed up timestamp when viewing a ZIP archive using the latest versions of unzip. I've since installed TDE 14.1.3 and have found the same problem exists with TDE ark as well (trinity-ark-14.1.3-1.oss156.x86_64.rpm). Unzip (unzip-5.52-77.x86_64.rpm), some years ago, when listing files in an archive, showed the timestamp for those files in the format of MM-DD-YY. The latest versions of unzip (unzip-6.00-89.1.x86_64.rpm), when listing files in an archive, shows the timestamp for those files in the format of YYYY-MM-DD. This change in how unzip shows timestamps caused KDE 3.5.10 ark, and is also causing TDE 14.1.3 ark, to show a messed up timestamp when viewing a ZIP archive using the latest versions of unzip. Rolling back to the older version of unzip gets rid of the problem. However, that could create other problems. Also, TDE ark (trinity-ark-14.1.3-1.oss156.x86_64.rpm) has many advantages over KDE4 ark and later, one prime example being its TDE konqueror integration. For these reasons, I'm requesting this bug be fixed.

1 month

libtqt-perl: how to use it?

by Dr. Nikolaus Klepp

Hi all! Has anybody experience with using libtqt-perl? Somehow I cannot get any test program running: $ perl /usr/share/doc/libtqt-perl/tutorials/t1/t1.perl Cannot find blib even in /usr/share/doc/libtqt-perl/tutorials/t1/../../../../.. BEGIN failed--compilation aborted at ./t1.pl line 3. Commenting out said line 3 and retrying: --- No method to call for : TQt::Application(ARRAY(0x560d6f75b3c8)) at ./t1.pl line 6. Line 6 is: my $a = TQt::Application(\@ARGV); So checking perl TQt API: $ pqtapi TQt|grep Application $ ... gives nothing. Testing pqtsh: $ pqtsh Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at /usr/lib/x86_64-linux-gnu/perl5/5.40/TQt/isa.pm line 48. Compilation failed in require at /usr/bin/pqtsh line 15. BEGIN failed--compilation aborted at /usr/bin/pqtsh line 15. So .. what am I missing? Does this interface work at all? Or better asked, when was the last time somebody has last tested it or seen it working? Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...

1 month, 1 week

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels March 2025