[ghostwriter] [Bug 485691] Ghostwriter crashes on launch

[Duncan M]

https://bugs.kde.org/show_bug.cgi?id=485691

--- Comment #4 from Duncan M  ---
Created attachment 169517
  --> https://bugs.kde.org/attachment.cgi?id=169517=edit
coredumpctl info ghostwriter-24.02.2-1

-- 
You are receiving this mail because:
You are watching all bug changes.

[ghostwriter] [Bug 485691] Ghostwriter crashes on launch

[Duncan M]

https://bugs.kde.org/show_bug.cgi?id=485691

Duncan M  changed:

   What|Removed |Added

 CC||duncan_macl...@proton.me

--- Comment #3 from Duncan M  ---
Hello,

The same issue occurs for me as of last update.

App: Ghostwriter-24.02.2-1.fc40.x86_64 (I experience the same issue on
24.02.1-1 if that helps)
Distro: Fedora Linux 40 (up to date)
DE: Plasma 6.0.4-1.fc40
QT: 6.7.0-1.fc40
Kernel: Linux 6.8.9-300.fc40.x86_64
Video: Nvidia 550.78

The program closes with a segfault when launched from shortcut or command-line.
However, the Flatpak (Flathub) does not crash for me. I have attached my
coredump to provide what I can. Cheers.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-integration] [Bug 429403] Changing shortcut for "Move to Trash" breaks Delete key in text fields/editors

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=429403

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||1i5t5.dun...@cox.net

--- Comment #6 from Duncan <1i5t5.dun...@cox.net> ---
CCing.

THIS is why "delete" has very frustratingly not done text-delete for me for
ages (since kde3 era I believe, certainly it was broken in  kde/plasma5 and
remains broken on 6, but not sure about 4)!

Being an old-timer even the confirm-on-delete is a luxury and I just learned to
be careful, tho I still find delete-confirmation a useful luxury so enable it
where possible.  But trash?!  Bah-humbug!  It just gets in the way of actually
freeing the space I wanted free or I'd not be deleting the file in the first
place!

Unfortunately, kde/dolphin doesn't appear to allow actually disabling trash,
but it's set to the smallest possible size (0.01%, ~2MB on my 20 gig /home) 
and time (24 hours), warn-on-full, which means a warning (I've gotten one in
~20 years!) if I mistakenly trash instead of delete a file over 2MB,
(hopefully) delete with a llloonnggg latency of a 24 hours if it's under that. 
Meanwhile, the unused trash functionality shortcut is disabled, and delete is
configured to do what it says on the label -- delete (albeit with
confirmation).

Now I find out that having delete configured to actually do what it says on the
label (the key is NOT labeled "trash"!) for files is unintuitively killing the
other normal delete-key functionality, text-deletion! =:^(

At least now I can go digging in the source to see about changing the default
shortcuts so delete actually does what it says on the label without me having
to customize the shortcut, thus triggering this bug...

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kglobalaccel] [Bug 480304] Add support for second stroke shortcuts (feature request)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=480304

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||1i5t5.dun...@cox.net

--- Comment #9 from Duncan <1i5t5.dun...@cox.net> ---
TLDR summary: Brief kde multi-key global hotkeys history and current status,
discussion of available user workarounds.

FWIW this remains a long-term regression from the kde3 era where multi-key
hotkeys worked fine, including even a popup menu after the first one showing
configured second-key choices.  Only now it's worse, at least on wayland,
because unlike X where every app could see the keys entered (including
passwords!!) entered on any other app, thereby allowing third-party global
hotkey apps, that choice is gone on wayland (where apps other than the
compositor only see keys entered while they are in focus) due to its higher
security, so a standardized the third-party solution is out (but see option #3
below... and out at least until a wayland protocol extension is agreed that
makes it possible, the mechanism by which third-party screenshotting apps can
arrange for access to the visual contents of windows of other wayland apps, for
instance).

Available workarounds:

1) Stick to X and (continue to) use third-party X-based global hotkey
solutions.

Biggest downside is that X platform support is now second-class and gets less
testing, with the problem only getting worse as time progresses, but if you
already have other things keeping you on X and already have a third-party X
hotkey app setup, this should work reasonably for awhile, anyway.  But I'd
*not* recommend this to people who haven't setup such an app yet as the
timeframe it'll be viable is limited.

Upgrade path would presumably be thru #2, below.

2) On wayland, configure "Legacy X11 App Support" (plasma system settings >
security & privacy > application permissions) to "Allow legacy X11 apps to read
keystrokes in all apps" to "always".  Again, use a third-party X-based global
hotkeys solution.

This should continue to be supported much longer than #1 and is the likely
upgrade path thru which people on #1 will move.  As such it's much more viable.
 There's still a security tradeoff in that all X apps will be seeing your
wayland keys as well, but security-wise, it's not worse than the X we used for
decades, and is at least a step on the way, since wayland apps will at least
not see each others keys even if X apps still do.

