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.
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
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.
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
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
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…
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.
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 ...
