[plasmashell] [Bug 446213] Calendar app showing "0 %2(I18N_ARGUMENT_MISSING)"

[Anton Kreuzkamp]

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

Anton Kreuzkamp  changed:

   What|Removed |Added

 CC||akreuzk...@web.de

--- Comment #1 from Anton Kreuzkamp  ---
Try to reconfigure your time zone in systemsettings. Apparently something broke
that setting. I had the same issue and found out (via plasmaengineexplorer, if
you want to check it out on your system) that plasma's time-DataSource reported
an empty DataTime for the "Local" time but a correct time for all time zones.
So I went for the time zone dialog in systemsettings and set the time zone to
the correct one and at least here the digital clock shows a correct time again
and the calendar widget shows correct dates.

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

[plasmashell] [Bug 439513] Klipper interferes with XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

--- Comment #12 from Anton Kreuzkamp  ---
I don't always see a blank entry appear, but there is always exactly one blank
entry floating around in my klipper history (and pasting doesn't work when it's
the upper most).
The stdout-output of klipper clearly indicates that more than one entry is
created (probably afterwards filtered by some duplication removal).

The bug only happens with the "Prevent empty clipboard" is activated (above I
wrote "only when IgnoreSelection is set", that was by mistake)

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

[plasmashell] [Bug 439513] Klipper interferes with XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

--- Comment #11 from Anton Kreuzkamp  ---
Created attachment 140498
  --> https://bugs.kde.org/attachment.cgi?id=140498=edit
klipperrc

Here is the config of klipper. The bug happens only when IgnoreSelection is set
to true.

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

[kwin] [Bug 439070] Unable to copy/paste when using Wayland

[Anton Kreuzkamp]

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

--- Comment #12 from Anton Kreuzkamp  ---
After update to 5.22.3 pasting images into krita (xwayland) works fine, pasting
into Chrome (91.0, XWayland) still fails.

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

[plasmashell] [Bug 439513] Klipper interferes with XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

Anton Kreuzkamp  changed:

   What|Removed |Added

Version|5.22.2  |5.22.3

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

[kwin] [Bug 439070] Unable to copy/paste when using Wayland

[Anton Kreuzkamp]

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

--- Comment #10 from Anton Kreuzkamp  ---
Note the related issue #439513 Copying images (and text) from Chrome (XWayland)
to Dolphin (Wayland native) works when Klipper is not running but fails
sometimes when Klipper is running (at least on my machine).

The issue mentioned here (copy and pasting from wayland-native to Chrome/Krita)
happens independently of Klipper.

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

[plasmashell] [Bug 439513] Klipper interferes with XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

Anton Kreuzkamp  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1
 Status|RESOLVED|REOPENED