The upgrade path from this will presumably be through #3, once a wayland
protocol extension is standardized to make third-party wayland hotkey apps more
viable.  Meanwhile, this is likely the simplest solution, even if it is someone
time-limited (but less than #1).

3) There is apparently at least one wayland third-party hotkey app, but I don't
remember the name ATM (egg-something maybe?) and due to wayland's security
which would normally break it, I believe it actually hooks into the input
stream below wayland (at the /dev/input/* device-file level), which likely
requires fiddling with device-file permissions.

I've not looked into it further but have been meaning to as in theory that
would have many of the same upsides as the #4 choice I took before I knew about
this one, with less of the major downside, complexity, tho there'd still be
some in getting the permissions correct and just learning its config.

Eventually, wayland/XDG will likely standardize a protocol extension to make
third-party global hotkey apps work without the degree of permission-changes,
etc, now necessary, and there will be more of these third-party wayland-based
apps, enough so as long as the compositor implements the extension, much like
the existing situation on X, users won't be locked into whatever the desktop
natively provides -- or fails to provide.  This is thus the eventual ideal
target.

4) Take advantage of the insight that multi-key can be seen as sequential keys,
not all of which must be processed by the same app-instance, to cobble together
a solution out of available components, with plasma only processing the initial
hotkey to launch the cobbled-together solution to handle the second and further
keys.

This is in fact what I did back when the regression first hit with kde4, and
what I still do today, altho I've changed the primary component I use since
then.  (I initially rolled my own bash script for the menu, but eventually
switched to pdmenu...)

Ideally, this would work like so: Configure a single plasma/kwin hotkey to
launch a third-party menu app, which would then see and process the second and
subsequent keys as it would then be the in-focus app.   If more than one
initial launcher keys are configured, each would conceptually launch the third
party app as if it were a submenu, since the choice of initial launching key
would effectively

[plasma-browser-integration] [Bug 478812] plasma-browser-integration e0a1a18cb bumps to 5.91.90, fails build against plasma-workspace f4129cf0f, still 5.91.0

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=478812

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Resolution|NOT A BUG   |FIXED

--- Comment #4 from Duncan <1i5t5.dun...@cox.net> ---
fanzhuyifan's notabug was in error.  It's now fixed by plasma-workspace
(despammed emails):

* commit 678b3dedb (HEAD, master)
| Author: Luca Beltrame 
| AuthorDate: Thu Dec 21 08:36:47 2023 +0100
| Commit: Luca Beltrame 
| CommitDate: Thu Dec 21 08:36:47 2023 +0100
|
| Put version to 5.91.90
|
| A bunch of other things looks for this version all around Plasma
| repositories
|
| If in error, please revert, but at least this allows building.
|
|  CMakeLists.txt | 2 +-
|  1 file changed, 1 insertion(+), 1 deletion(-)

Marking it as such.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeplasma-addons] [Bug 478807] kde-plasma-addons git-master build error against plasma5support git-master

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=478807

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Resolution|NOT A BUG   |FIXED

--- Comment #4 from Duncan <1i5t5.dun...@cox.net> ---
Seems I was correct filing it as a bug after all (and the resolved/notabug, not
my change, was wrong), fixed by plasma5support commit 8c9878917, which did
exactly what I did locally to work around it, bumping the version to 5.91.90.

So changing to the now correct resolved/fixed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-browser-integration] [Bug 478812] plasma-browser-integration e0a1a18cb bumps to 5.91.90, fails build against plasma-workspace f4129cf0f, still 5.91.0

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=478812

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Duncan from comment #1)
> Manually bumping plasma-workspace to 5.91.90 
... allows plasma-desktop (which failed to build as well) to build too.

Which would seem to make it a plasma-workspace failure-to-bump bug, not
plasma-browser-integration or plasma-desktop either one except that they got
bumped without first bumping the plasma-workspace dependency.  But I don't see
a plasma-workspace product to file against...

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-browser-integration] [Bug 478812] plasma-browser-integration e0a1a18cb bumps to 5.91.90, fails build against plasma-workspace f4129cf0f, still 5.91.0

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=478812

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||j...@jriddell.org

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
CCing jriddell for the version bump.

Manually bumping plasma-workspace to 5.91.90 (following the pattern of
8620a0aec ) and rebuilding allows plasma-browser-integration to build as well. 
(I don't know how to do a PR.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-browser-integration] [Bug 478812] New: plasma-browser-integration e0a1a18cb bumps to 5.91.90, fails build against plasma-workspace f4129cf0f, still 5.91.0

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=478812

Bug ID: 478812
   Summary: plasma-browser-integration e0a1a18cb bumps to 5.91.90,
fails build against plasma-workspace f4129cf0f, still
5.91.0
Classification: Plasma
   Product: plasma-browser-integration
   Version: unspecified
  Platform: Gentoo Packages
OS: Other
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: k...@privat.broulik.de
  Reporter: 1i5t5.dun...@cox.net
  Target Milestone: ---

CMake Error at CMakeLists.txt:47 (find_package):
Could not find a configuration file for package "LibTaskManager" that is
compatible with requested version "5.91.90".

The following configuration files were considered but not accepted:

/usr/lib64/cmake/LibTaskManager/LibTaskManagerConfig.cmake, version: 5.91.0
/lib64/cmake/LibTaskManager/LibTaskManagerConfig.cmake, version: 5.91.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeplasma-addons] [Bug 478807] kde-plasma-addons git-master build error against plasma5support git-master

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=478807

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
Manually bumping plasma5support to 5.91.90 (following the pattern of 22eb517de)
and rebuilding it does the trick.  But my git-foo is user/admin not dev side,
so I know not how to do PRs...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeplasma-addons] [Bug 478807] kde-plasma-addons git-master build error against plasma5support git-master

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=478807

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||j...@jriddell.org

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
CCing jriddell for release bumping.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeplasma-addons] [Bug 478807] New: kde-plasma-addons git-master build error against plasma5support git-master

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=478807

Bug ID: 478807
   Summary: kde-plasma-addons git-master build error against
plasma5support git-master
Classification: Plasma
   Product: kdeplasma-addons
   Version: git-master
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: General
  Assignee: plasma-b...@kde.org
  Reporter: 1i5t5.dun...@cox.net
  Target Milestone: ---

At kde-plasma-addons f29b44f0e against plasma5support 22eb517de attempting to
build kde-plasma-addons yields:

CMake Warning at /usr/share/ECM/find-modules/FindKF6.cmake:52 (find_package):
Could not find a configuration file for package "KF6Plasma5Support" that is
compatible with requested version "5.91.90".

The following configuration files were considered but not accepted:

/usr/lib64/cmake/KF6Plasma5Support/KF6Plasma5SupportConfig.cmake, version:
5.91.0
/lib64/cmake/KF6Plasma5Support/KF6Plasma5SupportConfig.cmake, version: 5.91.0


That kills the build,, and no wonder, since it's looking for 5.91.90
(kde-plasma-addons version as of  a9ec97b8b )  but plasma5support has only been
updated (in HEAD, 22eb517de) to 5.91.0 .

(Given the latest commits to both were less than 24 hours ago, I did a 24-hour
search before filing, turning up nothing apropos.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 448532] Dolphin crashed while copying files to external hard drive

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=448532

--- Comment #21 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Méven from comment #20)
> Git commit b1820506f20088fad311d68f41aa4e35853ad436
> 
> WidgetsAskUserActionHandler: fix backport

Indeed.  Builds fine now. =:^)  Thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 448532] Dolphin crashed while copying files to external hard drive

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=448532

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||1i5t5.dun...@cox.net
 Resolution|FIXED   |---

--- Comment #18 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Méven Car from comment #17)
> Git commit 6bea074739d5a75920d5540bc266549df5642511 by Méven Car, on behalf
> of Akseli Lahtinen.
> Committed on 15/12/2023 at 09:48.
> Pushed by meven into branch 'kf5'.
> 
> WidgetsAskUserActionHandler: Use QPointer to check the validity of parent
> widgets

This commit breaks a (kf5) kio rebuild (kf6 kio is fine at 25add040d, which
includes the parallel bdef648ed  from a couple weeks ago), at least on a hybrid
kf5/kf6 system updating from yesterday  using the gentoo/kde overlay.   Occurs
immediately after  [381/472] in the build process.  The errors are below. 
(5.239. is gentoo/kde's pseudo-version used for the kf5 frameworks live-git
slot.)

../kio-5.239./src/widgets/widgetsaskuseractionhandler.cpp: In member
function 'virtual void
KIO::WidgetsAskUserActionHandler::requestUserMessageBox(KIO::AskUserActionInterface::MessageDialogType,
const QString&, const QString&, const QString&, const QString&, const QString&,
const QString&, const QString&, const QString&, const KIO::MetaData&,
QWidget*)':
../kio-5.239./src/widgets/widgetsaskuseractionhandler.cpp:411:42: error:
'parentWidget' was not declared in this scope
411 | d->sslMessageBox(text, metaData, parentWidget);
|  ^~~~
../kio-5.239./src/widgets/widgetsaskuseractionhandler.cpp: In member
function 'void KIO::WidgetsAskUserActionHandlerPrivate::sslMessageBox(const
QString&, const KIO::MetaData&, QWidget*)':
../kio-5.239./src/widgets/widgetsaskuseractionhandler.cpp:491:29: error:
'd' was not declared in this scope
491 | QWidget *parentWidget = d->getParentWidget(parent);
| ^
ninja: subcommand failed

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 477099] New: Fullscreen games tearing with a thick black bar

[Duncan Vriend]

https://bugs.kde.org/show_bug.cgi?id=477099

Bug ID: 477099
   Summary: Fullscreen games tearing with a thick black bar
Classification: Plasma
   Product: kwin
   Version: 5.27.9
  Platform: Archlinux
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: wayland-generic
  Assignee: kwin-bugs-n...@kde.org
  Reporter: vrienddun...@gmail.com
  Target Milestone: ---

Created attachment 163217
  --> https://bugs.kde.org/attachment.cgi?id=163217=edit
Black bar screen tear

SUMMARY
When "allow tearing" is enabled, a tear during fullscreen gameplay shows up as
a big black bar, instead of 2 different frames being displayed by different
parts of the screen. (see attachment)


STEPS TO REPRODUCE
1. Display fullscreen game without V-sync
2. Let frame rate fall below monitors current refresh rate (set to 120Hz (it
can do 144Hz) in my case)

OBSERVED RESULT
A black bar appears where I'd expect a "screen tear" (happens frequently, is
annoying)

EXPECTED RESULT
The old frame is partially shown and the new frame is partially shown


SOFTWARE/OS VERSIONS
Linux: 6.6.1
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11

ADDITIONAL INFORMATION

GPU: GTX1060 6GB (proprietary NVIDIA drivers)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 431643] Aurorae decoration engine is inefficient

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=431643

--- Comment #8 from Duncan <1i5t5.dun...@cox.net> ---
With the first qt6-based plasma6 (I'm assuming they're calling it that) release
due in February, betas from December and possibly even an alpha in November
(unknown whether it's still on for then or early/late Nov but that's only ~4-6
weeks out!!), there's very little chance a fix will hit qt5-based plasma5,
particularly since the center-tile-focused efficiency fix discussed in comment
#4 and comment #5 may well break /some/ existing third-party aurorae-based
theme (even if as expected it's fine for ninety-some percent), and as an at
least theoretically breaking change, at this point it just doesn't make sense
to do it in 5.

But here's hoping they take the opportunity to do it for 6, since this would be
the time to do any breaking changes there and the efficiency boost should be
well worth it.  Maybe this new bug activity will get them on it (if they're not
already doing it that way in 6).

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 351175] "Auto-Hide" mode does not work when panel is on an edge between two screens

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=351175

--- Comment #60 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Nate Graham from comment #59)
> So to fix this in a way that makes sense, we would probably need to
> implement some kind of edge stickiness feature for screen edges between
> monitors that have hidden panels on them, as is proposed for Bug 416570. If
> we don't or can't do that, then there will remain no practical way to move
> the cursor onto the pixel that triggers the hidden panel [...]
> I think our path forward is to implement the feature requested at Bug 416570,
> and then make it always-on for edges between screens that have hidden
> panel on them.

I believe that's only partially correct... as described below:

Note that for at least some people CCed to this bug, their screen configuration
might look like this (ASCII-art best viewed with a monospace font or the spaces
will be too small horizontally and it won't align):

+--++
| not here>|  v |
|  ++
| >|< ^
+--+

In words, that's a higher resolution screen to the left, with a lower
resolution screen to the right and aligned at the top, leaving an undisplayed
square to the bottom right.

The paired arrows indicate edges that should be hard-stops for the pointer as
they're bordered by only a single screen, not between screens, making them easy
to hit (Fitt's law).

Or even (basically my setup when I reported):

++
| v >|< v
+++
  ^ >|< ^ |
 ++

That's two screens diagonal to each other so they only connect at a corner --
no actually shared borders so Fitt's law applies to all edges, only the corner
connecting them (which makes it easy to switch screens with the pointer, just
hit an edge that extends to the other screen and slide toward the other screen
until the pointer hits the shared corner and enters the other screen).

Regardless of what happens at the fully shared edges (like the not here edge of
the first one) where your observation applies and edge-stickiness would be
useful, there's no reason why the "internal edges" (as I called them in my bug)
that are not actually shared, so Fitt's law applies, can't have a working
autohide panel.  The bug I filed was that autohide is broken on them too -- hit
that stopping-edge then move away, and a panel on them set to auto-hide did
disappear momentarily  at the move-away (I'm not entirely sure this is still
the behavior as I have a different layout now, but I expect it is), but
immediately appeared again, so (except for that momentary hide and popout
again) autohide behaved as if the panel was set to permanently visible. =:^( 
But it's a stopping edge that only /extends/ to a different screen, it's not
actually a shared edge that the pointer cruises over and keeps going.  So
autohide really can and /should/ work, even without the sticky-shared-edge
feature described in comment #59.

So while the sticky-shared-edge idea is a rather ingenious solution (I wish I
had thought of) for actually shared edges,  for stopping-edges that only extend
to a different screen and aren't actually shared, sticky-shared-edge is not
critical to having a working autohide.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 465937] Split does not reset to its original value once "adjacent quick-tiled windows" configuration ceases to exist

[Duncan Calvert]

https://bugs.kde.org/show_bug.cgi?id=465937

--- Comment #25 from Duncan Calvert  ---
(In reply to jake gaisser from comment #23)
> This  may not be a solution for everyone, but just having a setting that
> always forces 50% for tiling would make me happy, then it would behave like
> it did previously.

+1 This would be great. I snap windows around constantly and always want them
to snap 50%. I often adjust the width afterwards and am usually okay with
windows overlapping some. It's a nice way to keep track of what's there while
getting the full view when focusing it.

Changes like this subvert the utility of so many of the concepts of a normal
windowing system. We shouldn't be forced into tiling.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 473524] Menu flashing on desktop context menu with fractional scaling

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=473524

--- Comment #2 from Duncan  ---
Screenshot of menu missing segments:
https://nextcloud.cricalix.net/index.php/s/bcZD6gXBHWAyegf

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 473524] Menu flashing on desktop context menu with fractional scaling

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=473524

--- Comment #1 from Duncan  ---
qdbus-qt5 org.kde.KWin /KWin supportInformation:
https://nextcloud.cricalix.net/index.php/s/bkj7fMBXz7SNtQ6

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 473524] New: Menu flashing on desktop context menu with fractional scaling

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=473524

Bug ID: 473524
   Summary: Menu flashing on desktop context menu with fractional
scaling
Classification: Plasma
   Product: kwin
   Version: 5.27.7
  Platform: openSUSE
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: wayland-generic
  Assignee: kwin-bugs-n...@kde.org
  Reporter: kde.b...@cricalix.net
  Target Milestone: ---

Created attachment 161054
  --> https://bugs.kde.org/attachment.cgi?id=161054=edit
Video showing menu issue

SUMMARY
Fractional scaling causes menu flashing/tearing as the mouse moves over the
menu entries. It's almost as if the menu is being raised over itself on
highlighted segment at a time.


STEPS TO REPRODUCE
1. Use Wayland
2. Use one 1440p monitor, one 2160p monitor
3. Set the 2160p to 150% scaling
4. Right-click on desktop, move cursor over menu

OBSERVED RESULT
See attached video for better description than I can provide with words.

When pressing Print Screen to open Spectacle to take a static image, the areas
the mouse has not moved over vanish, leaving holes in the menu (the windows
below it are shown).

EXPECTED RESULT
Behaviour like with no fractional scaling - no flashing, no holes in the menu
etcetera.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20230817
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.9-1-default (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2


ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 465937] Split does not reset to its original value once "adjacent quick-tiled windows" configuration ceases to exist

[Duncan Calvert]

https://bugs.kde.org/show_bug.cgi?id=465937

Duncan Calvert  changed:

   What|Removed |Added

 CC||accou...@calvertsoftware.co
   ||m

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 471173] git okular build cmake error at 9f498c7f5

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=471173

--- Comment #3 from Duncan <1i5t5.dun...@cox.net> ---
Downstream gentoo bug at https://bugs.gentoo.org/908740

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 471173] git okular build cmake error at 9f498c7f5

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=471173

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Duncan from comment #0)
> commit 9f498c7f5

>  Noting the named imageScalingTest target and
> assuming testing/CI has testing on suggests a likely testing-option-off
> logic error.

Confirmed that testing option logic error.  Setting USE=test (without
FEATURES=test it still doesn't actually run the tests) allows it to build.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 471173] git okular build cmake error at 9f498c7f5

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=471173

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||n...@kde.org,
   ||s...@vuorela.dk

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
CCing author/committer.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 471173] New: git okular build cmake error at 9f498c7f5

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=471173

Bug ID: 471173
   Summary: git okular build cmake error at 9f498c7f5
Classification: Applications
   Product: okular
   Version: unspecified
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: okular-de...@kde.org
  Reporter: 1i5t5.dun...@cox.net
  Target Milestone: ---

Okular  (and frameworks5/plasma/many-other-kde-apps) from git, using the
gentoo/kde project overlay live-git packages.  Currently reporting 23.07.70 but
bugzi's version selector has no git option nor 23.07.70, so unspecified it is.

Yesterday/today I updated to qt 5.15.10 and okular was on the triggered
reverse-deps-rebuild list.  At head 0c383d8cf it failed both the initially
triggered rebuild and further rebuild attempts after finishing the system
update and doing a full smart-live-rebuild (all packages with git updates
available, but for okular of course due to this bug).

A bisect points to culprit (emails despammed):
commit 9f498c7f5
Author: Sune Vuorela 
AuthorDate: Thu Apr 20 16:17:41 2023 +0200
Commit: Nate Graham 
CommitDate: Wed Jun 14 17:47:41 2023 +

Allow new signatures to have image backgrounds

The reported cmake error is:

CMake Error at generators/poppler/CMakeLists.txt:40
(target_compile_definitions):
Cannot specify compile definitions for target "imageScalingTest" which is
not built by this project.

Note that I have build-testing turned off (Portage's FEATURES=-test, the okular
package's USE=-test).  Noting the named imageScalingTest target and assuming
testing/CI has testing on suggests a likely testing-option-off logic error.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 470328] New: LSP Client: Kate's LSP parser does not support codeDescription from a server

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=470328

Bug ID: 470328
   Summary: LSP Client: Kate's LSP parser does not support
codeDescription from a server
Classification: Applications
   Product: kate
   Version: 22.12.3
  Platform: Ubuntu
OS: Linux
Status: REPORTED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: kwrite-bugs-n...@kde.org
  Reporter: kde.b...@cricalix.net
  Target Milestone: ---

SUMMARY
Kate's LSP handler
(https://github.com/KDE/kate/blob/master/addons/lspclient/lspclientserver.cpp#L829)
does not handle a returned codeDescription attribute of a Diagnostic.


STEPS TO REPRODUCE
1. Use a LSP that returns a codeDescription for a diagnostic
2. Trigger a diagnostic that includes that codeDescription attribute

OBSERVED RESULT
No rendering of a codeDescription entry in the JSON diagnostic

EXPECTED RESULT
Kate is able to render the `href` attribute of the codeDescription as part of
the diagnostic data, linking the user to documentation that explains the
diagnostic in detail.

SOFTWARE/OS VERSIONS
Operating System: Kubuntu 23.04
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106.0
Qt Version: 5.15.8
Kernel Version: 6.2.12-060212-generic (64-bit)
Graphics Platform: X11
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 31.2 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2

ADDITIONAL INFORMATION
Based on the linked source code, `relatedInformation` is processed, but this
attribute of a Diagnostic is for "these other document locations are affected".
I'm currently scratching an itch of having Meta's Pyre type checker integrated
as a plugin for `python-lsp-server`, but have run into the stumbling block that
Kate won't render a `codeDescription` attribute.

`codeDescription` was added in 2020 to the specification -
https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#diagnostic

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 468779] Fails to build without KActivities (wrong #if check)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=468779

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
Fixed with c3fb0dc15

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 468779] Fails to build without KActivities (wrong #if check)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=468779

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||1i5t5.dun...@cox.net

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
Created attachment 158576
  --> https://bugs.kde.org/attachment.cgi?id=158576=edit
#ifdef HAVE_KACTIVITIES -> #if HAVE_KACTIVITIES patch

Confirmed bisect to b99f6f50e.  Confirmed it builds with (gentoo)
USE=kactivites.  Here's the error without:

src/global.cpp:20:10: fatal error: KActivities/Consumer: No such file or
directory
20 | #include 

And a patch confirmed to fix it since I have it.  I'm not a dev and don't know
how to do PRs, but given cfeck's #IFDEF -> #IF hint and the commit, on gentoo a
patch was trivial to do and test, so I might as well post it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 469084] New: System Settings crashes on import of OpenVPN configuration file .ovpn

[Chris Duncan]

https://bugs.kde.org/show_bug.cgi?id=469084

Bug ID: 469084
   Summary: System Settings crashes on import of OpenVPN
configuration file .ovpn
Classification: Applications
   Product: systemsettings
   Version: 5.27.2
  Platform: Debian testing
OS: Linux
Status: REPORTED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: plasma-b...@kde.org
  Reporter: ch...@theduncans.us
  Target Milestone: ---

Application: systemsettings (5.27.2)

Qt Version: 5.15.8
Frameworks Version: 5.103.0
Operating System: Linux 6.1.0-7-amd64 x86_64
Windowing System: X11
Distribution: Debian GNU/Linux 12 (bookworm)
DrKonqi: 5.27.2 [KCrashBackend]

-- Information about the crash:
OpenVPN configuration file is from ExpressVPN. Successive attempts to import
the file crash every time. Separately installed packages openvpn and
network-manager-openvpn with no change.

The crash can be reproduced every time.

-- Backtrace:
Application: System Settings (systemsettings), signal: Segmentation fault

[KCrash Handler]
#4  0x7ffa6d03b6ae in OpenVpnUiPlugin::importConnectionSettings(QString
const&) () from
/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/network/vpn/plasmanetworkmanagement_openvpnui.so
#5  0x7ffa82083972 in ?? () from
/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/kcms/systemsettings_qwidgets/kcm_networkmanagement.so
#6  0x7ffac3ee8f7c in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7ffac1a6eb78 in QQmlVMEMetaObject::metaCall(QObject*,
QMetaObject::Call, int, void**) () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#8  0x7ffac1ac6c93 in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#9  0x7ffac19a3521 in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#10 0x7ffac19a53e0 in QV4::QObjectMethod::callInternal(QV4::Value const*,
QV4::Value const*, int) const () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#11 0x7ffac19c1cb6 in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#12 0x7ffac19c53df in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#13 0x7ffac1957c2e in QV4::Function::call(QV4::Value const*, QV4::Value
const*, int, QV4::ExecutionContext const*) () from
/lib/x86_64-linux-gnu/libQt5Qml.so.5
#14 0x7ffac1ae144d in QQmlJavaScriptExpression::evaluate(QV4::CallData*,
bool*) () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#15 0x7ffac1a92baf in QQmlBoundSignalExpression::evaluate(void**) () from
/lib/x86_64-linux-gnu/libQt5Qml.so.5
#16 0x7ffac1a942f8 in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#17 0x7ffac1ac677f in QQmlNotifier::emitNotify(QQmlNotifierEndpoint*,
void**) () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#18 0x7ffac3ee8a8d in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x7ffac1a6eb78 in QQmlVMEMetaObject::metaCall(QObject*,
QMetaObject::Call, int, void**) () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#20 0x7ffac1ac6c93 in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#21 0x7ffac19a3521 in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#22 0x7ffac19a53e0 in QV4::QObjectMethod::callInternal(QV4::Value const*,
QV4::Value const*, int) const () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#23 0x7ffac19c1cb6 in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#24 0x7ffac19c53df in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#25 0x7ffac1957c2e in QV4::Function::call(QV4::Value const*, QV4::Value
const*, int, QV4::ExecutionContext const*) () from
/lib/x86_64-linux-gnu/libQt5Qml.so.5
#26 0x7ffac1ae144d in QQmlJavaScriptExpression::evaluate(QV4::CallData*,
bool*) () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#27 0x7ffac1a92baf in QQmlBoundSignalExpression::evaluate(void**) () from
/lib/x86_64-linux-gnu/libQt5Qml.so.5
#28 0x7ffac1a942f8 in ?? () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#29 0x7ffac1ac677f in QQmlNotifier::emitNotify(QQmlNotifierEndpoint*,
void**) () from /lib/x86_64-linux-gnu/libQt5Qml.so.5
#30 0x7ffac3ee8a8d in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#31 0x7ffabf271221 in QQuickAbstractButtonPrivate::handleRelease(QPointF
const&) () from /lib/x86_64-linux-gnu/libQt5QuickTemplates2.so.5
#32 0x7ffabf290251 in QQuickControl::mouseReleaseEvent(QMouseEvent*) ()
from /lib/x86_64-linux-gnu/libQt5QuickTemplates2.so.5
#33 0x7ffac20550e8 in QQuickItem::event(QEvent*) () from
/lib/x86_64-linux-gnu/libQt5Quick.so.5
#34 0x7ffac4b62fae in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#35 0x7ffac3eb16f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /lib/x86_64-linux-gnu/libQt5Core.so.5
#36 0x7ffac20729da in
QQuickWindowPrivate::deliverMouseEvent(QQuickPointerMouseEvent*) () from
/lib/x86_64-linux-gnu/libQt5Quick.so.5
#37 0x7ffac20740dd in
QQuickWindowPrivate::deliverPointerEvent(QQuickPointerEvent*) () from

[plasmashell] [Bug 463356] Audio indicators are displayed for some flatpaks that aren't running audio

[Mark Duncan]

https://bugs.kde.org/show_bug.cgi?id=463356

Mark Duncan  changed:

   What|Removed |Added

Version|5.26.4  |5.27.2

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 466229] Spider segfaulting, new solver (417bdc2ec) bug?

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=466229

--- Comment #4 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Duncan from comment #3)
> I'll have to look up again how to build unstripped, with debugging enabled 

This is more like it.  (The - bit is gentoo's normal live-git package
version-numbering.)

Again, a bunch of new-thread/thread-exited per-move as the solver-thread starts
and exits, then...

[New Thread 0x7fffd9da96c0 (LWP 74954)]

Thread 159 "SolverThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd9da96c0 (LWP 74954)]
0x75ef3c0b in memmove () from /usr/lib64/libc.so.6
(gdb) bt
#0  0x75ef3c0b in memmove () from /usr/lib64/libc.so.6
#1  0x555c060e in memcpy (__len=, __src=0x7fffb80ce700,
__dest=0x7fffa4020ea8) at /include/bits/string_fortified.h:29
#2  Deck::update (this=this@entry=0x7fffa4020e28,
other=other@entry=0x7fffb80ce680) at
../kpat-/src/patsolve/spidersolver2.cpp:656
#3  0x555c169e in Deck::applyMove (this=this@entry=0x7fffb80ce680,
m=..., newdeck=...) at ../kpat-/src/patsolve/spidersolver2.cpp:677
#4  0x555c1bfd in Deck::shortestPath (this=,
cap=cap@entry=150) at ../kpat-/src/patsolve/spidersolver2.cpp:802
#5  0x555c1eaa in SpiderSolver2::patsolve (this=0x56e473f0,
max_positions=-1) at ../kpat-/src/patsolve/spidersolver2.cpp:941
#6  0x55586979 in SolverThread::run (this=0x55dddfe0) at
../kpat-/src/dealer.cpp:157
#7  0x764cb05f in ?? () from /usr/lib64/libQt5Core.so.5
#8  0x75ee042d in ?? () from /usr/lib64/libc.so.6
#9  0x75f5943c in ?? () from /usr/lib64/libc.so.6
(gdb)

glibc-2.36-r7 (r7 being the gentoo package revision), gcc-12.2.1_p20230121-r1,
qtcore-5.15.8-r3.

For the debug I built kpat with C(XX)FLAGS="-ggdb -Og", which I'll leave in
place for the moment in case you need something beyond the simple bt.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 466229] Spider segfaulting, new solver (417bdc2ec) bug?

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=466229

--- Comment #3 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Stephan Kulow from comment #2)
> Hi, can you export KDE_DEBUG=1 before starting it from console? Then
> something useful should appear in coredumpctl (typing from memory as I'm not
> having a computer around).

Kernel CONFIG_COREDUMP=n, so coredumpctl never gets the cores from the kernel. 
I could change that if necessary (tho would rather not deal with figuring out
all that config), but what about running via gdb instead?

Meanwhile , dmesg does say SolverThread  SIGSEGV ... error 6 in kpat ...

Currently the gdb likely isn't much help due to stripped binaries, but here's
what I get ATM...

A bunch of New Thread ... Thread exited pairs, apparently one per move, I guess
for the solver threads.  Then at the SIGSEGV...

[New Thread 0x7fffd99fc6c0 (LWP 13533)]

Thread 381 "SolverThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd99fc6c0 (LWP 13533)]
0x555d762e in ?? ()
(gdb) bt
#0  0x555d762e in ?? ()
#1  0x555d8546 in ?? ()
#2  0x555d9726 in ?? ()
#3  0x555da057 in ?? ()
#4  0x5558eab7 in ?? ()
#5  0x764cb05f in ?? () from /usr/lib64/libQt5Core.so.5
#6  0x75ee042d in ?? () from /usr/lib64/libc.so.6
#7  0x75f5943c in ?? () from /usr/lib64/libc.so.6
(gdb)

I'll have to look up again how to build unstripped, with debugging enabled 
(IIRC gentoo/kde has a guide I'll need to reread, I've done it once before for
something and it wasn't difficult) to fill in the ??s.  Hopefully this
weekend...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 466229] Spider segfaulting, new solver (417bdc2ec) bug?

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=466229

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
Bisecting confirms it's the new solver.  417bdc2ec (the new solver) bad. 
3c581787e (the commit previous to that) seems to be fine. (Well, at least it
played a full round without segfaulting, tho as I mentioned above that did
happen -- once -- with the bad code, too.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kpat] [Bug 466229] New: Spider segfaulting, new solver (417bdc2ec) bug?

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=466229

Bug ID: 466229
   Summary: Spider segfaulting, new solver (417bdc2ec) bug?
Classification: Applications
   Product: kpat
   Version: unspecified
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: crash
  Priority: NOR
 Component: solver
  Assignee: co...@kde.org
  Reporter: 1i5t5.dun...@cox.net
CC: kde-games-b...@kde.org
  Target Milestone: ---

Live-git version updated yesterday (Feb 20, 2023), using the gentoo/kde project
overlay's live-git packages, reported as 23.03.70 (both unlisted so I can't set
that version above), with live-git frameworks-5 as well.  Qt is 5.15.8 (current
as of yesterday with gentoo's regular sub-version update patchsets) .

Spider has started segfaulting on me recently (the other kpat games I play
regularly, klondike and freecell, are fine), with several weeks of further
updates not fixing it yet.  The timing and spider-specificness suggest it's due
to a race or nul-deref in the new solver, tho I'm filing this with the info I
have before bisecting to confirm that.

Maybe happenstance, but at first it /seemed/ to happen nearly immediately after
starting a spider round, often on (before ?) the first move, but something
(maybe just another rebuild, or an update of libkdegames, some framework, or
qt5, as I see no further kpat code changes gitlogged, only l10n/appstream)
seems to have decreased the frequency of the issue since and I can often get in
a number of moves now before the segfault.  Once I was even able to finish a
round and I hoped for a moment the problem was fixed, but it segfaulted on the
second round.

The output when started from konsole is unhelpful; an initial complaint from
QFont::setPixelSize that appears unrelated as it happens well before the
segfault, then nothing as I play until the segfault:

QFont::setPixelSize: Pixel size <= 0 (0)
Segmentation fault


For reference here's the suspect commit (email addresses despammed for
posting):

* commit 417bdc2ec
| Author: Stephan Kulow 
| AuthorDate: Fri Jan 20 10:51:07 2023 +0100
| Commit: Albert Astals Cid 
| CommitDate: Sun Jan 22 22:33:51 2023 +
|
| Replace spider solver with a self serving solution
|
| This is something I had lying around (don't ask). It's generally
| slower (as it tries harder to find an optimal solution), but finds
| solutions more reliably - and is possibly easier to debug for
| other people :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 466126] Issues with panel autohide on specific monitor setup

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=466126

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||1i5t5.dun...@cox.net
 Status|REPORTED|RESOLVED

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
This is almost certainly a duplicate of bug #351175.   Marking it as such. 
However, I'm just another user with another dupe, not a dev, so if you think
it's not a dupe, feel free to reverse that and explain the difference.

Briefly, the problem is with "internal" borders/edges (aka "struts") between
monitors.  As long as the panel is on a true edge of the bounding rectangle
things are fine, but put it on a strut that's "internal", not on the bounding
rectangle edge, and the autohide does the immediate re-popup thing exactly as
you describe.

Unfortunately fixing this bug doesn't appear to be a priority, despite the
number of dupes and thus users obviously affected.

Two known workarounds:

1) Change your layout and/or panel position to avoid placing panels on such
"internal" struts.

(This one's obvious once the problem is understood. For me, it was the excuse I
needed to upgrade my older FullHD monitor to a second 4K so they'd match sizes
and I'd have no need to place a panel on the previously partial seam between
them.)

2) It has been reported that separating the monitors in the kscreen layout so
they don't logically touch eliminates the issue as it fools the logic into
thinking all the edges are external, while still allowing the pointer to move
between screens (which I thought would be broken, but apparently not).

IMO that's quite clever and I really wish I had thought to try it before
throwing money at the problem (but of course that would have done away with my
excuse to upgrade =:^)

*** This bug has been marked as a duplicate of bug 351175 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 351175] Panel on screen edge between two monitors does not auto hide

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=351175

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||fre...@bananateam.nl

--- Comment #49 from Duncan <1i5t5.dun...@cox.net> ---
*** Bug 466126 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 462660] kwin commit a6a022f00 breaks build: src/group.cpp:11:10 KX11Extras: No such file or directory

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=462660

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Resolution|NOT A BUG   |FIXED

--- Comment #4 from Duncan <1i5t5.dun...@cox.net> ---
Thanks.  Was just figuring that out and mid-air-ed.  (Gentoo did a qt5 update
which forced a kwin rebuild, among others, without doing the preliminaries.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 462660] kwin commit a6a022f00 breaks build: src/group.cpp:11:10 KX11Extras: No such file or directory

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=462660

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
Double-confirmed, both by building the previous commit and not being able to
build that one, and by applying the reversing patch at current head 1a97d384f.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 462660] kwin commit a6a022f00 breaks build: src/group.cpp:11:10 KX11Extras: No such file or directory

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=462660

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||nicolas.fe...@gmx.de,
   ||vlad.zahorod...@kde.org

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
CCing commit author and committer

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 462660] New: kwin commit a6a022f00 breaks build: src/group.cpp:11:10 KX11Extras: No such file or directory

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=462660

Bug ID: 462660
   Summary: kwin commit a6a022f00 breaks build:
src/group.cpp:11:10 KX11Extras: No such file or
directory
Classification: Plasma
   Product: kwin
   Version: git master
  Platform: Other
OS: Other
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: core
  Assignee: kwin-bugs-n...@kde.org
  Reporter: 1i5t5.dun...@cox.net
  Target Milestone: ---

On git master using gentoo/kde's live-git ebuilds. 

commit a6a022f00
Author: Nicolas Fella [snipped email]
AuthorDate: Thu Dec 1 02:15:26 2022 +0100
Commit: Vlad Zahorodnii [snipped email
CommitDate: Thu Dec 1 08:08:54 2022 +

Port away from deprecated KWindowSystem API

... breaks the build with #Include  on line 18.

Additional information:  I no longer have an independent X/xorg installed, only
xwayland, and am gradually reducing the number of installed X-related
dependencies as they become optional (USE=-X in gentoo-speak).  Presumably
KX11Extras is a (previously) optional X-related component that I have turned
off.  Preferably it'd be optional here too, but regardless, there's apparently
no cmake find for it here or I'd be getting that error instead of the build
error:

FAILED: src/CMakeFiles/kwin.dir/group.cpp.o
...
src/group.cpp:18:10: fatal error: KX11Extras: No such file or directory
18 | #include 
 |  ^~~~
compilation terminated.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 413645] Can't remember desktop widget positions after reboot

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=413645

--- Comment #44 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Aaron Rainbolt from comment #42)
> [T]he problem might actually be the
> result of a resolution change during early startup

Yes.  In my (different resolution dual-monitor) case the problem was definitely
the resolution switch, in that case on the high resolution monitor (actually a
4K TV), switching from the resolution of the low-resolution monitor (a Full-HD
TV).  What was happening is that all the widgets on the high-res monitor were
moved to fit within the confines of the low-res monitor, thus all repositioning
in the top-left quadrant of the high-res monitor.  It was pretty obvious --
once I noticed it. =:^\

The problem went away when I switched to both 4K monitors so there wasn't a
resolution-switch.  Before that I worked around it by setting the rc-file
read-only (so the bad startup wouldn't overwrite the good config) and setting
up a start-up script that slept for a few seconds then did a plasmashell
restart, basically doing via user script exactly what you suggested, waiting
until after the resolutions settled in before (re)starting plasmashell.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 413645] Can't remember desktop widget positions after reboot

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=413645

--- Comment #35 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Aaron Rainbolt from comment #34)
> I can also resolve the problem by entirely removing the "ItemGeometries"
> line and leaving the "ItemGeometriesHorizontal" line. However, again, this
> line is recreated at login, and if left at logout, the widget will again
> "wander" and then snap. So something about the two entries coexisting is
> causing things to go wrong.

Those floating-point values look suspect.  Does manually setting them to
integer values (767 and 688) help?  If not or if it doesn't stick, try the
following...

This bug has been around awhile, but there was a workaround I initially
described in https://bugs.kde.org/show_bug.cgi?id=389141 that (with a bit of
updating) presumably still works (see below):

With the plasmoids in the desired location (either with the ItemGeometries
lines deleted or with them set as desired, not sure which), set
plasma-org.kde.plasma.desktop-appletsrc (normally found in ~/.config unless you
set $XDG_CONFIG_HOME) read-only.   This should prevent it from being
overwritten with the bad config but unfortunately you'll still need to manually
restart the initially started mixed-up plasmashell (plasmashell --replace,
unfortunately at each login, tho it can be scripted as described below) in
ordered to get it to take, since that initial start is what goes haywire.

You can try the --replace from krunner.  If that works as I expect it will,
automate it with a script set to autostart (see the autostart
kcontrol/systemsettings module), with a few seconds sleep to let the system
stabilize before the --replace command.

Of course with the desktop-appletsrc file set readonly reconfiguring things
will work only for that plasmshell session so you'll have to remember to toggle
it back read-writable if you want to reconfigure...

(I believe the bug trigger here was a multi-monitor setup with different
resolutions for each monitor, one full-HD one 4K.  When I upgraded to
matching-resolution 4Ks it stopped triggering for me so I've not seen the bug
in awhile.  Thus the "presumably still works" qualification above.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 458775] File type detection fails on reload after external change

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=458775

--- Comment #1 from Duncan  ---
Created attachment 151860
  --> https://bugs.kde.org/attachment.cgi?id=151860=edit
Screen capture of issue

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 458775] New: File type detection fails on reload after external change

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=458775

Bug ID: 458775
   Summary: File type detection fails on reload after external
change
   Product: kate
   Version: 22.04.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: application
  Assignee: kwrite-bugs-n...@kde.org
  Reporter: kde.b...@cricalix.net
  Target Milestone: ---

SUMMARY
Mutating a file outside of Kate causes Kate to offer a reload option. Taking
that option will result in Kate "forgetting" that the file is of a particular
type (Python in my case), and disables type-specific behaviours like syntax
highlighting and LSP usage.

STEPS TO REPRODUCE
1. Install pylsp
2. Install black, flake8 plugins for pylsp
3. Edit a python file with Kate - ensure the file type is detected as Python,
with syntax highlighting etc
4. Save the file with content that black will fix (extra long lines or
whatever)
5. Mutate the file outside of Kate with black 
6. Back to Kate, accept the reload of the file

OBSERVED RESULT

Syntax highlighting and LSP support stop working; Kate appears to treat the
file as text/plain, not Python. Detected language in the bottom right is still
Python.

Clicking the detected language, and then clicking the already-ticked Python
causes Kate to re-apply syntax highlighting and LSP support for Python.

EXPECTED RESULT

Upon reload, Kate considers the file to be Python still, with syntax
highlighting and LSP support.

SOFTWARE/OS VERSIONS
Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.6
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.3
Kernel Version: 5.15.0-47-generic (64-bit)
Graphics Platform: X11
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457951

--- Comment #13 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Duncan from comment #12)
> What makes kpat's Egyptian different so it won't take it?

User mistake.  I didn't read the tabs and was changing card decks instead of
game themes, not realizing they were separate.  Once I changed game theme to
Egyptian as well, it took.  I'm not entirely sure whether the card deck was
changing to Egyptian all the time and I didn't notice it as I was staring at
the (to me[1]) blinding green-blaze background, or whether it only took once I
changed the game theme to Egyptian as well, but in any case, I can say the card
deck Egyptian did take once I set the game theme Egyptian.

But we're still left with the fact that the patch breaks the existing kpatrc
theme choice, tho not as badly as ksudoku's breakage, as kpat does at least
revert to a usable default instead of blanking.   Both honor resetting the
theme, but kpat's breakage is less as it reverts to a usable (if personally
uncomfortable) default instead of breaking game play.

---
[1] I wear rigid gas-perm contacts with a rather high nearsightedness
correction of ~ -10 diopters.  The combination of  the strongly negative
correction and rigid lenses means too bright backgrounds star-flare-reflect in
the contacts and eventually give me a headache as my eyes and brain try to
compensate and see around/through the flare-reflections.   It took me years to
figure out, but that's why I strongly prefer a "reversed" light-on-dark
color-scheme as at least then the flares are smaller than when the entire
background is bright.  The brown-sand Egyptian background is perfect for that,
plus I visited and find the idea of the theme rather pleasing as well!

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457951

--- Comment #12 from Duncan <1i5t5.dun...@cox.net> ---
Yikes!  The patch breaks kpat's Egyptian theme (at least with my existing
kpatrc).  In the kpat case, however, it *does* revert to something else
(default?) instead of blanking, as I proposed for ksudoku.  However, unlike
ksudoku, I can't reset it to Egyptian -- it simply doesn't take -- tho I *can*
set at least some other themes and they will take.  

It took all I tried (several, it ships way more than the three ksudoku ships)
/except/ Egyptian.  Which is weird, as again, I've not HNS-ed additional themes
so they're all as-shipped.  What makes kpat's Egyptian different so it won't
take it?

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457951

--- Comment #11 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Duncan from comment #10)
> [H]ow difficult would it be to code up a "this entry
> doesn't make sense, ignore it and use/rewrite the default" solution?

... maybe with a warning, to STDERR, notification or dialog depending on
evaluated priority of the user actually seeing it, saying the existing entry
was corrupted (or whatever better wording) so it reverted to default.

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457951

--- Comment #10 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Friedrich W. H. Kossebau from comment #9)
> https://invent.kde.org/games/libkdegames/-/merge_requests/20.diff

Good and bad news:
Good:   The relative style ksudokurc theme entry works with that patch.
Bad: The full-path style does not.

If there hasn't been a release with the now-existing code that creates the
full-path entry I imagine the bad news can be ignored (unless we want to give
people hand-editing their ksudokurc files the choice of doing full paths, too).

If there has been a release, the question is do we want to cover both styles
and thus cover the short-period code that additionally only writes the full
path for symlinked paths, or are we willing to sacrifice the narrow segment who
both ran the new release and have in-path symlinks, most of who likely were
upgrades already and thus had to do the blow-away/hand-edit process once
already in ordered to get that full path entry in the first place?

Alternatively or as well, how difficult would it be to code up a "this entry
doesn't make sense, ignore it and use/rewrite the default" solution?  I'd
personally prefer that, as then the worst-case (triggered by say a fully
corrupted entry or one pointed at a missing theme) would be losing the
configured theme and resetting to default, instead of showing blank/broken
game-play areas thus breaking the games in question.

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457951

--- Comment #8 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Friedrich W. H. Kossebau from comment #6)
> Please try the attached patch for libkdegames
> Interesting will be all the log output starting with "THEMELOADING"

For clarity this is at libkdegames c5848c0d6 and $HOME=/h/x (with
$XDG_CONFIG_HOME=$HOME/config), but having visited Egypt I /really/ like that
theme and I haven't felt the need to HNS any themes, so (/usr)/share/ksudoku is
the only location with any.

THEMELOADING considering locations ("/h/x/config/share/ksudoku",
"/usr/local/share/ksudoku", "/usr/share/ksudoku")
THEMELOADING considering desktop file
"/usr/share/ksudoku/themes/abstraction.desktop"
THEMELOADING canonical path "/share/ksudoku/themes/abstraction.desktop"
THEMELOADING id "/usr/share/ksudoku/themes/abstraction.desktop"
THEMELOADING considering desktop file
"/usr/share/ksudoku/themes/default.desktop"
THEMELOADING canonical path "/share/ksudoku/themes/default.desktop"
THEMELOADING id "/usr/share/ksudoku/themes/default.desktop"
THEMELOADING considering desktop file
"/usr/share/ksudoku/themes/ksudoku_scrible.desktop"
THEMELOADING canonical path "/share/ksudoku/themes/ksudoku_scrible.desktop"
THEMELOADING id "/usr/share/ksudoku/themes/ksudoku_scrible.desktop"

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457951

--- Comment #4 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Friedrich W. H. Kossebau from comment #3)
> Then it generates the theme id by first turning the desktop file path
> to a canonical version 

That rings a bell.  My system has a reverse-usrmerge, /usr -> .  so everything
installed to /usr ends up in /.  Up to probably about a year ago that was
causing a problem with canonical/non-canonical path comparisons against the
*.desktop file path that was supposed to give plasmashell the special privs it
needs from kwin to get the wayland running tasks info (not a problem with
insecure X), so none of the taskmanager plasmoids could actually see running
tasks and all they were showing were the pinned launchers.  That problem turned
out to be in whatever framework was doing the resolution, fixed when someone
traced down an apparently unrelated instance of the same bug, and as soon as I
saw the git log I knew what was going on with my bug and that it was probably
fixed with that commit, which it was.

> Are you capable to add some fprint debug lines to libkdegames yourself to
> get insight into the respective values used there?

Give me a debug/test patch and I can apply it for local testing, no sweat, but
coding it is another story... (Effectively I can and sometimes do hack existing
patches when necessary, but I'm not a dev so coding my own, even for trivial
debugging like this, if possible at all, typically takes me hours of bumbling.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457951

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||kosse...@kde.org

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
CCing kossebau@ as the author/committer of the culprit commit.

-- 
You are receiving this mail because:
You are watching all bug changes.

[ksudoku] [Bug 457951] New: ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457951

Bug ID: 457951
   Summary: ksudoku commit 6e9d941ce with an existing theme config
results in a blank play-space and qpainter engine
errors
   Product: ksudoku
   Version: unspecified
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: iandw...@gmail.com
  Reporter: 1i5t5.dun...@cox.net
CC: kde-games-b...@kde.org
  Target Milestone: ---

On git-master (for frameworks/plasma/gear all three) using the gentoo/kde
project overlay live-git ebuilds.  Current ksudoku HEAD 64ec262ee

For a couple months ksudoku would run, but attempting to actually play a game
resulted in a blank play-space, with the number-selector space blank as well.

Running from konsole gave me this pair of errors, twice at the select game
screen (which seemed to work), many many times when starting a game and getting
the blank play-space:

QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::end: Painter not active, aborted

I finally had some time to bisect it tonight, with the culprit being (emails
masked):

commit 6e9d941ce
Author: Friedrich W. H. Kossebau 
AuthorDate: Sun Jun 19 19:40:16 2022 +0200
Commit: Friedrich W. H. Kossebau 
CommitDate: Sun Jun 19 19:40:16 2022 +0200

Port away from deprecated KGameTheme & KGameThemeSelector


Given that clue I rebuilt at HEAD, then tried reconfiguring my theme, and sure
enough, ksudoku gave me a proper play-space (and no qpainter errors in konsole)
once again. =:^)


So then I wondered what in the ksudokurc file it had been choking on.  A diff
against a backup revealed this in the [Themes] section:

Old:
theme=themes/default.desktop

New:
theme=/usr/share/ksudoku/themes/default.desktop

So the code in the above commit does absolute paths while the old code
apparently saved the path relative to the system theme location, and the new
code doesn't know how to interpret that, resulting in a null theme, in turn
resulting in the null/0 qpainter engine error above.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457573] kwin git master can't find GlobalAccelPrivate (at HEAD or the same commit 84e5d92f6 that built fine on Aug 1)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457573

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Resolution|--- |NOT A BUG
 Status|REPORTED|RESOLVED

--- Comment #4 from Duncan <1i5t5.dun...@cox.net> ---
Found it!  And I was wrong about it being a cmake bug.

Turns out it was gentoo adding back the X USE flag, based on upstream
kglobalaccel 7d6ef389d: Add BUILD_RUNTIME option.

Since I'm wayland-only now I tried turning it off... and promptly FORGOT ABOUT
IT!  Big mistake, at least the forgetting!  Apparently that turns off the
GlobalAccelPrivate stuff that kwin still requires (for xwayland?).  I gotta
remember when I test new things so as to toggle them back if they don't work!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457573] kwin git master can't find GlobalAccelPrivate (at HEAD or the same commit 84e5d92f6 that built fine on Aug 1)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457573

--- Comment #3 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Duncan from comment #2)
> So what provided libKF5GlobalAccelPrivate.so.5 and why does it no longer
> provide it?

rpmfind suggests that I was correct -- it should be kglobalaccel (on gentoo
which apparently unlike rpm-based-distros combines the lib-files into their
primary namesake package).

So why isn't it building it?  I still suspect it's a cmake-3.24.0 bug,
apparently with something cached so a straight downgrade to cmake-3.23.x and
retry doesn't fix it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457573] kwin git master can't find GlobalAccelPrivate (at HEAD or the same commit 84e5d92f6 that built fine on Aug 1)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457573

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Duncan from comment #1)
> cmake-3.23.3  -> cmake-3.24.0

... And 3.23.2 -> 3.23.3 was Aug 1.

But downgrading to either one doesn't seem to help. =:^(  I even tried
rebuilding kglobalaccel after downgrading.  Still no luck.


Tackling another angle, attempting to reinstall the existing kwin package
binary gives me this error concerning a missing library:

emerge: there are no binary packages to satisfy "x86_64:
libKF5GlobalAccelPrivate.so.5".
(dependency required by "kde-plasma/kwin-::kde" [binary])
(dependency required by "kwin" [argument])

So what provided libKF5GlobalAccelPrivate.so.5 and why does it no longer
provide it?  I regressed the obvious kglobalaccel back to the 5.97.0 bump
commit (118e262bd on July 9, well before my last successful kwin build on Aug
1), and it doesn't seem to provide it.  But /something/ obviously did on Aug 1
when I last successfully built kwin.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457573] kwin git master can't find GlobalAccelPrivate (at HEAD or the same commit 84e5d92f6 that built fine on Aug 1)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457573

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
Hmm... System upgrade before the live-package upgrade included:

cmake-3.23.3  -> cmake-3.24.0

I've not tried downgrading back to 3.23.3 yet, but that looks related and fits
the not-kwin-and-not-kglobalaccel but some other dep requirements.  I wonder
what cmake-3.24 changed?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457573] New: kwin git master can't find GlobalAccelPrivate (at HEAD or the same commit 84e5d92f6 that built fine on Aug 1)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457573

Bug ID: 457573
   Summary: kwin git master can't find GlobalAccelPrivate (at HEAD
or the same commit 84e5d92f6 that built fine on Aug 1)
   Product: kwin
   Version: git master
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kwin-bugs-n...@kde.org
  Reporter: 1i5t5.dun...@cox.net
  Target Milestone: ---

Git master kwin/plasma/frameworks using the gentoo/kde overlay live-git
ebuilds.  Last successful kwin update was August 1, to 84e5d92f6, but
attempting to rebuild it results in the same error as HEAD (currently
ed829eb5a), and a revdep-rebuild now detects that existing kwin as missing
libraries so I'm afraid to reboot or restart plasma/kwin as there's a big
chance I won't be able to get back into plasma.

The build error is at the end of the configure phase, and relates to a missing
KF5::GlobalAccelPrivate (despite kglobalaccel being detected and presumably
GlobalAccel being fine, and the last kglobalaccel commit being 5683e036e back
on Jul 21, well before my successful kwin build on Aug 1, to the same kwin
commit 84e5d92f6 that now fails).

So the culprit doesn't seem to be in either kwin or kglobalaccel, despite the
below error.  What else could have caused kwin not to see GlobalAccelPrivate?

I'm including the full features summary below:

...
-- Found KF5GlobalAccel:
/usr/lib64/cmake/KF5GlobalAccel/KF5GlobalAccelConfig.cmake (found version
"5.97.0")
...

-- The following features have been enabled:

* KF5Activities (required version >= 5.97), Enable building of KWin with
kactivities support
Enable building of KWin with kactivities support
* KF5DocTools (required version >= 5.97), Enable building documentation
Enable building documentation
* KF5Runner (required version >= 5.97), Enable building of KWin with krunner
support
Enable building of KWin with krunner support
* Breeze-Decoration, Default decoration plugin Breeze
* Wayland::EGL, Enable building of Wayland backend.
* Libxcvt, Required for generating modes in the drm backend
* XInput, Required for poll-free mouse cursor updates
* XCB-ICCCM, Required for building test applications for KWin
* SCHED_RESET_ON_FORK, Required for running kwin_wayland with real-time
scheduling
* Python3, Required to strip effects metadata

-- The following RUNTIME packages have been found:

* KF5Kirigami2 (required version >= 5.97), A QtQuick based components set
Required at runtime for Virtual desktop KCM
* EGL, A platform-agnostic mechanism for creating rendering surfaces for use
with other graphics libraries, such as OpenGL|ES and OpenVG.,

Required to build KWin with EGL support
* Xwayland, Xwayland X server, 
Needed for running kwin_wayland
* hwdata, 
Runtime-only dependency needed for mapping monitor hardware vendor IDs to full
names
* QtQuick-QMLModule, QML module 'QtQuick' is a runtime dependency.
* QtQuick.Controls-QMLModule, QML module 'QtQuick.Controls' is a runtime
dependency.
* QtQuick.Layouts-QMLModule, QML module 'QtQuick.Layouts' is a runtime
dependency.
* QtQuick.Window-QMLModule, QML module 'QtQuick.Window' is a runtime
dependency.
* QtMultimedia-QMLModule, QML module 'QtMultimedia' is a runtime dependency.
* org.kde.kquickcontrolsaddons-QMLModule, QML module
'org.kde.kquickcontrolsaddons' is a runtime dependency.
* org.kde.plasma.core-QMLModule, QML module 'org.kde.plasma.core' is a runtime
dependency.
* org.kde.plasma.components-QMLModule, QML module 'org.kde.plasma.components'
is a runtime dependency.

-- The following OPTIONAL packages have been found:

* KF5Attica (required version >= 5.96.0)
* KF5NewStuffCore (required version >= 5.97.0)
* KF5NewStuffQuick (required version >= 5.97.0)
* KF5Codecs (required version >= 5.96.0)
* KF5Activities (required version >= 5.97), Enable building of KWin with
kactivities support
Enable building of KWin with kactivities support
* KF5DocTools (required version >= 5.97), Enable building documentation
Enable building documentation
* KF5Runner (required version >= 5.97), Enable building of KWin with krunner
support
Enable building of KWin with krunner support
* Breeze (required version >= 5.9.0)
For setting the default window decoration plugin
* X11_XCB, A compatibility library for code that translates Xlib API calls into
XCB calls, 
Required for building X11 windowed backend of kwin_wayland
* PkgConfig
* Python3, Required to strip effects metadata

-- The following REQUIRED packages have been found:

* ECM (required version >= 5.97)
* Qt5Concurrent
* Qt5Qml (required version >= 5.15.5)
* Qt5QmlModels (required version >= 5.15.5)
* Qt5UiTools
* Qt5X11Extras
* Qt5XkbCommonSupport
* KF5Crash (required version >= 5.97)
* KF5DBusAddons (required version >= 5.97)

[kwin] [Bug 457516] Firefox locks up with kwin_wayland spiking in CPU when repeatedly right-clicking on extension popups

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457516

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||1i5t5.dun...@cox.net

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
I had seen this too (on gentoo, running all frameworks/plasma git-master using
the gentoo/kde overlay live-git ebuilds, and also on wayland), but had chalked
it up to forcing on some additional firefox gfx accel using about:config
(running amdgpu driver with an old AMD Radeon Polaris-11 rx460 on an
approximately decade old AMD fx6100  that has trouble with firefox/youtube 4k60
videos, 4k50's generally fine, so it needs all the accel help it can get).

Nate G: Per chance AMD gfx also (as me and original reporter), or Intel/nVidia
thus confirming cross-gfx?  I know firefox at least was disabling certain gfx
accel on kde/kwin_wayland on amdgpu, thus my trying to force it on, but am not
sure what their current status is.  Anyway, could be related to that, if you're
AMD gfx too.  If not it's gotta be unrelated to the previous
firefox/amdgpu/kwin_wayland bugs.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457487] After fixing the shaded/shuttered window feature, restarting kwin_x11 --replace forgets the shaded window sizes

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457487

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||1i5t5.dun...@cox.net

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
Given the mention of minimum window size...

Does setting a minimum-size window rule (perhaps a generic one if you use shade
enough, below more specific rules so it will only apply to windows without a
rule already setting minimum size, tho I'd suggest matching only normal window
type to avoid interfering with special windows), forcing minimum-size to say
800x1 or some such, help, as a workaround until this is fixed?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457152] kwin commit 6576a83ae breaks build: missing QApplication

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457152

--- Comment #6 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Duncan from comment #5)
> (In reply to David Redondo from comment #4)
> > Remove unneeded include
> 
> Doesn't seem to do it.  Still getting a similar altho slightly different in
> the details error:

... and reenabling my patch with the Qt::Widgets line still builds fine, so
indeed, the include you removed doesn't appear to be needed, but removing it
doesn't fix the problem of the missing QApplication.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457152] kwin commit 6576a83ae breaks build: missing QApplication

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457152

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to David Redondo from comment #4)
> Git commit 1f9c3178788d793d05a9065163569cb035b759c8 by David Redondo.
> Committed on 26/07/2022 at 10:06.
> Pushed by davidre into branch 'master'.
> 
> Remove unneeded include

Doesn't seem to do it.  Still getting a similar altho slightly different in the
details error:

/tmp/portage/kde-plasma/kwin-/work/kwin-/src/effects/outputlocator/outputlocator.cpp:11:10:
fatal error: QApplication: No such file or directory
11 | #include 
|  ^~
compilation terminated.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457152] kwin commit 6576a83ae breaks build: missing QApplication

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457152

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
Created attachment 150918
  --> https://bugs.kde.org/attachment.cgi?id=150918=edit
This fixes it for me.

Indeed, a Qt:Widgets line seems to do it.  I'm not a coder so I don't know if
this is the "correct" fix, but it works for me.  (And I only know git from a
gentoo-running consumer side so a gitlab merge request is beyond me.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457152] kwin commit 6576a83ae breaks build: missing QApplication

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457152

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||k...@david-redondo.de

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
CCing David as author/committer.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 457152] New: kwin commit 6576a83ae breaks build: missing QApplication

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=457152

Bug ID: 457152
   Summary: kwin commit 6576a83ae breaks build: missing
QApplication
   Product: kwin
   Version: git master
  Platform: Other
OS: Other
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: effects-various
  Assignee: kwin-bugs-n...@kde.org
  Reporter: 1i5t5.dun...@cox.net
  Target Milestone: ---

On git master for kwin, frameworks and plasma using the gentoo/kde overlay live
git ebuilds.  My current kwin HEAD is b7d7a99f in case it's fixed while I'm
filing this.

kwin commit (email addresses masked)

* commit 6576a83ae
Author: David Redondo 
AuthorDate: Wed Jun 29 13:52:52 2022 +0200
Commit: David Redondo 
CommitDate: Wed Jul 20 07:01:05 2022 +

Add outputlocator effect

An effect that implements the "identify" functionality of
the screen configuration kcm. It displays a label on each
screen that identifies the screen.
Doing this as a kwin effect allows to correctly handle
the case when outputs are mirrored (on wayland) compared to
absolute positioning of windows which end up on top of each other.

... breaks my build with the following error:

In file included from
/tmp/portage/kde-plasma/kwin-/work/kwin-/src/effects/outputlocator/outputlocator.cpp:10:
/tmp/portage/kde-plasma/kwin-/work/kwin-/src/main.h:21:10: fatal error:
QApplication: No such file or directory
21 | #include 

Missing a Qt::Widgets in CMakeLists.txt under
target_link_libraries(kwin4_effect_outputlocator PRIVATE ??

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 450582] Some change between 5.24.0 and 5.24.1 broke windows shade/shutter feature

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=450582

--- Comment #36 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Hans-Peter Jansen from comment #35)
> Of course, we also need to take session management into account.

Not being one that uses session management (per se, I use startup scripts and
window rules to do the configuring I need) much, I hadn't thought of that. 
Good call, altho I'd suggest an initial implementation wouldn't need it due to
the complexity.

> The X11
> protocol does provide the shaded flag for this task.
> I even hacked a related tool to handle my firefox setup. FF failed to handle
> the geometry and shaded state for some time:
> 
> https://github.com/frispete/wm-win-tool

What about other gtk3-based apps?  Firefox only or anything gtk-based?

As for your tool, I was thinking wmctrl as well, and sure enough it's a dep.  
But I'm a shellscript guy so that's what all my wmctrl/xprop/etc stuff is, not
the python you used.  Well, that and kwin window rules.

There was also the khotkeys GUI app that allowed dynamic/triggered action
invocation, back in the day, but last I tried it, even on X, while the
configuration GUI still ran and actions could still be configured, I couldn't
get them to actually work as configured.  I strongly suspect that it had lost a
proper maintainer even by the time of the kde4->kde5 port, and while it was
"ported" by others in terms of made to build and the GUI run, I'm not sure it
ever actually worked properly on kde5, and certainly didn't seem to even on
xorg last I tried it.

But I can't /imagine/ the kde wayland port being considered complete without
/some/ sort of scriptable/invokable custom window management comparable to the
static functionality kwin window rules provides on X and wayland, and wmctrl
and friends  provide dynamically on X, so I guess eventually they'll either
fix/port khotkeys, or reimpliment similar functionality from scratch.  But I
actually don't expect it until after the (currently underway) qt6 port is done.
  (And qt6 being the first qt to have wayland support from the get-go, I expect
its wayland support to be better and more efficient, such that implementing
such stuff in it may well be 2/3 the work it'd be on qt5.)

Anyway, doing wayland-shading session support without full protocol support is
still possible, but I expect it'd be several times the complexity of the
"simple" solution I was imagining, so wouldn't be likely for initial support at
least.  But as long as apps can be forced to run in X mode via xwayland,
existing solutions like your scripting solution should remain viable.  And
pre-setting such vars before app startup or auto-adding commandline options as
appropriate, is what wrapper scripts are for! =:^)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 450582] Some change between 5.24.0 and 5.24.1 broke windows shade/shutter feature

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=450582

--- Comment #34 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Hans-Peter Jansen from comment #33)
> As a reminder: as far as I know, the Wayland protocol has no such concept of
> shaded/shuttered windows. Therefore, preserving this feature in the longer
> term would, in my humble view, require that such an option be considered in
> the Wayland protocol itself. If anyone has more information on this topic,
> please let me know. Thank you!

Just thinking... What would it take?  AFAIK/IMO, wayland protocol shading
support would be nice, but isn't absolutely required, certainly for apps that
are prepared to deal with kwin's compositor-side-decorations, as most modern
wayland apps can, nowdays.

Basically, it would require "lying" a bit to the app, telling it it's either
mimimized/offscreen or a normal window, because telling it the real state, that
it's shaded, isn't supported.  In the former case, kwin would have to keep
track of the previous window size and position, and continue drawing the
(compositor-side for kwin) titlebar, but ONLY the titlebar.  In the latter
case, the app would think it was shown so would behave normally, but the
kwin-compositor, always in charge of where and how the window is drawn in any
case, would simply only draw the titlebar part of the (compositor-side)
decoration, not the client/application window.

The latter case, telling the app its window is normalized, which in some ways
it effectively would be but with the app-window portion effectively 100%
transparent or covered with 100% opacity (something a wayland app doesn't
normally  know in any case),  would probably avoid some problems, but would use
more power for apps that basically suspend themselves when they're not doing
any output drawing anyway, as is the case when they're offscreen/minimized,
because they wouldn't know that and would continue drawing their window as if
it was visible.

The former case, telling the app its window is minimized/offscreen, would
likely be more complicated, as kwin would have to keep track of more state
about the actual window that the app might not track when its minimized.   Apps
that update their titlebar frequently (think a resource monitor updating
information in the titlebar every second, for instance) but suspend that
updating when they're minimized/offscreen would be particularly troublesome, as
the titlebar would still be displayed when shaded, but the title would simply
stop updating.

Either way it should be possible, even without direct protocol support. 
Someone, presumably someone with the necessary skills (which I don't claim to
have) suitably motivated to scratch their own itch, just has to code it up and
get it accepted.   It /might/ even be doable as a kwin window management
script, allowing it to be uploaded to the kde store, thus avoiding the "get it
accepted" part it'd have to go through to become part of kwin proper.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 456655] plasma-workspace bf4dd6353 broke building without kpipewire, fed29855f didn't fix

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=456655

--- Comment #4 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Bug Janitor Service from comment #3)
> A possibly relevant merge request was started @
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1923

That fixes it, here.  Built fine with the patch and rebooted so I'm running it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 456655] plasma-workspace bf4dd6353 broke building without kpipewire, fed29855f didn't fix

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=456655

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
See also downstream gentoo: https://bugs.gentoo.org/848771#c11

 (I tried to put it in the see also field as well, but kdebugs says it's the
wrong format and doesn't seem to have/list a gentoo exception like it does for
debian.  That bug is about a related gentoo plasma-desktop problem, but the
linked comment mentions this plasma-workspace issue as a followup and has more
complete error output.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 456655] plasma-workspace bf4dd6353 broke building without kpipewire, fed29855f didn't fix

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=456655

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||aleix...@kde.org

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
CCing aleixpol@ as the author/committer of both commits.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 456655] New: plasma-workspace bf4dd6353 broke building without kpipewire, fed29855f didn't fix

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=456655

Bug ID: 456655
   Summary: plasma-workspace bf4dd6353 broke building without
kpipewire, fed29855f didn't fix
   Product: plasmashell
   Version: master
  Platform: Compiled Sources
OS: All
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Task Manager and Icons-Only Task Manager
  Assignee: plasma-b...@kde.org
  Reporter: 1i5t5.dun...@cox.net
  Target Milestone: 1.0

This is for plasma-workspace from git master using the gentoo/kde overlay
ebuilds.  Unfortunately there's no "plasma-workspace" product so I had to
choose the closest fit I could find.  (FWIW frameworks and the rest of plasma
are git-master as well, tho I don't believe it matters for this bug.)

The first following plasma-workspace commit broke building without kpipewire
(the previous commit 2a7a7fd14 builds fine), and the second one didn't fix it:

* commit bf4dd6353
Author: Aleix Pol 
AuthorDate: Wed Jun 29 16:27:01 2022 +0200
Commit: Aleix Pol 
CommitDate: Tue Jul 5 12:47:56 2022 +0200

libtaskmanager: Use KPipeWire

* commit fed29855f
| Author: Aleix Pol 
| AuthorDate: Fri Jul 8 20:10:10 2022 +0200
| Commit: Aleix Pol Gonzalez 
| CommitDate: Sun Jul 10 15:48:23 2022 +
|
| KPipeWire isn't actually required
|
| Just some features will be missing

Doing the build, I get this during the configure step:

-- The following features have been disabled:

* PipeWire, Required for Wayland screencasting

But the following screencasting-related errors (plus many more of the same)
never-the-less occur:
/x86_64-pc-linux-gnu/gcc-bin/12.1.1/../../../lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o:
in function `int qmlRegisterUncreatableType(char const*, int,
int, char const*, QString const&) [clone .isra.0]':
taskmanagerplugin.cpp:(.text+0x2a): undefined reference to
`Screencasting::staticMetaObject'
/x86_64-pc-linux-gnu/gcc-bin/12.1.1/../../../lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
taskmanagerplugin.cpp:(.text+0x167): undefinedreference to
`Screencasting::staticMetaObject'
/x86_64-pc-linux-gnu/gcc-bin/12.1.1/../../../lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
taskmanagerplugin.cpp:(.text+0x195): undefinedreference to
`Screencasting::staticMetaObject'

Why is it still trying to reference screencasting despite it being specifically
disabled?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdialog] [Bug 427414] --slider dialog needs documentation and usage instructions

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=427414

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
Not sure kdialog's currently maintained beyond "minimal life support" level
(keeping it building and running, it is a native wayland app running on
wayland, and I see hints of qt6 support in git so should hopefully outlast
qt5).  See bug #455994 which I just filed for more on that: 
https://bugs.kde.org/show_bug.cgi?id=455994

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdialog] [Bug 450015] KDialog progress bar doesn't go to 100%

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=450015

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||1i5t5.dun...@cox.net

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
Not sure kdialog's actually actively maintained any longer (tho it is kept
building and working, including running as a native wayland binary and current
qt6 porting work).  For more on that see bug #455994 which I just filed:
https://bugs.kde.org/show_bug.cgi?id=455994

Meanwhile, I've not had occasion to use --progressbar and wasn't aware of this
bug until the pre-bug-file search for the above, but as it hasn't been
mentioned yet, kdialog should now ship with a kdialog_progress_helper binary
(depending on your distro packaging, of course), which I /assume/ does what its
name indicates, and that it's "the modern way" to deal with kdialog
progressbars.

Unfortunately it's entirely undocumented AFAICT, nothing on the tutorial (which
uses the bare kdialog --progressbar), nothing in the README, no manpages or kde
handbook entries for kdialog at all, and it doesn't even have the --help output
that kdialog itself has.  And it's an elf binary so can't just open it in a
text editor like a script to see what it does. So it seems it's "read the
source" (if you can) or try your luck with experiments. =:^(

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdialog] [Bug 455994] kdialog README needs updated (is kdialog currently maintained?)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=455994

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||fa...@kde.org

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
CCing dfaure@ based on README.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdialog] [Bug 455994] New: kdialog README needs updated (is kdialog currently maintained?)

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=455994

Bug ID: 455994
   Summary: kdialog README needs updated (is kdialog currently
maintained?)
   Product: kdialog
   Version: unspecified
  Platform: Other
OS: Other
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: br...@frogmouth.net
  Reporter: 1i5t5.dun...@cox.net
  Target Milestone: ---

Is kdialog maintained any longer?  Bugs are assigned to bradh@ (not kde,
frogmouth, but avoiding full address for spam control for not logged in) but
his last commit to the repo seems to have been in 2006 (!!), and the last bug
he commented on on bugzi (find his comments on any bug, sort by bug ID) was one
he filed in 2011, during the port to kde4 (!).

The README seems to be rather dated too, with multiple issues:

1) Tutorial link is still http and is dated:

http://techbase.kde.org/Development/Tutorials/Shell_Scripting_with_KDE_Dialogs

... which says it has moved (but doesn't redirect) to (https this time):

https://develop.kde.org/deploy/kdialog/

2) README says for functionality changes/adds, contact bradh@, but ...

3) It also says current maintainer David Faure (faure@), who is at least
reasonably currently active, but git log says last faure commit to kdialog was
mid 2020,  the only recently closed kdialog bugs seem to have been closed by
others (often the original filer), no real activity there, and that's not where
the bugzilla assignments are going.

Further, at least the --slider option isn't documented in the tutorial, and
mandatory arguments (presumably min/max/increment, are not documented in the
--help output.   Further, there seems to be no kdialog handbook entry to look
at and no manpage (which would be nice for a scriptable like kdialog). That's
bug #427414, but it illustrates the lack of maintenance.

And the kdialog_progress_helper binary seems entirely undocumented.  No --help
output, no mention in the README or tutorial (which demonstrates --progressbar
without the helper), no manpage or handbook...  Bug #450015 but another
illustration of missing maintenance.

kdialog does seem to be kept building and working, and seems to be a native
wayland app at least, but beyond that, any actual maintenance, or is it
effectively abandonware that's only kept minimally working by others?  (I do
see montel@ added Qt6 CI support with 8236e4711 back on May 24, so at least
there's hints of continued life support into qt6, but that's still minimal life
support even if continued, not proper maintenance.)

Version: kdialog along with plasma and frameworks on git master (using
gentoo/kde's overlay live ebuilds), but git master is not listed as a version
option.  (Tho I've not updated in a bit over a week, but given the time points
and lack of maintainer bug activity above, status is unlikely to have changed
in that time.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdialog] [Bug 427414] --slider dialog needs documentation and usage instructions

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=427414

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|REPORTED|CONFIRMED

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdialog] [Bug 427414] --slider dialog needs documentation and usage instructions

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=427414

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||1i5t5.dun...@cox.net

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
Just trying to find some --slider documentation myself.

With a bit of experimentation I had guessed it was text/min/max/increment, but
at least here...

kdialog --slider "test" 0 10 2

... increments by 1, not 2, and an increment of .1 or 0.1 increments by 1 as
well, so it seems "increment" isn't doing what I expected and after not seeing
information about that in the --help output or on the page linked in the
README, here I am looking at bugs, still trying to confirm that "increment" is
indeed the third argument (beyond text), and whether I'm formatting it
correctly if so.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 454933] Saving to network fails

[duncan]

https://bugs.kde.org/show_bug.cgi?id=454933

--- Comment #9 from duncan  ---
Hi Nate. Please suggest a different KDE app you'd like me to use for testing,
also where to install it from snap/repo/flatpack ...

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 454933] Saving to network fails

[duncan]

https://bugs.kde.org/show_bug.cgi?id=454933

--- Comment #7 from duncan  ---
It opens the file (when I remove the spaces) but as soon as I try and do
anything it freezing, says 'not responding', fails to close for a long time
before eventually closing.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeplasma-addons] [Bug 389623] potd "Centered" positioning behaves exactly as "Tiled" somewhy

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=389623

--- Comment #3 from Duncan <1i5t5.dun...@cox.net> ---
CCing Fushan Wen as he seems to have been doing all the recent PotD work. 
Maybe he can fix this one while he's at it. =:^)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeplasma-addons] [Bug 389623] potd "Centered" positioning behaves exactly as "Tiled" somewhy

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=389623

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|REPORTED|CONFIRMED
 CC||1i5t5.dun...@cox.net

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
This is a long-standing bug I still see.  Confirming and CCing.  (And also
mentioning in a new PotD bug 455062.  They're working on PotD ATM thus creating
that bug; maybe they can finally fix this one too.)

Actually, what I'd consider *ideal*, tho it'd require additional UI, would be
adjustable zoom/pan so the portion of the image shown could be selected, be
that top-left, centered at 100%, bottom-right, or other.  And of course make it
so such a choice can be applied to either PotD or local images.

Alternatively, remove the "centered" option for PotD since it's just broken,
and has been for years.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeplasma-addons] [Bug 455062] New: PotD: Setting a provider on multi-monitor sets all of them to the same one

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=455062

Bug ID: 455062
   Summary: PotD: Setting a provider on multi-monitor sets all of
them to the same one
   Product: kdeplasma-addons
   Version: git-master
  Platform: Gentoo Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Picture of the Day
  Assignee: plasma-b...@kde.org
  Reporter: 1i5t5.dun...@cox.net
CC: i...@guoyunhe.me, qydwhotm...@gmail.com
  Target Milestone: ---

This is on git-master frameworks/plasma using the gentoo/kde live-git ebuilds,
on qt 5.15.4.  Current kdeplasma-addons commit
f3db2b5c84c7e1a7aa1f8f2bef32a8b8ecbf34b0 .  I'm running on wayland without X
(other than xwayland) installed.   (Tho I do have weston installed as a wayland
compositor backup; I /am/ running live-git kwin/kde, after all.)

Since the PotD rework in April/May, my dual-monitor (side-by-side) layout
cannot setup different PotDs for each monitor.  Setting one will either set
both to the same PotD provider or do nothing. ( As best I've been able to work
out, setting it to PotD from image on one monitor will set it on both, after
which I cannot set it to another PotD on the other -- but setting it to a
different PotD on the first will reset it to that one on both.  However, I'm
not /entirely/ sure that's the specific behavior, while I /am/ sure I can't set
different ones on each, sometimes it ignores the setting, sometimes it resets
both.)

Despite not being able to set different PotD providers on each monitor, the
positioning settings remain distinct -- I can set one to scaled while the other
is set to scaled-and-cropped, for instance, and that is honored.

Further, I can still set (local) image (and presumably the other non-PotD
choices) separately, both to separate images, and with both set to (the same)
PotD, I can set either one to an image.  I just can't set different PotD
providers on each one.

The result is that if I want different images on each monitor with a PotD, I
must choose a single PotD first and set it, then change the other to a (local)
image.


(And while you are looking at this PotD bug, could you see about the
long-standing broken-PotD-centering-option bug #389623 as well.  It has existed
since at least 2018 as that's when the bug was filed.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 454933] Saving to network fails

[duncan]

https://bugs.kde.org/show_bug.cgi?id=454933

--- Comment #5 from duncan  ---
Hi Nate

Yes this is Gnome in a very vanilla and fresh Ubuntu install of 22.04.

Sadly I cannot paste a file path into the default file manager anywhere ... But
if I navigate to the path fully (/run/user/1000/gvfs/ etc) it opens. It does
not open using the shortcut/bookmark in the file manager
(smb//kiwinest2.local/storage).

Even if opened with the full path I cannot save the file to that location
afterwards.

Full path - yes. Via bookmark - no. Saving - no.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 454933] Saving to network fails

[duncan]

https://bugs.kde.org/show_bug.cgi?id=454933

duncan  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |REPORTED

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 454933] Saving to network fails

[duncan]

https://bugs.kde.org/show_bug.cgi?id=454933

--- Comment #3 from duncan  ---
So after chatting with some Ubuntu folks I tried to install Okular as a flatpak
instead of as a snap (default method). This is just to let you know that it
made no difference and Okular behaved the same.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 454933] Saving to network fails

[duncan]

https://bugs.kde.org/show_bug.cgi?id=454933

--- Comment #2 from duncan  ---
The path is already mounted and a LibreOffice file is saving a document around
the same time to the same directory.

The path looks like this:
/run/user/1000/gvfs/smb-share:server=kiwinest2.local,share=storage/Gyldenmuld_4/Gyldenmuld_renovering/Tegninger
Gyldenmuld_2022.05.29_dli.pdf

I notice that Okular cannot open the file itself when I navigate to the file.
It can only open the file from my file manager by specifying Okular (rather
than the current default PDF viewer). It can also open the file by the recent
files list from the file manager. The file is not listed in Okulars own recent
files list.

So now I'm wondering if Okular can even see the file in that location. I'm not
sure how to test what might be going on to see if this has much to do with
Okular at all or is a wider problem.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 454933] New: Saving to network fails

[duncan]

https://bugs.kde.org/show_bug.cgi?id=454933

Bug ID: 454933
   Summary: Saving to network fails
   Product: okular
   Version: 20.12.3
  Platform: Ubuntu Packages
OS: Linux
Status: REPORTED
  Severity: critical
  Priority: NOR
 Component: general
  Assignee: okular-de...@kde.org
  Reporter: dun...@lithgow-schmidt.dk
  Target Milestone: ---

SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug
symbols.
See
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***


STEPS TO REPRODUCE
1. Open a PDF file from a network directory (smb) 
2. Work in the file, adding markups
3. Try to save with a new name (probably name makes no difference)

OBSERVED RESULT
The 'save as' dialogue closes without complaining but the file has not been
saved and Okular is now frozen and can't be closed by the usual GUI methods.

EXPECTED RESULT
In order of preference
1. The files should be saved
2. Okluar should report that it cannot save the file because ." ... "

SOFTWARE/OS VERSIONS
GNU/Linux: Ubuntu 22.04
Gnome: 42.1

ADDITIONAL INFORMATION
The smb share is on a Synology NAS running updated DSM OS. This same operation
works fine with LibreOffice files and a PDF opened and saved with the default
Document Viewer

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 454243] Window glitching and blinking after closing

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=454243

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|REPORTED|CONFIRMED

--- Comment #3 from Duncan <1i5t5.dun...@cox.net> ---
Status: Confirmed.

Problem is still there.  I found the fix for the segfaulting issue that was
preventing me testing for resolution of this bug, turned the fall-apart effect
back on, and the problem returned against the fresh git-master build I did
today.

So fall-apart is back off again for the moment as a workaround.  Wish all
workarounds were that simple, but it'd be nice to have it back working one of
these days. =:^)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 454243] Window glitching and blinking after closing

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=454243

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||1i5t5.dun...@cox.net

--- Comment #2 from Duncan <1i5t5.dun...@cox.net> ---
I was seeing similar from a couple weeks ago, tho here the blinking continued
until I triggered a repaint (usually by focusing a different window, triggering
the dim-inactive effect and thus a repaint of the previously focused window as
well as the newly focused one).

* Fall-apart effect was on and turning it off eliminated the problem. (I left
it off for now.)

* git-master frameworks/plasma (and most gear) using the gentoo/kde overlay
live ebuilds
(so it's not just arch)

* amdgpu (so it's not nvidia-specific)

I hadn't upgraded again until yesterday and have other problems
(systemsettings, krunner, plasmashell segfaults triggered on first
geometry-changed, possibly due to a missing rebuild of something after
upgrading to qt-5.15.4 but that's what I'm looking at new bugs for) ATM so
can't get into the config to try turning it back on to see if the problem's
still there.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 453609] kwin commit 4cb3ab09e: build error: kwinanimationeffect.cpp:14:10 fatal error: QAction: No such file or directory:

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=453609

--- Comment #1 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Duncan from comment #0)
> Missed dep in CMakeLists.txt?  (Not investigated yet.)

Indeed.  But while I already have it and might as well post it, I'm not
dev-side-git familiar enough for a PR to be an option and patchfiles submitted
here seem to be studiously ignored (to be fair the warning says as much, but
that doesn't help people who don't know how to do a PR but already have the
patch from troubleshooting the problem and might as well post it), so we'll see
if posting it as text is as studiously ignored as patchfiles seem to be.


--- a/src/libkwineffects/CMakeLists.txt 2022-05-09 21:26:13.964236519 -0700
+++ b/src/libkwineffects/CMakeLists.txt 2022-05-09 22:21:46.805839417 -0700
@@ -55,6 +55,7 @@ target_link_libraries(kwineffects
 KF5::WindowSystem
 XCB::XCB
 PRIVATE
+Qt::Widgets
 Qt::Quick
 KF5::I18n
  kwinglutils

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 453609] kwin commit 4cb3ab09e: build error: kwinanimationeffect.cpp:14:10 fatal error: QAction: No such file or directory:

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=453609

Duncan <1i5t5.dun...@cox.net> changed:

   What|Removed |Added

 CC||notm...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 453609] New: kwin commit 4cb3ab09e: build error: kwinanimationeffect.cpp:14:10 fatal error: QAction: No such file or directory:

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=453609

Bug ID: 453609
   Summary: kwin commit 4cb3ab09e: build error:
kwinanimationeffect.cpp:14:10 fatal error: QAction: No
such file or directory:
   Product: kwin
   Version: git master
  Platform: Other
OS: Other
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: effects-various
  Assignee: kwin-bugs-n...@kde.org
  Reporter: 1i5t5.dun...@cox.net
  Target Milestone: ---

kwin commit 4cb3ab09e (thru e1cec89dd HEAD)  won't build.  The previous commit
(46bbe4ff0) builds fine.  The error is:

src/libkwineffects/kwinanimationeffect.cpp:14:10: fatal error: QAction: No such
file or directory
14 | #include 

I'm on git master for kde-frameworks/-plasma/(most)-gear, using the live-git
ebuilds from the gentoo/kde overlay and /usr/include/qt5/QtWidgets/QAction (and
qaction.h) exist.

Missed dep in CMakeLists.txt?  (Not investigated yet.)

 (I should also mention, actually here the canonical location is /include/...
as I'm running reverse-usrmerge, with a /usr symlink: /usr -> .   But it's
normally all found just fine, and other qt libs are found in this case, but not
that one.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney] [Bug 452935] I18N_ARGUMENT_MISSING in CSV import Columns screen

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=452935

--- Comment #3 from Duncan  ---
(In reply to Thomas Baumgart from comment #1)
> I am unable to duplicate this here. I tried with en_US.UTF-8 and
> de_DE.UTF-8. Which language setting do you use?

$ env | grep LAN
LANGUAGE=en_IE:en
LANG=en_IE.UTF-8

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 452937] New: CPU view in Info Center cuts off CPU flags

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=452937

Bug ID: 452937
   Summary: CPU view in Info Center cuts off CPU flags
   Product: kinfocenter
   Version: 5.24.4
  Platform: Kubuntu Packages
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: plasma-b...@kde.org
  Reporter: kde.b...@cricalix.net
CC: hubn...@gmail.com
  Target Milestone: ---

Created attachment 148338
  --> https://bugs.kde.org/attachment.cgi?id=148338=edit
Annotated screenshot

SUMMARY
The rendering of the Flags section of CPU Info does not show the last few
elements of the flags; they're wrapped onto a line that's hidden below the
bottom of the window. If the window is then resized enough to cause a text
reflow, it becomes possible to scroll all the way down and see the last flags.

STEPS TO REPRODUCE
1. About this system
2. Show More Information
3. Devices
4. CPU
5. Scroll the CPU output down

OBSERVED RESULT

The last few elements from the CPU flags are not rendered properly in the text
box.

EXPECTED RESULT

All CPU flags are shown.

SOFTWARE/OS VERSIONS
Operating System: Kubuntu 21.10
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.2
Kernel Version: 5.13.0-40-generic (64-bit)
Graphics Platform: X11
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor


ADDITIONAL INFORMATION

The text box is not showing "rdpid overflow_recov succor smca fsrm", but the
screenshot shows that the text is there; you can see the top of the d, i, and d
in rdpid, and the fl in overflow, and the f in frsm.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney] [Bug 452935] New: I18N_ARGUMENT_MISSING in CSV import Columns screen

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=452935

Bug ID: 452935
   Summary: I18N_ARGUMENT_MISSING in CSV import Columns screen
   Product: kmymoney
   Version: 5.1.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: ux-ui
  Assignee: kmymoney-de...@kde.org
  Reporter: kde.b...@cricalix.net
  Target Milestone: ---

Created attachment 148336
  --> https://bugs.kde.org/attachment.cgi?id=148336=edit
Annotated screenshot

SUMMARY
The Columns setup for CSV import displays "Memo columns:
(I18N_ARGUMENT_MISSING)" where  is the selected columns


STEPS TO REPRODUCE
1. Start the CSV import process
2. Get to the stage of selecting columns
3. Look at the text after the italicised "Memo columns"

OBSERVED RESULT
With no memo column selected, "None(I18N_ARGUMENT_MISSING)"
With a memo column selected, replace None with the column, rest of text is the
same.

EXPECTED RESULT
Don't know. Can't tell if this is a failure to pass a flag to a method, or some
other issue with a translation.

SOFTWARE/OS VERSIONS
Operating System: Kubuntu 21.10
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.2
Kernel Version: 5.13.0-40-generic (64-bit)
Graphics Platform: X11


ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney] [Bug 452918] Payee > Account Numbers > IBAN does not accept pasted content with a space at the start

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=452918

--- Comment #5 from Duncan  ---
Thank you Thomas. I had looked in that validator code, but my C++ knowledge is
about zero, so couldn't offer a patch (and didn't know fixup() existed either).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney] [Bug 452918] Payee > Account Numbers > IBAN does not accept pasted content with a space at the start

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=452918

--- Comment #2 from Duncan  ---
Clarity for step 3 of the reproduction - highlight including the space at the
start.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney] [Bug 452918] Payee > Account Numbers > IBAN does not accept pasted content with a space at the start

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=452918

--- Comment #1 from Duncan  ---
Where I ran into this was double-clicking an IBAN in wise.com's interface to
select it, copying it with Ctrl-C, and then attempting to paste it. Something
about the copied HTML places a space at each end of the text, and this
whitespace is not obvious unless you paste into a program like Kate and notice
the extra space on the highlight.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney] [Bug 452918] New: Payee > Account Numbers > IBAN does not accept pasted content with a space at the start

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=452918

Bug ID: 452918
   Summary: Payee > Account Numbers > IBAN does not accept pasted
content with a space at the start
   Product: kmymoney
   Version: 5.1.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: ux-ui
  Assignee: kmymoney-de...@kde.org
  Reporter: kde.b...@cricalix.net
  Target Milestone: ---

SUMMARY
The IBAN and BIC fields in the per-payee Account Numbers does not accept pasted
content from the clipboard on X11 if the content has whitespace at the
beginning

STEPS TO REPRODUCE
1. Open Kate
2. Type an IBAN, placing an extra space at the start
3. Highlight the IBAN
4. Ctrl-C to copy the IBAN
5. Open kMyMoney
6. Choose a payee
7. Choose Account Numbers
8. Select IBAN & BIC
9. Double-click the IBAN & BIC that shows up to show the entry fields
10. Place cursor in IBAN field
11. Try to paste with Ctrl-V or Ctrl-Shift-Ins

OBSERVED RESULT
Paste does not happen

EXPECTED RESULT
One of

1. Acceptance of the pasted content, with the leading whitespace stripped.
2. An error dialog explaining why the content was not accepted.

Given the UI will reformat an IBAN of the format  IE48ICON11223344556677 into
IE48 ICON 1122 3344 5566 77, I would advocate for the first option; apply
strip() to the input, then validate that it's in the appropriate form for an
IBAN. If it's still not appropriate, *tell* the person that it's not valid -
don't silently fail.

SOFTWARE/OS VERSIONS
Operating System: Kubuntu 21.10
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.2
Kernel Version: 5.13.0-40-generic (64-bit)
Graphics Platform: X11

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney] [Bug 452894] New: When entering new ledger entries, previous payee is kept without category

[Duncan]

https://bugs.kde.org/show_bug.cgi?id=452894

Bug ID: 452894
   Summary: When entering new ledger entries, previous payee is
kept without category
   Product: kmymoney
   Version: 5.1.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: ux-ui
  Assignee: kmymoney-de...@kde.org
  Reporter: kde.b...@cricalix.net
  Target Milestone: ---

SUMMARY
The ledger entry payee field has a behaviour that I find frustrating - it
remembers the previous payee, but doesn't remember the previous category OR use
the default category if one is assigned for that payee.

A workaround is to delete the last letter of the pre-filled payee, then
down-arrow to select the full match on the existing payee. Depending on the
autofill settings in Settings > Ledger > Data Entry, you then either get the
autofill popup from previous transaction (Same transaction if amount differs..)
or what looks like the default category (With previously most often used..).

This is frustrating, and slows down my data entry.

It looks as though the pre-fill is not triggering whatever trigger is used when
selecting a payee from the dropdown typeahead.

STEPS TO REPRODUCE
1. Open kMyMoney to a ledger view
2. Enter a back-dated transaction for an existing payee,  to save it
3. Tab over to Dolphin to open new PDF
4. Move Okular window a bit
5. Tab back to kMyMoney
6. Ctrl+Ins to start new ledger entry

I'm not sure 3/4/5 matter much, but it's what I'm doing, so I'm including it.

OBSERVED RESULT
Previous payee from step 2 appears in the ledger entry area, defaulting as an
Increase. The category is not set, regardless of the tickbox value and dropdown
value for "default category".

Pressing tab to move to the category field does not fill the category if
default category is ticked and set.

EXPECTED RESULT
One of two options.
1) The payee is not kept.
2) The payee is kept, but if the default category is set, the category field is
populated.

SOFTWARE/OS VERSIONS

Operating System: Kubuntu 21.10
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.2
Kernel Version: 5.13.0-40-generic (64-bit)
Graphics Platform: X11

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.