TDE devs,
Here is an odd bit of behavior with a new KDE3 install on openSUSE
Tumbleweed I'm trying to chase down and wonder if this has been seen on TDE
yet. The basic problem is with focus-follows-mouse set and no longer being
able to scroll Firefox or Thunderbird windows with the mouse-wheel UNLESS the
window is click and made top-level. (kinda defeats the purpose of
focus-follows-mouse...)
There is no question that the window receives focus, everything else works,
titlebar indicates focus, you can 'tab' between widgets in FF or TB, but the
mouse scroll does not work.
As a work-around you can set the environment variable
GDK_CORE_DEVICE_EVENTS=1 when starting either and then the focus-follows-mouse
works normally.
I've opened a bug:
Firefox Bug - no middle-mouse scroll on focused window not raised to top
https://bugzilla.mozilla.org/show_bug.cgi?id=1907708
only to find this is not a new issue:
Scrolling inactive windows in KDE/KWin with mouse wheel
https://bbs.archlinux.org/viewtopic.php?id=239918
Mousewheel action over Firefox doesn't work if Firefox window is not active
https://bugzilla.mozilla.org/show_bug.cgi?id=1359226
and to find this is likely related to the new KDE3 builds at openSUSE. I
have a Leap-15.4 install where KDE3 hasn't been updated since Sept. 2023 (it
was perfect -- why tempt something like this ....) So it may be related to
library version changes in the past 6 months or kernel differences between 5.4
and 6.9 or it could be due to a cockup in the build system.
Long story short I'm looking for more data points to help narrow down
where/what is causing this. Since this may be a Linux 6.9 or recent library
issue, I thought I would check if TDE has seen anything like this?
Also, a possible related issue has to do with the Run Command dialog
(Alt+F2) which I can summarize in a test case:
Test Case:
1. Alt + F2
2. type kmenuedit (tmenuedit on TDE IIRC)
3. return (to run it)
4. close kmenuedit
5. Alt + F2
6. type kmenuedit again
As you type the 'k' ('t' on TDE?) you will see the icon displayed change to
the kmenuedit icon showing at least the search-as-you-type part has identified
the prior kmenuedit command -- but -- the list-box does not open. You have to
manually click the list-box to see the previous kmenuedit command.
I don't know if this is related, but I thought I would add that scenario as
well. If you can't currently reproduce any of this -- good! But keep this in
mind if it should crop up in the future.
--
David C. Rankin, J.D.,P.E.
--
David C. Rankin, J.D.,P.E.
I thought I would get started with TDE programming, so I'm following the
steps in the Wiki Development section, "Qt Designer and KDevelop 3.0 for
Beginners". I followed the steps for creating the HelloWorld program
substituting TDevelop for KDevelop, and all went well until the Project Build
step, which failed, producing this output:
| cd '/home/development/TDEupdAlt/debug' && WANT_AUTOCONF_2_5="1"
WANT_AUTOMAKE_1_6="1" LC_MESSAGES="C" LC_CTYPE="C" gmake -k
| gmake all-recursive
| gmake[1]: Entering directory '/home/development/TDEupdAlt/debug'
| Making all in doc
| gmake[2]: Entering directory '/home/development/TDEupdAlt/debug/doc'
| Making all in .
| gmake[3]: Entering directory '/home/development/TDEupdAlt/debug/doc'
| gmake[3]: Nothing to be done for 'all-am'.
| gmake[3]: Leaving directory '/home/development/TDEupdAlt/debug/doc'
| Making all in en
| gmake[3]: Entering directory '/home/development/TDEupdAlt/debug/doc/en'
| /opt/trinity/bin/meinproc --check --cache
index.cache.bz2 /home/development/TDEupdAlt/doc/en/index.docbook
| gmake[3]: Leaving directory '/home/development/TDEupdAlt/debug/doc/en'
| gmake[2]: Leaving directory '/home/development/TDEupdAlt/debug/doc'
| Making all in po
| gmake[2]: Entering directory '/home/development/TDEupdAlt/debug/po'
| gmake[2]: Nothing to be done for 'all'.
| gmake[2]: Leaving directory '/home/development/TDEupdAlt/debug/po'
| Making all in src
| gmake[2]: Entering directory '/home/development/TDEupdAlt/debug/src'
|
g++ -DHAVE_CONFIG_H -I. -I/home/development/TDEupdAlt/src -I.. -I/opt/trinity/include/tde -I/usr/include/tqt3 -I. -include
tqt.h -DTQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -D_DEFAULT_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -fno-builtin -g3 -fno-inline -O0 -g3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT
main.o -MD -MP -MF .deps/main.Tpo -c -o
main.o /home/development/TDEupdAlt/src/main.cpp
| mv -f .deps/main.Tpo .deps/main.Po
| /usr/bin/tmoc /home/development/TDEupdAlt/src/tdeupdalt.h -o tdeupdalt.moc
|
g++ -DHAVE_CONFIG_H -I. -I/home/development/TDEupdAlt/src -I.. -I/opt/trinity/include/tde -I/usr/include/tqt3 -I. -include
tqt.h -DTQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -D_DEFAULT_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -fno-builtin -g3 -fno-inline -O0 -g3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT
tdeupdalt.o -MD -MP -MF .deps/tdeupdalt.Tpo -c -o
tdeupdalt.o /home/development/TDEupdAlt/src/tdeupdalt.cpp
| mv -f .deps/tdeupdalt.Tpo .deps/tdeupdalt.Po
| /bin/sh ../libtool --tag=CXX --mode=link
g++ -Wno-long-long -Wundef -D_DEFAULT_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -fno-builtin -g3 -fno-inline -O0 -g3 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -R /opt/trinity/lib64 -R /opt/trinity/lib64 -R /usr/lib64 -R /usr/lib64 -L/opt/trinity/lib64 -L/usr/lib64 -ltqt-mt -lz -lpng -lz -lm -lXext -lX11 -lSM -lICE -ltqt -lpthread -ltdecore -ltdeui -ltdeparts -o
tdeupdalt main.o tdeupdalt.o -ltdeui
| ../libtool: line 1300: func_opt_split: command not found
| libtool: Version mismatch error. This is libtool 2.2.6b
Debian-2.2.6b-2ubuntu1, but the
| libtool: definition of this LT_INIT comes from libtool 2.4.6.
| libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b
Debian-2.2.6b-2ubuntu1
| libtool: and run autoconf again.
| gmake[2]: Leaving directory '/home/development/TDEupdAlt/debug/src'
| gmake[2]: *** [Makefile:629: tdeupdalt] Error 63
| gmake[2]: Target 'all' not remade because of errors.
| gmake[2]: Entering directory '/home/development/TDEupdAlt/debug'
| gmake[2]: Leaving directory '/home/development/TDEupdAlt/debug'
| gmake[1]: Leaving directory '/home/development/TDEupdAlt/debug'
| gmake[1]: *** [Makefile:582: all-recursive] Error 1
| gmake: *** [Makefile:500: all] Error 2
| *** Exited with status: 2 ***
All went well until libtool was invoked, and I have to suppose that TDevelop
is (or thinks it is) using embedded libraries? because 1) I'm running on
openSUSE, not Debian ubuntu, and 2) my current installed libtool is
|@17:51:37 root@pinto
| wd=~
| ● rpm -q libtool
| libtool-2.4.6-150000.3.6.2.x86_64
| rc=0
Am I going to have to download TDevelop and compile it on my system?
Leslie
--
Platform: Linux
Distribution: openSUSE Leap 15.5 - x86_64
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.1.2
tde-config: 1.0
Hi,
last week or so someone raised the topic around org.freedesktop.ScreenSaver
https://specifications.freedesktop.org/idle-inhibit-spec/latest/ch05.html
I created one application (I will publish on my TGW projects page soon)
implementing the interface and let it run over time while watching now and
then videos on youtube or else where in Firefox.
Today I fell asleep while watching - haha, getting older :) and when I
checked the output, I saw following [1], which tells me that indeed video
applications are using this interface.
I also saw a lot of stuff around screen saver in various applications (for
example tdepowersave (just grep screensaver or screen in applications).
I saw there many things that I think, might be not really contemporary and
hence not needed any more.
I want to discuss here that path forward. AFAIR we were talking about doing
something about automating dbus interface usage (similar to newer Qt4 and
Qt5). I think it was around hwcontrol (tdelibs/tdecore/tdehw) In any case I
think, we have to do something as more and more interfaces are defined and
more and more services implement those interfaces.
Can we have an update on the topic?
BR
[1] output of the application debug log
[2024/05/27 17:34:01.787] ScreenSaverInterfaceImpl::Inhibit: Reason:
video-playing
[2024/05/27 17:34:03.550] ScreenSaverInterfaceImpl::UnInhibit: cookie(7),
application(), reason(video-playing)
[2024/05/27 17:34:09.569] ScreenSaverInterfaceImpl::Inhibit: Reason:
video-playing
[2024/05/27 17:34:12.422] ScreenSaverInterfaceImpl::UnInhibit: cookie(8),
application(), reason(video-playing)
[2024/05/27 17:34:17.902] ScreenSaverInterfaceImpl::Inhibit: Reason:
video-playing
[2024/05/27 18:05:19.272] ScreenSaverInterfaceImpl::UnInhibit: cookie(9),
application(), reason(video-playing)
[2024/05/27 18:23:30.728] ScreenSaverInterfaceImpl::Inhibit: Reason:
video-playing
[2024/05/27 18:23:32.185] ScreenSaverInterfaceImpl::UnInhibit: cookie(10),
application(), reason(video-playing)
[2024/05/27 18:23:32.890] ScreenSaverInterfaceImpl::Inhibit: Reason:
video-playing
[2024/05/27 18:23:33.134] ScreenSaverInterfaceImpl::UnInhibit: cookie(11),
application(), reason(video-playing)
[2024/05/27 18:45:47.290] ScreenSaverInterfaceImpl::Inhibit: Reason:
video-playing
[2024/05/27 18:45:47.579] ScreenSaverInterfaceImpl::UnInhibit: cookie(12),
application(), reason(video-playing)
[2024/05/27 18:46:40.388] ScreenSaverInterfaceImpl::Inhibit: Reason:
video-playing
[2024/05/27 18:51:57.562] ScreenSaverInterfaceImpl::UnInhibit: cookie(13),
application(), reason(video-playing)
[2024/05/27 18:56:07.655] ScreenSaverInterfaceImpl::Inhibit: Reason:
video-playing
[2024/05/27 18:58:43.041] ScreenSaverInterfaceImpl::UnInhibit: cookie(14),
application(), reason(video-playing)
[2024/05/27 19:01:40.704] ScreenSaverInterfaceImpl::Inhibit: Reason:
video-playing
[2024/05/27 19:01:41.081] ScreenSaverInterfaceImpl::UnInhibit: cookie(15),
application(), reason(video-playing)
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
I'm feeling more frustrated than stupid, but I cannot figure out how to
request a new feature (or report a bug).
I have four proposed Kicker wallpapers to submit.
I logged into gitea, in the top left selected the 'Pull Requests' link,
in the left side selected TDE/tdebase.
I see a green New Pull Request button. I select the button and am
greeted with a message, "These branches are equal. There is no need to
create a pull request."
I have no idea or memory what to do next or if I am even on the right track.
Hi,
I have a bug to report concerning the Control Center, but I can't figure out
which Gitea repository it should go in. Help?
Leslie
-- Platform: Linux
Distribution: openSUSE Leap 15.4 (x86_64)
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.1.1
tde-config: 1.0
I would like to offer that with my efforts to build TDE on vintage
systems, I built TDE R14.1.2 on Slackware 14.2 64-bit (gcc 5.5.0) and
Slackware 14.1 32-bit (gcc 4.8.2). Both systems are EOL as of Dec. 2023.
I did not build every package but core dependencies and packages built
and run.
I had to find some patches to back port. For example, some patches
related to hotpluggable hwlib and ensuring '-std=c++11' is declared with
tqt3.
These days my brain is entrenched in old fart elderly territory and I
have my days exhibiting grumpy old man traits. I have been out of the
loop for many years with this kind of development and tend to lose
patience easily. That said, that I have built the latest TDE on vintage
systems is remarkable.
Dare I say that the 14.1 builds are running on Pentium I/II single core
systems with less than 512 MB of RAM and a 3.10.107 kernel? A tad slow?
Yes, but everything functions and the slowness is mostly caused by PATA
drives.
I am impressed with the developers far more than a grumpy old man being
able to build TDE on vintage systems. Good job devs. :)