--- Comment #9 from Anton Kreuzkamp  ---
This does not seem to be a duplicate of #439070. I can confirm the other one,
but while this one is clearly related to Klipper doing things, the other one is
not (cf. my comment on #439070). Here the issue appears while copying, there it
happens while pasting.

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

[kwin] [Bug 439070] Unable to copy/paste when using Wayland

[Anton Kreuzkamp]

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

--- Comment #9 from Anton Kreuzkamp  ---
I can confirm this issue. Here, copying from spectacle into the clipboard works
fine (as shown by Klipper), pasting fails for Chrome (XWayland), Krita
(XWayland). Pasting does work for Firefox (XWayland), Dophin (XWayland),
Dolphin (wayland native).

It makes no difference whether Plasmashell/Klipper is running or not.

Copy and pasting from Firefox (XWayland) or Chrome (XWayland) into Chrome
(XWayland) or Krita (XWayland) works fine.

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

[plasmashell] [Bug 439513] Klipper interferes with XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

Anton Kreuzkamp  changed:

   What|Removed |Added

 Attachment #139872|0   |1
is obsolete||

--- Comment #7 from Anton Kreuzkamp  ---
Created attachment 139873
  --> https://bugs.kde.org/attachment.cgi?id=139873=edit
Stout-output of klipper

Excerpt of the stdout-output of `plasmawindowed org.kde.plasma.clipboard` while
copying four times a word from firefox. The first and second copy succeeded,
the third one failed the fourth succeeded. Empty lines and lines starting with
hashtag are added by me. The content mentioned in the lines `org.kde.klipper:
Setting clipboard to < ... >` is always the content of the clipboard BEFORE,
not the copied text.

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

[plasmashell] [Bug 439513] Klipper interferes with XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

--- Comment #6 from Anton Kreuzkamp  ---
Created attachment 139872
  --> https://bugs.kde.org/attachment.cgi?id=139872=edit
Stout-output of klipper

Excerpt of the stdout-output of `plasmawindowed org.kde.plasma.clipboard` while
copying three times a word from firefox. The first two copies succeeded, the
last one failed.

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

[plasmashell] [Bug 439513] Klipper interferes with XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

Anton Kreuzkamp  changed:

   What|Removed |Added

Summary|XWayland: Copying text  |Klipper interferes with
   |works only every second |XWayland: Copying text
   |time|works only every second
   ||time
   Target Milestone|--- |1.0
   Assignee|kwin-bugs-n...@kde.org  |plasma-b...@kde.org
Product|kwin|plasmashell
  Component|platform-wayland|Clipboard

--- Comment #5 from Anton Kreuzkamp  ---
copying from Firefox in a Weston-session works fine. The bug disappears when
quitting plasmashell and reappears when starting `plasmawindowed
org.kde.plasma.clipboard`, so klipper is obviously involved somehow.

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

[kwin] [Bug 439513] XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

--- Comment #4 from Anton Kreuzkamp  ---
Created attachment 139866
  --> https://bugs.kde.org/attachment.cgi?id=139866=edit
kwin queryWindowInfo for Signal, where no issue appeared

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

[kwin] [Bug 439513] XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

--- Comment #3 from Anton Kreuzkamp  ---
Created attachment 139865
  --> https://bugs.kde.org/attachment.cgi?id=139865=edit
kwin queryWindowInfo for Okular, where the issue appeared

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

[kwin] [Bug 439513] XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

--- Comment #2 from Anton Kreuzkamp  ---
starting firefox with `GTK_USE_PORTAL=0 firefox` (instead of with
GTK_USE_PORTAL=1 as I use to) does not prevent this bug to appear with firefox.

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

[kwin] [Bug 439513] XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

--- Comment #1 from Anton Kreuzkamp  ---
Created attachment 139864
  --> https://bugs.kde.org/attachment.cgi?id=139864=edit
org.kde.KWin.supportInformation

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

[kwin] [Bug 439513] New: XWayland: Copying text works only every second time

[Anton Kreuzkamp]

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

Bug ID: 439513
   Summary: XWayland: Copying text works only every second time
   Product: kwin
   Version: 5.22.2
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: platform-wayland
  Assignee: kwin-bugs-n...@kde.org
  Reporter: akreuzk...@web.de
  Target Milestone: ---

I cannot yet tell under which circumstances this issue arises, it only happens
in some windows, but I cannot yet tell the difference.

I can only reproduce this with xwayland windows. I could reproduce the issue
with firefox, okular and kate running through xwayland, I could not reproduce
with kate running as wayland window.

It might indeed be an issue with xdg-portals, as Signal, which is running
through xwayland from a flatpak, but does afaik not support xdg-portals, does
not have this issue.

STEPS TO REPRODUCE
1. Start for example Firefox in a plasma wayland session
2. Mark some text, press Ctrl+c to copy
3. paste into krunner or check klipper to see if the text made its way into the
clipboard
4. Repeat steps 2 and 3 several times.

OBSERVED RESULT
It appears, that copying works exactly every second time.


EXPECTED RESULT
The text should be pasted and displayed in klipper every time.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux, kernel 5.12.13 (64bit)
(available in About System)
KDE Plasma Version: 5.22.2
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION

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

[kmail2] [Bug 409851] New: "Import key" link in mails with attached PGP key doesn't do anything

[Anton Kreuzkamp]

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

Bug ID: 409851
   Summary: "Import key" link in mails with attached PGP key
doesn't do anything
   Product: kmail2
   Version: 5.11.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: crypto
  Assignee: kdepim-b...@kde.org
  Reporter: akreuzk...@web.de
  Target Milestone: ---

Importing an attached PGP key from a received mail is not possible currently.
The key is displayed correctly as a pgp key and a link to import the key is
offered. Clicking on that link doesn't do anything, though. I couldn't find any
way around it, like a way to save the key to the harddisk. In encrypted mails,
not even the mail source code helps.

I don't have debug symbols available, unfortunately, so I can't verify, if
ApplicationPgpKeyUrlHandler::handleClick is being called or not...

STEPS TO REPRODUCE
1. Receive an email with an attached PGP key, you don't have yet.
2. Open the mail and scroll down to the "OpenPGP Key" section.
3. Click on "Import key" and wonder why nothing happens at all.

OBSERVED RESULT
No visible reaction whatsoever, the key does not appear in kleopatra's key list
afterwards

EXPECTED RESULT
Kleopatra opens, importing the key.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
(available in About System)
KDE Plasma Version: 5.16.2
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.4

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

[kdevelop] [Bug 393643] KDevelop is not able to recover from clang crashes

[Anton Kreuzkamp]

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

--- Comment #1 from Anton Kreuzkamp <akreuzk...@web.de> ---
Created attachment 112306
  --> https://bugs.kde.org/attachment.cgi?id=112306=edit
The file to reproduce the clang and therefore the kdevelop-crash

It's already enough to open the file without a project.

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

[kdevelop] [Bug 393643] New: KDevelop is not able to recover from clang crashes

[Anton Kreuzkamp]

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

Bug ID: 393643
   Summary: KDevelop is not able to recover from clang crashes
   Product: kdevelop
   Version: 5.2.1
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: akreuzk...@web.de
  Target Milestone: ---

Application: kdevelop (5.2.1)

Qt Version: 5.10.1
Frameworks Version: 5.45.0
Operating System: Linux 4.16.3-1-ARCH x86_64
Distribution (Platform): Archlinux Packages

-- Information about the crash:
- What I was doing when the application crashed:
KDevelop parsed a file that causes clang to crash. The stack trace suggests
that KDevelop tries to recover from the crash (the KDevelop-crash happens
inside a llvm::CrashRecoveryContext), but fails to do so.

For a file to reproduce the crash see attachment. I have clang 6.0.0 installed.

The crash can be reproduced every time.

-- Backtrace:
Application: KDevelop (kdevelop), signal: Segmentation fault
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f10d0346e80 (LWP 19077))]

Thread 23 (Thread 0x7f102d7fa700 (LWP 19133)):
#0  0x7f10c615b07c in pthread_cond_wait@@GLIBC_2.3.2 () at
/usr/lib/libpthread.so.0
#1  0x7f10cd0d7fac in QWaitCondition::wait(QMutex*, unsigned long) () at
/usr/lib/libQt5Core.so.5
#2  0x7f10c1b6952f in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () at /usr/lib/libKF5ThreadWeaver.so.5
#3  0x7f10c1b6d719 in  () at /usr/lib/libKF5ThreadWeaver.so.5
#4  0x7f10c1b686fd in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at
/usr/lib/libKF5ThreadWeaver.so.5
#5  0x7f10c1b6d772 in  () at /usr/lib/libKF5ThreadWeaver.so.5
#6  0x7f10c1b686fd in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at
/usr/lib/libKF5ThreadWeaver.so.5
#7  0x7f10c1b6b583 in ThreadWeaver::Thread::run() () at
/usr/lib/libKF5ThreadWeaver.so.5
#8  0x7f10cd0d6acd in  () at /usr/lib/libQt5Core.so.5
#9  0x7f10c61550bc in start_thread () at /usr/lib/libpthread.so.0
#10 0x7f10cc9dc2ff in clone () at /usr/lib/libc.so.6

Thread 22 (Thread 0x7f102dffb700 (LWP 19132)):
#0  0x7f10c615b07c in pthread_cond_wait@@GLIBC_2.3.2 () at
/usr/lib/libpthread.so.0
#1  0x7f10cd0d7fac in QWaitCondition::wait(QMutex*, unsigned long) () at
/usr/lib/libQt5Core.so.5
#2  0x7f10c1b6952f in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () at /usr/lib/libKF5ThreadWeaver.so.5
#3  0x7f10c1b6d719 in  () at /usr/lib/libKF5ThreadWeaver.so.5
#4  0x7f10c1b686fd in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at
/usr/lib/libKF5ThreadWeaver.so.5
#5  0x7f10c1b6b583 in ThreadWeaver::Thread::run() () at
/usr/lib/libKF5ThreadWeaver.so.5
#6  0x7f10cd0d6acd in  () at /usr/lib/libQt5Core.so.5
#7  0x7f10c61550bc in start_thread () at /usr/lib/libpthread.so.0
#8  0x7f10cc9dc2ff in clone () at /usr/lib/libc.so.6

Thread 21 (Thread 0x7f102e7fc700 (LWP 19131)):
#0  0x7f10c615b07c in pthread_cond_wait@@GLIBC_2.3.2 () at
/usr/lib/libpthread.so.0
#1  0x7f10cd0d7fac in QWaitCondition::wait(QMutex*, unsigned long) () at
/usr/lib/libQt5Core.so.5
#2  0x7f10c1b6952f in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () at /usr/lib/libKF5ThreadWeaver.so.5
#3  0x7f10c1b6d719 in  () at /usr/lib/libKF5ThreadWeaver.so.5
#4  0x7f10c1b686fd in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at
/usr/lib/libKF5ThreadWeaver.so.5
#5  0x7f10c1b6b583 in ThreadWeaver::Thread::run() () at
/usr/lib/libKF5ThreadWeaver.so.5
#6  0x7f10cd0d6acd in  () at /usr/lib/libQt5Core.so.5
#7  0x7f10c61550bc in start_thread () at /usr/lib/libpthread.so.0
#8  0x7f10cc9dc2ff in clone () at /usr/lib/libc.so.6

Thread 20 (Thread 0x7f102effd700 (LWP 19130)):
[KCrash Handler]
#6  0x7f1020007b20 in  ()
#7  0x7f106546b08b in clang::ASTUnit::~ASTUnit() () at
/usr/lib/../lib/libclangFrontend.so.6
#8  0x7f106546ba93 in  () at /usr/lib/../lib/libclangFrontend.so.6
#9  0x7f1060261989 in llvm::CrashRecoveryContext::~CrashRecoveryContext()
() at /usr/lib/../lib/libLLVM-6.0.so
#10 0x7f1066200d69 in clang_parseTranslationUnit2FullArgv () at
/usr/lib/libclang.so.6
#11 0x7f106620100f in clang_parseTranslationUnit2 () at
/usr/lib/libclang.so.6
#12 0x7f1066507b17 in
ParseSessionData::ParseSessionData(QVector const&, ClangIndex*,
ClangParsingEnvironment const&, QFlags) () at
/usr/lib/libKDevClangPrivate.so.30
#13 0x7f106674c447 in  () at
/usr/lib/qt/plugins/kdevplatform/30/kdevclangsupport.so
#14 0x7f106674fef5 in  () at

[kontact] [Bug 392018] New: Contact group resolution can go crazy due to recursively resolving on a part of the group name

[Anton Kreuzkamp]

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

Bug ID: 392018
   Summary: Contact group resolution can go crazy due to
recursively resolving on a part of the group name
   Product: kontact
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: mail
  Assignee: kdepim-b...@kde.org
  Reporter: akreuzk...@web.de
  Target Milestone: ---

I had a contact group named "Family Mustermann". Guess what happens if you try
to write a mail to "Max Mustermann ".

Kontact wants to resolve the contact group "Family Mustermann" based on the
match "Mustermann". That causes "Erika Mustermann
" and "Max Mustermann
" to be loaded into the recipient list. Both of
them cause Kontact to resolve the contact group "Family Mustermann" based on
the match "Mustermann"... That doesn't only go until the maximal number of
recipients is reached, but continues after that, causing error messages about
the full recipient list to be created infinitely.
If you don't kill Kontact immediately the mail will be auto-saved and reappear
on a restart of Kontact, driving Kontact completely unusuable until you delete
the draft manually in the file system.

The same thing doesn't happen in KMail, as KMail apparently doesn't resolve
contact groups. It also doesn't happen if you insert e.g. "Max
" so resolution does only happen based on the name, not
on the e-mail address.

Reproducible: Always

Steps to Reproduce:
1. Create a contact group (e.g. "Family Mustermann"), whose name contains a
word (e.g. "Mustermann") that is also part of the name of one of the group
members (e.g. "Max Mustermann").
2. Compose a new mail
3. Insert the name of one of those recipients that have a partial name match
with the contact group name (e.g. "Max Mustermann ") is added to the recipient list, without the
contact group being resolved.

Proposed fix:
You could either not resolve contact groups based on only part of the name
and/or you could during contact group resolution filter out lines that contain
a full email address.

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

[kdevelop] [Bug 377397] New: "Implement ..." template for template methods misses the keyword "typename"

[Anton Kreuzkamp]

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

Bug ID: 377397
   Summary: "Implement ..." template for template methods misses
the keyword "typename"
   Product: kdevelop
   Version: 5.1.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Language Support: CPP (Clang-based)
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: akreuzk...@web.de
  Target Milestone: ---

Steps to reproduce:
1. Create a c++ project and use the clang-plugin.
2. Write a template class 
```
template class Foo {
void bar();
};
```
3. Below (or in the cpp) press CTRL+Space at an appropriate place in order to
get an completion proposal "Implement void Foo::bar()"
4. Press Enter.

The code will look like
```
template void Foo::bar()
{
}
```
while it needs to look like
```
template void Foo::bar()
{
}
```

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

[minuet] [Bug 375757] New: Major 7(b9) is duplicated in chord definition file

[Anton Kreuzkamp]

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

Bug ID: 375757
   Summary: Major 7(b9)  is duplicated in chord definition file
   Product: minuet
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: sandroandr...@kde.org
  Reporter: akreuzk...@web.de
  Target Milestone: ---

The chords-root-position-definitions.json has two identical chords "Major
7(b9)". It's not a big deal, as the exercises would tell me I answered
correctly for any of the duplicated options, but still it would be cleaner
without.:)

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

[kwin] [Bug 375518] global shortcuts show some oddities with foreign keyboard layouts

[Anton Kreuzkamp]

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

Anton Kreuzkamp <akreuzk...@web.de> changed:

   What|Removed |Added

Summary|global shortcuts don't work |global shortcuts show some
   |as expected with foreign|oddities with foreign
   |keyboard layouts|keyboard layouts

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

[kwin] [Bug 375518] New: global shortcuts don't work as expected with foreign keyboard layouts

[Anton Kreuzkamp]

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

Bug ID: 375518
   Summary: global shortcuts don't work as expected with foreign
keyboard layouts
   Product: kwin
   Version: git master
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: wayland-generic
  Assignee: kwin-bugs-n...@kde.org
  Reporter: akreuzk...@web.de
  Target Milestone: ---

I'm using a EU (US + special keys) keyboard layout, but occasionally I switch
to a greek layout to enter greek symbols. On X11 I used to use CTRL+ALT+K to
switch to greek and CTRL+ALT+K again to switch back.
On Wayland, I can use CTRL+ALT+K to switch to greek, but I can't switch back.
Probably this is, because I now effectively enter CTRL+ALT+Kappa.

I'm not 100% sure, how global shortcuts are supposed to work with foreign
keyboard layouts, but especially in regards of the "switch keyboard layout"
shortcut this is odd.

Maybe CTRL+ALT+Kappa is simply missing as a trigger for the shortcut or KWin's
handling should be different here.

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

[kdevelop] [Bug 368265] KDevelop crashes on macro navigation

[Anton Kreuzkamp via KDE Bugzilla]

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

--- Comment #1 from Anton Kreuzkamp <akreuzk...@web.de> ---
Created attachment 100933
  --> https://bugs.kde.org/attachment.cgi?id=100933=edit
minimal testcase

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

[kdevelop] [Bug 368265] New: KDevelop crashes on macro navigation

[Anton Kreuzkamp via KDE Bugzilla]

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

Bug ID: 368265
   Summary: KDevelop crashes on macro navigation
   Product: kdevelop
   Version: 5.0.0
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: akreuzk...@web.de

Application: kdevelop (5.0.0)
 (Compiled from sources)
Qt Version: 5.7.0
Frameworks Version: 5.25.0
Operating System: Linux 4.7.0-1-ARCH x86_64
Distribution (Platform): Archlinux Packages

-- Information about the crash:
- What I was doing when the application crashed:
I hovered an include statement, it said "Declarations: TEST_H, Class Test".
I clicked on TEST_H.
It crashed.

Interestingly enough, it happens only when test.h is also opened in the editor.

-- Backtrace:
Application: KDevelop (kdevelop), signal: Aborted
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f051894f840 (LWP 20922))]

Thread 22 (Thread 0x7f04837fe700 (LWP 21465)):
#0  0x7f05072c010f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f0508ab4ac4 in ?? () from /usr/lib/libQt5Script.so.5
#2  0x7f0508ab4b09 in ?? () from /usr/lib/libQt5Script.so.5
#3  0x7f05072ba454 in start_thread () from /usr/lib/libpthread.so.0
#4  0x7f0510ace7df in clone () from /usr/lib/libc.so.6

Thread 21 (Thread 0x7f0483fff700 (LWP 21315)):
#0  0x7f05072c010f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f05116d4c2b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/libQt5Core.so.5
#2  0x7f050d561402 in
ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned_locked
(this=0x4aa0fa0, th=0x7f047c002e20) at
/home/anton/devel/kde/frameworks/threadweaver/src/weaver.cpp:594
#3  0x7f050d5610da in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait (this=0x4aa0fa0,
th=0x7f047c002e20, threadWasBusy=false, suspendIfInactive=false,
justReturning=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/weaver.cpp:554
#4  0x7f050d569991 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x4aa1380, th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/workinghardstate.cpp:66
#5  0x7f050d56121c in ThreadWeaver::Weaver::applyForWork (this=0x4aa0fa0,
th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/weaver.cpp:568
#6  0x7f050d569a94 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x4aa1380, th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/workinghardstate.cpp:73
#7  0x7f050d56121c in ThreadWeaver::Weaver::applyForWork (this=0x4aa0fa0,
th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/weaver.cpp:568
#8  0x7f050d569a94 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x4aa1380, th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/workinghardstate.cpp:73
#9  0x7f050d56121c in ThreadWeaver::Weaver::applyForWork (this=0x4aa0fa0,
th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/weaver.cpp:568
#10 0x7f050d569a94 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x4aa1380, th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/workinghardstate.cpp:73
#11 0x7f050d56121c in ThreadWeaver::Weaver::applyForWork (this=0x4aa0fa0,
th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/weaver.cpp:568
#12 0x7f050d569a94 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x4aa1380, th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/workinghardstate.cpp:73
#13 0x7f050d56121c in ThreadWeaver::Weaver::applyForWork (this=0x4aa0fa0,
th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/weaver.cpp:568
#14 0x7f050d569a94 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x4aa1380, th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/workinghardstate.cpp:73
#15 0x7f050d56121c in ThreadWeaver::Weaver::applyForWork (this=0x4aa0fa0,
th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/weaver.cpp:568
#16 0x7f050d569a94 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x4aa1380, th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/workinghardstate.cpp:73
#17 0x7f050d56121c in ThreadWeaver::Weaver::applyForWork (this=0x4aa0fa0,
th=0x7f047c002e20, wasBusy=false) at
/home/anton/devel/kde/frameworks/threadweaver/src/weaver.cpp:568
#18 0x7f050d569a94 in ThreadWeaver::WorkingHardState::applyForWork
(this=0x4aa1380, th=0x7f047c002e20, wasBusy=false) at

[kwin] [Bug 365232] New: Mouse hover in menus only works sparsely on xwayland windows

[Anton Kreuzkamp via KDE Bugzilla]

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

Bug ID: 365232
   Summary: Mouse hover in menus only works sparsely on xwayland
windows
   Product: kwin
   Version: git master
  Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: backend-wayland
  Assignee: kwin-bugs-n...@kde.org
  Reporter: akreuzk...@web.de

While testing plasma with wayland I recognized glitches when hovering items in
right-click menus.
Steps to reproduce:
1. Open some xwayland window
2. Do a right-click or open a menu from the menubar
3. Hover some menu items

The item will only be highlighted sometimes. They do receive hover events, but
rendering seems faulty. I've seen the issue occur with Qt4 and 5-based
applications, as well chromium and firefox.
It doesn't happen with weston.

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