[systemsettings] [Bug 344867] Setting custom background image in kcm_sddm does not work
https://bugs.kde.org/show_bug.cgi?id=344867 --- Comment #30 from Janek Bevendorff --- I upgraded to 5.8 now. The fix seems to have introduced a little regression in the settings dialog itself. When I set a background image it (finally) shows up on the login screen. But when I close and reopen the settings dialog, the "set background image" button always shows a default image icon and not the actually selected image. Besides that, the login screen still shows the default user avatar and not my actual avatar, but that is probably a different issue. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356841] Plasma-nm applet does not show connection speed
https://bugs.kde.org/show_bug.cgi?id=356841 --- Comment #25 from Janek Bevendorff --- I just tested in 5.8.0 and it always shows 0B. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 365570] Systray icons are big and pixelated after update to 5.7.1
https://bugs.kde.org/show_bug.cgi?id=365570 --- Comment #19 from Janek Bevendorff --- In 5.8.0, minimized windows show a black rectangle if the option to keep thumbnails of hidden windows in memory is disabled. I don't think that's any more beautiful than pixelated icons. ;-) -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 369635] Allow to change UI colors, not just editor theme
https://bugs.kde.org/show_bug.cgi?id=369635 --- Comment #2 from Janek Bevendorff --- Looking at the diff, this should be in the settings menu. But there is no such entry, at least not in the current stable version (5.0.1). Maybe it didn't make it into the release? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353983] Turning off compositing breaks Plasma panel rendering
https://bugs.kde.org/show_bug.cgi?id=353983 Janek Bevendorff changed: What|Removed |Added Version|5.7.4 |5.8.0 --- Comment #39 from Janek Bevendorff --- This still happens in 5.8.0 and is super annoying. Now I don't know if this is a bug specifically in Chrome or indeed a general NVIDIA issue, but when I started an application that disables compositing, not only the Plasma panels showed this bug, but also the Chrome UI froze until I minimized and restored the window. Anyhow, this bug is a super show stopper and deserves a fix. Any more insight on what exactly may be causing it? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 370610] New: Automatically adjust window titlebar / window frame color to application theme
https://bugs.kde.org/show_bug.cgi?id=370610 Bug ID: 370610 Summary: Automatically adjust window titlebar / window frame color to application theme Product: kwin Version: 5.8.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: jbev_kdebugs...@refining-linux.org I don't know if this is possible, but it would be great if Kwin could automatically adjust the titlebar/window frame color to an application's color scheme. Programs with dark KDE color schemes (such as Krita) look pretty awful with bright window borders. This can be fixed by adding windows rules for changing the window color scheme, but it would be better if Kwin could do that automatically. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 370612] New: Artifacts when dragging maximized (wobbly) windows to different screen
https://bugs.kde.org/show_bug.cgi?id=370612 Bug ID: 370612 Summary: Artifacts when dragging maximized (wobbly) windows to different screen Product: kwin Version: 5.8.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: jbev_kdebugs...@refining-linux.org When I drag a maximized window to another screen with the "Wobbly Windows" effect turned on, weird flickering artifacts are shown on the original screen. Sometimes these are just a few pixels, sometimes they show large parts of the window. This does not happen when dragging non-maximized windows. The attached screenshot shows a quite extreme example which I could only achieve with Chrome and the "Use system titlebar and borders" setting turned off (with that setting turned on, artifacts are usually less dramatic). However, some artifacts can also be produced with other applications such as Krita. Using proprietary nvidia driver and TwinView. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 370612] Artifacts when dragging maximized (wobbly) windows to different screen
https://bugs.kde.org/show_bug.cgi?id=370612 --- Comment #1 from Janek Bevendorff --- Created attachment 101552 --> https://bugs.kde.org/attachment.cgi?id=101552&action=edit Screenshot -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 370615] New: Cannot delete SMTP accounts
https://bugs.kde.org/show_bug.cgi?id=370615 Bug ID: 370615 Summary: Cannot delete SMTP accounts Product: kmail2 Version: 5.3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: jbev_kdebugs...@refining-linux.org SMTP accounts in Settings->Accounts->Sending cannot be deleted. When clicking the "Remove" button, existing accounts are simply cleared and renamed to "Unnamed". Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 370617] New: SMTP config dialog uses wrong default port
https://bugs.kde.org/show_bug.cgi?id=370617 Bug ID: 370617 Summary: SMTP config dialog uses wrong default port Product: kmail2 Version: 5.3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: jbev_kdebugs...@refining-linux.org The SMTP configuration dialog suggests port 25 as default. This wrong. Port 25 is supposed to be the relay port, not the submission port. The correct port is 587. Many SMTP servers also accept mail submissions via port 25, but only for compatibility reasons. Some servers even block port 25 completely. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 370618] New: Cannot sync large amounts of mail through IMAP
https://bugs.kde.org/show_bug.cgi?id=370618 Bug ID: 370618 Summary: Cannot sync large amounts of mail through IMAP Product: Akonadi Version: 5.3.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: grave Priority: NOR Component: IMAP resource Assignee: chrig...@fastmail.fm Reporter: jbev_kdebugs...@refining-linux.org CC: kdepim-b...@kde.org, vkra...@kde.org I've really been wanting to switch from Thunderbird to KMail for years now, but every time I try it, I run into the same issue again: Akonadi can't cope with my mail account. The raw maildir on the server has a size of 1.4GB and consists of thousands of mails, many with attachments. There are actually quite a few reports of hangs and freezes here, but I'm not quite sure whether any of them is related. My problem is: Akonadi starts syncing and then suddenly hangs and nothing's happening anymore. When I turn off "Download all mails for offline use", it sometimes gets to 100%, but instead of finishing, it continues with 110% until something like 180%. I also can't see any mails in KMail until Akonadi has finished the full sync (which can take a long time or doesn't happend at all). Reproducible: Always Steps to Reproduce: 1. Set up a mail account with > 1GB of mail 2. Try to sync it via Akonadi IMAP resource 3. Get frustrated Actual Results: KMail is completely useless because I can't get Akonadi to fetch mails from my IMAP account. Expected Results: Akonadi shouldn't hang, no matter how big the maildir behind the IMAP account is and it houldn't be necessary to restart Akonadi a hundred times to get through all the mails. Akonadi should also deliver already synced mails to KMail immediately, so that I don't have to wait for the full sync to finish before I can see any mail. A full sync, especially with download for offline use can take minutes or even hours. However, fetching just the mail headers is fast and should enable KMail to list mails within seconds, even for very large maildirs (Thunderbird actually manages to do that). It should also be possible to move mails to the front of the download queue, so I can click a mail in KMail during sync to show its contents immediately. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 370617] SMTP config dialog uses wrong default port
https://bugs.kde.org/show_bug.cgi?id=370617 --- Comment #2 from Janek Bevendorff --- 467 ist for TLS, but kind of obsolete. The standard port is 587 (usually with STARTTLS) which every server should use these days. But 25 ist definitely wrong, so I strongly disagree that this is a WONTFIX. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 370612] Artifacts when dragging maximized (wobbly) windows to different screen
https://bugs.kde.org/show_bug.cgi?id=370612 --- Comment #3 from Janek Bevendorff --- Sure. https://paste.kde.org/pl2kiokt6 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 370610] Automatically adjust window titlebar / window frame color to application theme
https://bugs.kde.org/show_bug.cgi?id=370610 --- Comment #3 from Janek Bevendorff --- Alright. I'll open this as a bug for Krita then. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 49719] breakpoints are not visible in editor window
https://bugs.kde.org/show_bug.cgi?id=49719 Janek Bevendorff changed: What|Removed |Added CC||jbev_kdebugs_01@refining-li ||nux.org Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 Version|unspecified |5.0.1 --- Comment #2 from Janek Bevendorff --- Sorry to reopen this, but I'd like to suggest enabling this setting by default. It took me about 10 minutes to figure out how to set breakpoints properly and another 30 minutes to learn about the "icon border". In 99% of the IDEs out there it is a common UI pattern to click on the line number gutter to set a break point which adds a red dot there. In KDevelop this didn't work. So I looked for a different way and finally found it in the right click context menu. However, it didn't seem to do anything. The reason why I though it didn't work at first was that the line highlight is so subtle that I completely overlooked it (talking about Breeze Dark theme, with default it's a little better). Then I thought "why the heck can't I just click the gutter" and wanted to open a feature request here and finally found this issue after a long thorough search. Only then I learned about the existence of "icon border" feature or what it is supposed to do (even if I knew it, I couldn't tell what it does from the name). I therefore suggest activating this feature by default. I don't see a reason why it should be disabled. I would also suggest changing the weird pixel emoji to a conventional red dot. It's clear what a red dot means (every other IDE uses red dots) and it stands out more and is less likely to be overlooked. With the default editor theme, both line highlight and icon are more or less visible, but with dark themes, they are both really hard to see. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 49719] breakpoints are hard to see with dark themes, icon border should be enabled by default
https://bugs.kde.org/show_bug.cgi?id=49719 Janek Bevendorff changed: What|Removed |Added Summary|breakpoints are not visible |breakpoints are hard to see |in editor window|with dark themes, icon ||border should be enabled by ||default -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 370715] New: C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715
Bug ID: 370715
Summary: C++/boost indentation style is broken with automatic
closing brackets
Product: kdevelop
Version: 5.0.1
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: ident
Assignee: kdevelop-bugs-n...@kde.org
Reporter: jbev_kdebugs...@refining-linux.org
When automatic placement of closing brackets is enabled, the C++/boost
indentation style is broken.
When I enter an opening brace for a function body, it is completed with a
semicolon before the cursor instead of a closing brace after the cursor.
This can be tested with the following code (I denoted the current cursor
position with a pipe character |):
class Foo
{
public:
void foo()
|
};
Now when I type an opening brace after foo(), the result is this:
class Foo
{
public:
void foo()
{;|
};
although it should be this:
class Foo
{
public:
void foo()
{
|
}
};
With plain C style, it works, however then the indentation is wrong as both the
opening and the closing brace are automatically unindented:
class Foo
{
public:
void foo()
{
|
}
};
Reproducible: Always
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715 Janek Bevendorff changed: What|Removed |Added Component|ident |code completion -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715 --- Comment #2 from Janek Bevendorff --- What "normal" C++ indenter do you mean? I only have "C style" and "C++/boost style". The former doesn't indent class methods properly and the latter is broken. Also for some reason all new files use the C-style indenter, even when set to C++ mode until I close and reopen the file (with "Override Kate indentation mode" turned on). -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 370716] New: Automatically overwrite closing brackets
https://bugs.kde.org/show_bug.cgi?id=370716 Bug ID: 370716 Summary: Automatically overwrite closing brackets Product: kdevelop Version: 5.0.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: jbev_kdebugs...@refining-linux.org This is a feature which all JetBrains IDEs (IntelliJ IDEA, CLion, PyCharm etc.) have and which is super useful and makes working with automatically inserted closing brackets a lot more fun. When I type something like void foo(int bar|) (with | showing the current cursor position and the closing bracket automatically inserted), I usually need to move my finger to the right arrow key to skip the closing bracket. However, in IntelliJ I can simply type ")" instead which does the same, so I have void foo(int bar)| In KDevelop, however, I end up with void foo(int bar)|) Would be great if this could be implemented. This also makes it easy to not get lost in too many consecutive closing brackets, because you simply type ")" until the editor tries to insert a new one and then you know you reached the end (which isn't always obvious just with highlighting). Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715
--- Comment #4 from Janek Bevendorff ---
Well, yeah, what I said. I want to have
class Foo
{
public:
void foo()
{
|
}
};
but with the C-style indenter I end up with
class Foo
{
public:
void foo()
{
|
}
};
even when I initially was at the correct indentation level, i.e. there:
class Foo
{
public:
void foo()
{|
};
As soon as I hit enter, the braces are automatically unindented.
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715
--- Comment #6 from Janek Bevendorff ---
Either there or in the C++/boost indenter. All other indenters seem to work
fine with the automatic brace placement, but either don't indent my cursor
inside the braces, i.e.,
class Foo
{
public:
void foo()
{
|}
};
or do some very funky stuff such as
class Foo
{
public:
void foo()
{
|}
};
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 370716] Automatically overwrite closing brackets
https://bugs.kde.org/show_bug.cgi?id=370716 --- Comment #2 from Janek Bevendorff --- I think that's what IntelliJ does. It always "eats" the braces and brackets as long as there are corresponding opening ones. It doesn't care if they were already there, just typed by the user or inserted automatically. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 370716] Automatically overwrite closing brackets
https://bugs.kde.org/show_bug.cgi?id=370716 --- Comment #4 from Janek Bevendorff --- I have to say, there are some corner cases where bracket eating has already annoyed me in IntelliJ. This is mostly, when revising brackets within brackets. But generally, this happens a lot less and is a lot less annoying than always ending with excess brackets because I'm too lazy to move my hand over to the arrow keys. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715
--- Comment #7 from Janek Bevendorff ---
Actually, what I said is not quite correct. Not the enter key unindents the
braces, but the completion of the closing brace. As soon as I type "{", the
line gets unindented:
class Foo
{
public:
void foo()
|
};
entering "{" leads to
class Foo
{
public:
void foo()
{|}
};
and then enter behaves correctly, but the line is already unindented:
class Foo
{
public:
void foo()
{
|
}
};
If the braces are already there and I just hit enter, they stay in place:
class Foo
{
public:
void foo()
{|}
};
now enter results in the desired
class Foo
{
public:
void foo()
{
|
}
};
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 370716] Automatically overwrite closing brackets
https://bugs.kde.org/show_bug.cgi?id=370716 --- Comment #6 from Janek Bevendorff --- It somehow also doesn't eat brackets when a new pair has been inserted within. So foo(bar(|)) will result in foo(bar())|) when typing ")" twice. The inner bracket is overwritten, but the outer bracket is not which is super annoying. Generally, I don't think it would be a problem to just consume any closing brackets as long as they have a corresponding opening bracket. You can a lot more than you lose. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 370716] Automatically overwrite closing brackets
https://bugs.kde.org/show_bug.cgi?id=370716 --- Comment #8 from Janek Bevendorff --- It should have the same logic as the already existing bracket matching/highlighting. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 371002] White text selection in Chrome when browser window loses focus
https://bugs.kde.org/show_bug.cgi?id=371002 Janek Bevendorff changed: What|Removed |Added Version|5.7.95 |5.8.0 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 371002] New: White text selection in Chrome when browser window loses focus
https://bugs.kde.org/show_bug.cgi?id=371002 Bug ID: 371002 Summary: White text selection in Chrome when browser window loses focus Product: Breeze Version: 5.7.95 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: gtk theme Assignee: scionicspec...@gmail.com Reporter: jbev_kdebugs...@refining-linux.org When I select text in Chrome and then click somewhere else on my desktop so that the Chrome window loses the focus, the formerly blue text selection becomes almost white which makes it impossible to read the selected (and also white) text. Other applications are not affected (although their inactive selection color is also brighter than the active selection color). For some reason, bugs.kde.org is one of the few websites that don't have this problem with text selection. However, the problem does appear with selection input fields (such as the Component and the Version fields in the guided editor or the advanced search). When they lose focus, the selection becomes unreadable. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715
--- Comment #13 from Janek Bevendorff ---
I downloaded a KDE Neon ISO to test this in KWrite and make sure it's
reproducible on other systems. I can indeed reproduce both issues:
C++/boost inserting {; instead of {} and C unindenting the line.
BTW C indenter also indents incorrectly in if statements when you want
the brace to be in its own line.
When I have this code
class X
{
private:
void foo()
{
if (true) |
}
};
and press enter, I get
class X
{
private:
void foo()
{
if (true)
|
}
};
which is okay. But when I type an opening brace, I get
class X
{
private:
void foo()
{
if (true)
{|}
}
};
This can't even be corrected by pressing Ctrl+Z. The unindentation for
the method foo() can be corrected this way, but when I press Ctrl+Z
here, I end up with
class X
{
private:
void foo()
{
if (true)
{|}
}
};
When I have the opening braces on the same line as the method or if
condition header, indentation works as expected.
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715
--- Comment #14 from Janek Bevendorff ---
I played a little with the ktexteditor code. The culprit for the C-style
indenter is this part (line 774):
} else if (firstPos == column - 1 && c == '}') {
var indentation = findLeftBrace(line, firstPos);
if (indentation == -1)
indentation = -2;
return indentation;
}
When I manually enter "{}", then firstPos is 4 and column is 6. However,
when using automatic bracket completion, my cursor is at 5, so the
condition is true and findLeftBrace() is called which retrieves a cursor
to the preceding brace like that:
var cursor = document.anchor(line, column, '{');
But since the cursor is before the insert position, this always results
in a (1, 0) cursor and therefore always unindents the line. My fix would
be to extend the initial check with one more condition:
} else if (firstPos == column - 1 && c == '}' &&
document.charAt(line, firstPos) == '}') {
This would simply check if the inserted character is actually where the
cursor is. If not, it was probably inserted automatically.
The C++/boost indenter seems to be a lot more complex and I haven't
looked into that issue yet.
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715 --- Comment #16 from Janek Bevendorff --- I can't get Kate (and therefore the editor) to respect the auto-brackets on modeline. Any tips? -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 371008] New: KDevelop crashes when reloading file
https://bugs.kde.org/show_bug.cgi?id=371008 Bug ID: 371008 Summary: KDevelop crashes when reloading file Product: kdevelop Version: 5.0.1 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: jbev_kdebugs...@refining-linux.org Application: kdevelop (5.0.1) Qt Version: 5.7.0 Frameworks Version: 5.27.0 Operating System: Linux 4.8.1-1-ARCH x86_64 Distribution: "Arch Linux" -- Information about the crash: KDevelop tends to crash when files were modified externally. I experience this most often when I right click on a file in the project explorer and select Git->Revert. This can crash KDevelop when the file reloads. The crash can be reproduced sometimes. -- Backtrace: Application: KDevelop (kdevelop), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f1e8e86c800 (LWP 2123))] Thread 20 (Thread 0x7f1e07042700 (LWP 12917)): #0 0x7f1e8b67a48d in poll () at /usr/lib/libc.so.6 #1 0x7f1e82f66786 in () at /usr/lib/libglib-2.0.so.0 #2 0x7f1e82f6689c in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #3 0x7f1e8bf9c72b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #4 0x7f1e8bf4623a in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #5 0x7f1e8bd690f3 in QThread::exec() () at /usr/lib/libQt5Core.so.5 #6 0x7f1e8bd6dd78 in () at /usr/lib/libQt5Core.so.5 #7 0x7f1e84f52454 in start_thread () at /usr/lib/libpthread.so.0 #8 0x7f1e8b6837df in clone () at /usr/lib/libc.so.6 Thread 19 (Thread 0x7f1de37fe700 (LWP 12916)): #0 0x7f1e82fabdd4 in g_mutex_unlock () at /usr/lib/libglib-2.0.so.0 #1 0x7f1e82f6673a in () at /usr/lib/libglib-2.0.so.0 #2 0x7f1e82f6689c in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #3 0x7f1e8bf9c72b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #4 0x7f1e8bf4623a in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #5 0x7f1e8bd690f3 in QThread::exec() () at /usr/lib/libQt5Core.so.5 #6 0x7f1e8bd6dd78 in () at /usr/lib/libQt5Core.so.5 #7 0x7f1e84f52454 in start_thread () at /usr/lib/libpthread.so.0 #8 0x7f1e8b6837df in clone () at /usr/lib/libc.so.6 Thread 18 (Thread 0x7f1de3fff700 (LWP 2648)): #0 0x7f1e84f5810f in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f1e7f83cac4 in () at /usr/lib/libQt5Script.so.5 #2 0x7f1e7f83cb09 in () at /usr/lib/libQt5Script.so.5 #3 0x7f1e84f52454 in start_thread () at /usr/lib/libpthread.so.0 #4 0x7f1e8b6837df in clone () at /usr/lib/libc.so.6 Thread 17 (Thread 0x7f1e114d1700 (LWP 2251)): #0 0x7f1e8b6764ed in read () at /usr/lib/libc.so.6 #1 0x7f1e82faaa10 in () at /usr/lib/libglib-2.0.so.0 #2 0x7f1e82f66235 in g_main_context_check () at /usr/lib/libglib-2.0.so.0 #3 0x7f1e82f66724 in () at /usr/lib/libglib-2.0.so.0 #4 0x7f1e82f6689c in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #5 0x7f1e8bf9c72b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #6 0x7f1e8bf4623a in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #7 0x7f1e8bd690f3 in QThread::exec() () at /usr/lib/libQt5Core.so.5 #8 0x7f1e8984a84f in () at /usr/lib/libKDevPlatformLanguage.so.10 #9 0x7f1e8bd6dd78 in () at /usr/lib/libQt5Core.so.5 #10 0x7f1e84f52454 in start_thread () at /usr/lib/libpthread.so.0 #11 0x7f1e8b6837df in clone () at /usr/lib/libc.so.6 Thread 16 (Thread 0x7f1e22b5c700 (LWP 2247)): #0 0x7f1e8b690024 in __libc_enable_asynccancel () at /usr/lib/libc.so.6 #1 0x7f1e8b67a482 in poll () at /usr/lib/libc.so.6 #2 0x7f1e82f66786 in () at /usr/lib/libglib-2.0.so.0 #3 0x7f1e82f6689c in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #4 0x7f1e8bf9c72b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #5 0x7f1e8bf4623a in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #6 0x7f1e8bd690f3 in QThread::exec() () at /usr/lib/libQt5Core.so.5 #7 0x7f1e8bd6dd78 in () at /usr/lib/libQt5Core.so.5 #8 0x7f1e84f52454 in start_thread () at /usr/lib/libpthread.so.0 #9 0x7f1e8b6837df in clone () at /usr/lib/libc.so.6 Thread 15 (Thread 0x7f1e237fe700 (LWP 2229)): #0 0x7f1e84f5810f in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f1e8bd6ec2b in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #2 0x7f1e806701c0 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () at /usr/lib/libKF5ThreadWeaver.so.5 #3 0x7f1e80674988 in () at /usr/lib/libK
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715 --- Comment #17 from Janek Bevendorff --- Okay, I fixed it in C++/boost style as well. However, that indenter is overall a little broken. The only effect auto brackets had on it was that it inserted semicolons after opening braces. I fixed the semicolons and some over-indentation after condition or loop headers, but not the rest. It's not generating bullshit code anymore, but getting it to not ignore automatically inserted closing braces seems to be beyond reasonable effort. However, I still have the problem, that I can't produce proper unit tests, because the auto bracket modeline seems to be ignored. Otherwise I'd already submit the patches to Phabricator. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715 --- Comment #19 from Janek Bevendorff --- Created attachment 101608 --> https://bugs.kde.org/attachment.cgi?id=101608&action=edit Indenter Patch Yes, sure, I can append it here. The patch I uploaded includes the failing unit tests (because the auto bracket modeline) is ignored and is therefore not ready for merging yet. Since I couldn't leave it alone, I also experimented a little more with the C++ indenter. It had some functionality to consume characters to allow some sort of overwrite mode for brackets. That's pretty useful, but it completely breaks auto brackets. With a resolution for bug #370716 this should be a feature of the editor component anyway. So I removed that. It causes one unit test which tests comma consumption to fail, but not in a way that I would say the new behavior is buggy. With this consumption feature removed and a few more fixes to semicolon placement, auto brackets seem to work properly even with the C++ indenter. What do you think? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 371042] New: Contrast issues with Breeze Dark Schema
https://bugs.kde.org/show_bug.cgi?id=371042 Bug ID: 371042 Summary: Contrast issues with Breeze Dark Schema Product: frameworks-ktexteditor Version: 5.27.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: k...@jbev.net Created attachment 101609 --> https://bugs.kde.org/attachment.cgi?id=101609&action=edit Screenshot The Breeze Dark Schema has some contrast issues. Comments are pretty hard to read in general, but with highlighting for the current line, it becomes extra hard. Additionally, the highlighting of email addresses (and other stuff between <…>) inside comments is rendered as black text, making it almost impossible to read. I added a screenshot demonstrating these contrast issues. -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 358776] per-project tab colors not updated on palette change
https://bugs.kde.org/show_bug.cgi?id=358776 Janek Bevendorff changed: What|Removed |Added CC||k...@jbev.net --- Comment #5 from Janek Bevendorff --- Not sure if it's worth reopening for this, but the file tabs still need a restart of KDevelop after changing the color scheme. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 371042] Contrast issues with Breeze Dark Schema
https://bugs.kde.org/show_bug.cgi?id=371042 --- Comment #1 from Janek Bevendorff --- I would suggest making the comment color a little lighter and highlight all docblock comments in green instead of gray. Certain tags in doc comments are already green, why not make everything that color to distinguish doc comments from normal comments (similar to IntelliJ's Darcula theme)? Tags could then either be bold, italics or just a little brighter in color. The same could work for the stuff within angle brackets (instead of unreadable black). -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715 --- Comment #21 from Janek Bevendorff --- Well, it has tests, but they fail (actually, the C++ ones don't, but only because I haven't adjusted them yet to my latest changes in the indenter which allow for auto brackets). Additionally, one already existing test for the C++ indenter fails now as I said above, but not in a way that would consider buggy. The reason why my tests fail is still that I can't get the test environment to enable auto brackets. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 370715] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715 --- Comment #23 from Janek Bevendorff --- Thanks for the tip. I added a new Q_INVOKABLE to expose setAutoBrackets() to test scripts. The only possible pitfall I see here is that you have to explicitly disable auto brackets again at the end of your test, because the config is taken over to successive tests. I hope this won't backfire should "auto brackets on" become a default setting at some point. But in that case most tests would fail anyway, so not a big deal I guess. I submitted a patch with all the changes to Phabricator: https://phabricator.kde.org/D3104 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 371197] New: Running certain unit tests freezes KDevelop and Plasma panels
https://bugs.kde.org/show_bug.cgi?id=371197 Bug ID: 371197 Summary: Running certain unit tests freezes KDevelop and Plasma panels Product: kdevelop Version: 5.0.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: k...@jbev.net The vimode_modes unit test from the KTextEditor sources (from ktexteditor/autotests/src/vimode) freezes both KDevelop (the whole application) as well as my Plasma panels (not all of Plasma, though, just the panels) when run from the Unit Test tool panel. I don't know why this is (hell, I don't even know what exactly the test does), but this behavior is reproducible every time. Running the vimode_modes executable as standalone from the terminal works fine, though. I generally have the impression, that certain unit tests interfere with the responsiveness of the KDevelop UI. The vimode_keys test also freezes KDevelop for a couple of seconds, but then finishes and puts KDevelop back in a usable state. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 371197] Running certain unit tests freezes KDevelop and Plasma panels
https://bugs.kde.org/show_bug.cgi?id=371197 --- Comment #2 from Janek Bevendorff --- I'm not sure if this stacktrace is really helpful. There is no stack trace until I try to send it a SIGINT which kdevelop ignores. I can only kill it with SIGKILL. BTW I realized that not only Plasma panels are frozen, but also, e.g., Dolphin. Here's the stacktrace: Thread 1 "kdevelop" received signal SIGINT, Interrupt. 0x703800b3 in select () from /usr/lib/libc.so.6 #0 0x703800b3 in select () at /usr/lib/libc.so.6 #1 0x7fffd982a351 in () at /usr/lib/libQt5XcbQpa.so.5 #2 0x7fffd982a96f in () at /usr/lib/libQt5XcbQpa.so.5 #3 0x7fffd982c438 in () at /usr/lib/libQt5XcbQpa.so.5 #4 0x716c66ab in QInternalMimeData::formats() const () at /usr/lib/libQt5Gui.so.5 #5 0x7fffd982c8e0 in () at /usr/lib/libQt5XcbQpa.so.5 #6 0x716c6936 in QInternalMimeData::retrieveData(QString const&, QVariant::Type) const () at /usr/lib/libQt5Gui.so.5 #7 0x7118d02b in () at /usr/lib/libQt5Core.so.5 #8 0x7118e16d in QMimeData::data(QString const&) const () at /usr/lib/libQt5Core.so.5 #9 0x75346a71 in KIO::isClipboardDataCut(QMimeData const*) () at /usr/lib/libKF5KIOWidgets.so.5 #10 0x70041f5b in KFilePreviewGenerator::Private::applyCutItemEffect(KFileItemList const&) () at /usr/lib/libKF5KIOFileWidgets.so.5 #11 0x70044de8 in KFilePreviewGenerator::Private::updateCutItems() () at /usr/lib/libKF5KIOFileWidgets.so.5 #12 0x71192659 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib/libQt5Core.so.5 #13 0x716c28e9 in QClipboard::emitChanged(QClipboard::Mode) () at /usr/lib/libQt5Gui.so.5 #14 0x7fffd982abb0 in () at /usr/lib/libQt5XcbQpa.so.5 #15 0x7fffd9830d98 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () at /usr/lib/libQt5XcbQpa.so.5 #16 0x7fffd98318a5 in QXcbConnection::processXcbEvents() () at /usr/lib/libQt5XcbQpa.so.5 #17 0x711934b9 in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5 #18 0x71e46e0c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #19 0x71e4e581 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #20 0x71166de0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #21 0x7116956d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib/libQt5Core.so.5 #22 0x711bb303 in () at /usr/lib/libQt5Core.so.5 #23 0x7fffe849b587 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #24 0x7fffe849b7f0 in () at /usr/lib/libglib-2.0.so.0 #25 0x7fffe849b89c in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #26 0x711bb70f in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #27 0x7116523a in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #28 0x7116d73c in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5 #29 0x0040f1f5 in main () -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 351818] Shortcuts are not working to control the volume
https://bugs.kde.org/show_bug.cgi?id=351818 Janek Bevendorff changed: What|Removed |Added Version|unspecified |5.7.0 Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED CC||jbev_kdebugs_01@refining-li ||nux.org --- Comment #4 from Janek Bevendorff --- Still present in 5.7.0. I was really happy to see that it finally supports per-application volume. But then I realized that it still doesn't react to any volume key presses on my keyboard or mouse which is a no-go. Missing media key support and no per-application volume controls make plasma-pa practically useless (for my use case at least). One of these features has been added now, but the other one is still missing. So until this is fixed also, I have to continue using KMix. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 351818] Shortcuts are not working to control the volume
https://bugs.kde.org/show_bug.cgi?id=351818 --- Comment #5 from Janek Bevendorff --- Since I was already on it, I tried unsetting and then resetting all the media key bindings in the system settings under Shortcuts->Global Keyboard Shortcuts->KMix (Kmix wasn't running at that time). After this procedure it's working now, so I uninstalled KMix (which also changed the component name in the settings from "Kmix" to "Audio Volume"). Then I also realized that Chrome (and therefore Google Play Music) suddenly wasn't receiving Forward/Back/Play/Pause keys anymore. Setting the shortcuts for these under the "Media Controller" KDE component to "None" also fixed that issue, though. I guess this report can be closed then. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 362531] Plasma panels are not transparent after login
https://bugs.kde.org/show_bug.cgi?id=362531 Janek Bevendorff changed: What|Removed |Added CC||jbev_kdebugs_01@refining-li ||nux.org -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 365572] New: Use kdialog for selecting save location
https://bugs.kde.org/show_bug.cgi?id=365572 Bug ID: 365572 Summary: Use kdialog for selecting save location Product: Spectacle Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: jbev_kdebugs...@refining-linux.org Spectacle uses the built-in Qt file picker instead of the one provided by the system (i.e. kdialog). It's missing a lot of features, is therefore cumbersome to use and doesn't integrate well with the rest of the desktop. As part of the KDE family, Spectacle should really use the provided platform tools. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 365573] New: Remember rectangular region mask
https://bugs.kde.org/show_bug.cgi?id=365573 Bug ID: 365573 Summary: Remember rectangular region mask Product: Spectacle Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: jbev_kdebugs...@refining-linux.org ksnapshot used to remember the rectangle selection that was drawn when taking snapshots of a screen region. This was really useful when taking multiple screenshots in a row of the same region. It would be great if Spectacle remembered the last drawn rectangular region, too. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 365573] Remember rectangular region mask
https://bugs.kde.org/show_bug.cgi?id=365573 Janek Bevendorff changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Janek Bevendorff --- Never mind. I just found an option for that. Not sure though, why this is not the default behavior. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 361053] Center “click anywhere” message on screen instead of entire virtual desktop
https://bugs.kde.org/show_bug.cgi?id=361053 Janek Bevendorff changed: What|Removed |Added CC||jbev_kdebugs_01@refining-li ||nux.org -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 361053] Center “click anywhere” message on screen instead of entire virtual desktop
https://bugs.kde.org/show_bug.cgi?id=361053 Janek Bevendorff changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 344969] Shortcut configuration for Folder View actions not handled by standard keys
https://bugs.kde.org/show_bug.cgi?id=344969 Janek Bevendorff changed: What|Removed |Added Version|5.4.2 |5.7.1 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 365570] Systray icons are big and pixelated after update to 5.7.1
https://bugs.kde.org/show_bug.cgi?id=365570 Janek Bevendorff changed: What|Removed |Added Ever confirmed|0 |1 Keywords||regression Status|UNCONFIRMED |CONFIRMED CC||jbev_kdebugs_01@refining-li ||nux.org --- Comment #2 from Janek Bevendorff --- I also have huge icons with no padding around them (see attached screenshot, compare it to the Reshift Control widget to the left or the clock to the right) since 5.7.1. I assume this is a regression introduced by the fix for issue #364431. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 365570] Systray icons are big and pixelated after update to 5.7.1
https://bugs.kde.org/show_bug.cgi?id=365570 --- Comment #3 from Janek Bevendorff --- Created attachment 100049 --> https://bugs.kde.org/attachment.cgi?id=100049&action=edit Huge systray icons, no padding -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 362531] Plasma panels are not transparent after login
https://bugs.kde.org/show_bug.cgi?id=362531 Janek Bevendorff changed: What|Removed |Added Version|5.6.3 |5.7.1 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 344969] Shortcut configuration for Folder View actions not handled by standard keys
https://bugs.kde.org/show_bug.cgi?id=344969 --- Comment #29 from Janek Bevendorff --- I can also confirm the slow move to trash. It has annoyed me ever since the new Folder widget was introduced. The bug report is for Konqueror, however. Maybe someone should update that. I didn't report it here because after the upgrade to 5.7.1 yesterday, it seemed to work. But when I booted up my computer again today, the issue was back. Moving a file to the trash takes about 5 seconds and produces an annoying desktop notification while it's in progress. I would love to finally see the folder plasmoid being fixed. It's not in a very usable state right now. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 365572] Use kdialog for selecting save location
https://bugs.kde.org/show_bug.cgi?id=365572 --- Comment #2 from Janek Bevendorff --- What filter bug are you talking about? Bug 319502? That's the only bug report I can find about filters and I'm not even sure if that's really a kdialog bug or rather a PyQt4 bug (and in PyQt5 there isn't even a method QFileDialog.getOpenFileNameAndFilter()). The file dialog used by Spectacle is just utterly useless. It doesn't even show file/folder icons which makes it really hard to tell files and folders apart. All my bookmarks etc. are also missing. It's about as ugly and hard to use the the GtkFileChooserDialog (which IMHO is one of the ugliest pices of any GUI framework ever produced). I'm not quite sure what filter bug you mean, but I would glady accept some issues with file filters in exchange for a proper file dialog. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 344969] Shortcut configuration for Folder View actions not handled by standard keys
https://bugs.kde.org/show_bug.cgi?id=344969 --- Comment #33 from Janek Bevendorff --- It's always been 5 seconds for me on new files, sometimes a little more. I haven't experienced a minute or more but trust me, 5 seconds are annoying enough. And the desktop notification is annoying me too, especially because it doesn't really go away once the file is in the trash. I still always see a circle with a "1" in it in my tray until I click it away. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 344969] Shortcut configuration for Folder View actions not handled by standard keys
https://bugs.kde.org/show_bug.cgi?id=344969 --- Comment #35 from Janek Bevendorff --- No, I mean that moving a file to the trash takes that long. While it's being moved, I see a progress notification and then after that a persistent notification "Moving: finished" which stays as a (1) indicator in the system tray until I manually click it away. It usually only happens the first time I move something to the trash. After that the move is instant (most of the time at least). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 344969] Shortcut configuration for Folder View actions not handled by standard keys
https://bugs.kde.org/show_bug.cgi?id=344969 --- Comment #37 from Janek Bevendorff --- No, I can reproduce it at least once after a fresh reboot. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 364147] Too big window preview when hovering mouse on task manager
https://bugs.kde.org/show_bug.cgi?id=364147 Janek Bevendorff changed: What|Removed |Added CC||jbev_kdebugs_01@refining-li ||nux.org --- Comment #8 from Janek Bevendorff --- Created attachment 100111 --> https://bugs.kde.org/attachment.cgi?id=100111&action=edit Blurry app icon Since you said that you're reworking tooltips anyway (I would love that), I don't create a new issue for that and just add it as a remark here: it would be nice if you could also make them prettier. There are two major issues with the current look and feel: a) no animations which makes tooltips feel like compositing is turned off b) blurry (i.e. scaled-up) application icons when windows are minimized (see attached screenshot) Further explanation of b): icons with higher resolution definitely exist as I can see when I make the panel bigger. The tooltip still uses a scaled-down version, though. This does not happen for all applications, though. KDE apps (maybe Qt apps in general? Not sure) seem to show icons at correct sizes when windows are minimized. But icons of GTK apps (such as Chrome or Gimp) are usually scaled up and look blurry. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 364147] Too big window preview when hovering mouse on task manager
https://bugs.kde.org/show_bug.cgi?id=364147 --- Comment #10 from Janek Bevendorff --- I'm using 5.7.1 and I tested it with Chrome and Gimp (as written above). However, Gimp also uses a different icon for the taskbar entry (provided by the Breeze icon theme, I guess) than in the tooltip (standard Gimp icon). Thunderbird seems to show the tooltip icon at a correct size. But still, even if it's just Chrome: it's such a widely-used application that there should be a fix/workaround even if it's not really KDE's fault. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 364147] Too big window preview when hovering mouse on task manager
https://bugs.kde.org/show_bug.cgi?id=364147 --- Comment #11 from Janek Bevendorff --- Created attachment 100112 --> https://bugs.kde.org/attachment.cgi?id=100112&action=edit Blurry Icons 2 I attached a new screenshot showing Gimp and Chrome and a very big panel. Both apps have icons with correct resolution on the panel, but both show blurry icons in their tooltips. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 364147] Too big window preview when hovering mouse on task manager
https://bugs.kde.org/show_bug.cgi?id=364147 --- Comment #21 from Janek Bevendorff --- I agree that showing a big icon is not really helpful, especially not because there is already an icon right next to the title. A fine fix for me would also be to just make the tooltip smaller and only show the title (+ the smaller icon on the right-hand side). But having a big blurry icon whose native resolution is way too low is just a no-go. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 355540] Tooltips color wrong in gtk applications
https://bugs.kde.org/show_bug.cgi?id=355540 Janek Bevendorff changed: What|Removed |Added Version|5.5.95 |5.7.2 CC||jbev_kdebugs_01@refining-li ||nux.org -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 331707] Moving a file to trash is extremely slow
https://bugs.kde.org/show_bug.cgi?id=331707 --- Comment #7 from Janek Bevendorff --- (I tried it in Dolphin, though, not Konqueror) -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 331707] Moving a file to trash is extremely slow
https://bugs.kde.org/show_bug.cgi?id=331707 Janek Bevendorff changed: What|Removed |Added CC||jbev_kdebugs_01@refining-li ||nux.org --- Comment #6 from Janek Bevendorff --- I just tried it on 5.7.2: Created new file, pressed DEL and it still took about 7 seconds to move this file to the trash. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 331707] Moving a file to trash is extremely slow
https://bugs.kde.org/show_bug.cgi?id=331707 --- Comment #10 from Janek Bevendorff --- I don't think this is a bug in the folder plasmoid as it happens in Dolphin, too. Probably a Dolphin or Kio bug (but I'm not an expert when it comes to KDE's architecture). -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 369633] New: Allow to change UI colors, not just editor theme
https://bugs.kde.org/show_bug.cgi?id=369633 Bug ID: 369633 Summary: Allow to change UI colors, not just editor theme Product: kate Version: 16.08 Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: jbev_kdebugs...@refining-linux.org Kate ships with a nice and nifty Breeze Dark theme nowadays, but it still doesn't allow to change the UI color theme (like Krita does). I understand that people want consistency and I could simply change my desktop theme, but I don't want everything on my desktop to be dark. I generally prefer the normal bright Breeze theme, but certain applications at which I look for hours and hours such as code editors and IDEs have to be dark (and not only the editor component but the full application). It would be great if Kate allowed my to change the application theme together with the editor theme. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 369635] Allow to change UI colors, not just editor theme
https://bugs.kde.org/show_bug.cgi?id=369635 Janek Bevendorff changed: What|Removed |Added Version|unspecified |5.0.1 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 369635] New: Allow to change UI colors, not just editor theme
https://bugs.kde.org/show_bug.cgi?id=369635 Bug ID: 369635 Summary: Allow to change UI colors, not just editor theme Product: kdevelop Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: UI: general Assignee: kdevelop-bugs-n...@kde.org Reporter: jbev_kdebugs...@refining-linux.org I reported this already as bug #369633 for Kate, but since only the editor component is shared, but not the actual UI, I thought I might file this feature request for KDevelop again. Please close it if you think it's redundant. KDevelop now has a Breeze Dark theme which is provided by the Kate editor component. However, the overall UI still has the global desktop theme. It would be great if KDevelop allowed me to change the UI theme independent of my global desktop settings (like Krita does). I generally prefer the bright Breeze theme, but I can't work with an editor for hours that has such a bright theme. Using a dark editor theme with a bright UI results in really high contrast and doesn't go much easier on the eye than an overall bright editor theme. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 370715] [PATCH] C++/boost indentation style is broken with automatic closing brackets
https://bugs.kde.org/show_bug.cgi?id=370715 --- Comment #26 from Janek Bevendorff --- Thanks. I'm a long-term KDE user and contributor to this bug tracker, but haven't really submitted any patches so far. :-) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 371042] Contrast issues with Breeze Dark Schema
https://bugs.kde.org/show_bug.cgi?id=371042 --- Comment #5 from Janek Bevendorff --- That's a little better. I think for normal text it's okay. But the issue with the current line still persists. The current line color is #3f3b51 and that makes comments very hard to read, even with the new color. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 371042] Contrast issues with Breeze Dark Schema
https://bugs.kde.org/show_bug.cgi?id=371042 --- Comment #7 from Janek Bevendorff --- Strange, I had a different color, although I haven't changed anything. With #31363b it's a little better, but not optimal. I would make the current line color darker. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 371042] Contrast issues with Breeze Dark Schema
https://bugs.kde.org/show_bug.cgi?id=371042 --- Comment #9 from Janek Bevendorff --- Yeah, that looks fine. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 370422] kscreenlocker crashes when unlocking the session after resume from s2ram
https://bugs.kde.org/show_bug.cgi?id=370422 Janek Bevendorff changed: What|Removed |Added CC||k...@jbev.net --- Comment #11 from Janek Bevendorff --- I have a similar issue. Since the last update I cannot unlock my session anymore (on the desktop). I try four times and then the lock screen tells me that I have to use loginctl unlock-sessions. When I run kscreenlocker_greet manually, I unfortuantely only get a very useless stack trace and since I'm on arch, it's not that easy to install debug symbols, especially, when I don't really know for what package. #0 0x72df1ad0 in pthread_mutex_lock () from /usr/lib/libpthread.so.0 #1 0x7fffdcdf2e1c in ?? () from /usr/lib/libGLX_nvidia.so.0 #2 0x7fffdcdc9dc8 in ?? () from /usr/lib/libGLX_nvidia.so.0 #3 0x7fffd8806e89 in ?? () from /usr/lib/libEGL.so.1 #4 0x77de9ae8 in _dl_fini () from /lib64/ld-linux-x86-64.so.2 #5 0x73dce990 in __run_exit_handlers () from /usr/lib/libc.so.6 #6 0x73dce9ea in exit () from /usr/lib/libc.so.6 #7 0x73db9298 in __libc_start_main () from /usr/lib/libc.so.6 #8 0x0040946a in ?? () #9 0x7fffe158 in ?? () #10 0x001c in ?? () #11 0x0003 in ?? () #12 0x7fffe512 in ?? () #13 0x7fffe52f in ?? () #14 0x7fffe54c in ?? () #15 0x in ?? () >From the top part I would say this stack trace is different, but who knows... The bottom part, unfortunately, doesn't give any information about which packages need debug symbols. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356841] Plasma-nm applet does not show connection speed
https://bugs.kde.org/show_bug.cgi?id=356841 --- Comment #20 from Janek Bevendorff --- I just checked on my system (Arch Linux, Plasma 5.7.3). When I opened it for the first time, it showed 0B for about 1-2 seconds and then started showing the traffic graph. However, when I closed the applet and reopened it, it was gone and the graph only showed 0B. So apparently, the issue is not resolved in 5.7.3. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356841] Plasma-nm applet does not show connection speed
https://bugs.kde.org/show_bug.cgi?id=356841 --- Comment #22 from Janek Bevendorff --- KDE Frameworks 5.24, Qt 5.7.0, NetworkManager 1.2.4. As I said, I'm using Arch, so all packages are up to date. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 366403] KScreenlocker not unlockable when there are multiple sessions on NFS home
https://bugs.kde.org/show_bug.cgi?id=366403 Janek Bevendorff changed: What|Removed |Added CC||jbev_kdebugs_01@refining-li ||nux.org --- Comment #7 from Janek Bevendorff --- The same thing happens when I update my Arch system (presumably also updating the screen locker) and then lock the screen without restarting the session. It's pretty reproducible in that scenario. All I get then is this message saying "The screen locker is broken and unlocking is not possible anymore…" I think this should be fixed. You can't expect all users to understand this message and follow the instructions every time they update their system. Some don't even have spare VTs anymore so they have to restart the PC and kill their running session. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 278236] Cannot drag file onto chromium upload form input
https://bugs.kde.org/show_bug.cgi?id=278236 Janek Bevendorff changed: What|Removed |Added CC||jbev_kdebugs_01@refining-li ||nux.org Version|unspecified |15.12.1 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353983] Turning off compositing breaks Plasma panel rendering
https://bugs.kde.org/show_bug.cgi?id=353983 Janek Bevendorff changed: What|Removed |Added Version|5.4.1 |5.6.4 -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 364268] krunner puts system under heavy load when compositing is disabled
https://bugs.kde.org/show_bug.cgi?id=364268 Janek Bevendorff changed: What|Removed |Added Summary|krunner puts system under |krunner puts system under |heavy loads when|heavy load when compositing |compositing is disabled |is disabled -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 364268] New: krunner puts system under heavy loads when compositing is disabled
https://bugs.kde.org/show_bug.cgi?id=364268 Bug ID: 364268 Summary: krunner puts system under heavy loads when compositing is disabled Product: krunner Version: 5.6.4 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: m...@vhanda.in Reporter: jbev_kdebugs...@refining-linux.org When playing games, kwin usually automatically disables compositing (and if not I have a window rule for it). At some point I wondered why my gaming performance was so bad. I was playing at about 15 FPS instead of 60-100FPS. Opening htop revealed that krunner was hogging all my CPU cores at 100% until I killed it. I cannot reproduce this behavior on demand, but it has happened ever since. Disabling compositing doesn't directly start this behavior in every case, but it happens quite often. On some days I get lucky and cannot even reproduce it when toggling compositing all the time, on other days it starts as soon as compositing is disabled almost reliably. It has never happened when compositing was on, but once krunner has gone wild, it doesn't stop only because I turn it back on (i.e. I have to kill it in any case). Reproducible: Sometimes -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 364268] krunner puts system under heavy load when playing (OpenGL) games
https://bugs.kde.org/show_bug.cgi?id=364268 Janek Bevendorff changed: What|Removed |Added Summary|krunner puts system under |krunner puts system under |heavy load when compositing |heavy load when playing |is disabled |(OpenGL) games --- Comment #1 from Janek Bevendorff --- After some days where I played with an explicit window rule NOT to disable compositing I noticed (to my surprise) that the issue still occurs. So I looks like it's not the compositing but the game itself (in this case Dota2) that causes krunner to run at 100% CPU on all cores. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 363097] New: Traffic graph empty
https://bugs.kde.org/show_bug.cgi?id=363097 Bug ID: 363097 Summary: Traffic graph empty Product: plasma-nm Version: 5.6.4 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: applet Assignee: jgrul...@redhat.com Reporter: jbev_kdebugs...@refining-linux.org CC: lu...@kde.org Created attachment 98986 --> https://bugs.kde.org/attachment.cgi?id=98986&action=edit Screenshot The traffic graph for my active network connection is always empty like shown in the attached image. Sometimes it works after a fresh session restart, but when I close the panel widget and reopen it, the graph is gone. It used to work somewhere before 5.5 or 5.4, I think, but since then it has always been like this. There are no errors reported in .xsession-errors. This issue may be related to bug #268022 but it also occurs when I'm not connected to any VPN. Using Arch Linux with Plasma 5.6.4. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 363097] Traffic graph empty
https://bugs.kde.org/show_bug.cgi?id=363097 --- Comment #2 from Janek Bevendorff --- There is always traffic and it doesn't matter how long I have it open. It doesn't show anything. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 362899] dolphin crashed when I tried to delete file
https://bugs.kde.org/show_bug.cgi?id=362899 Janek Bevendorff changed: What|Removed |Added CC||jbev_kdebugs_01@refining-li ||nux.org --- Comment #1 from Janek Bevendorff --- I can confirm regular crashes when deleting files (Shift+Del). Since Arch doesn't provide debug symbols, I can't provide a stack trace right now, but from the description I would guess that this is the same bug. Here some observations: - The crash mostly seems to occur when I have multiple tabs open. - I usually delete multiple files at once - Dolphin doesn't crash immediately, but freezes for about 2 seconds before actually crashing - Move-to-trash is really, really slow (and I mean REALLY slow, like 5 seconds or more) while instant delete with Shift+Del is actually instant, but sometimes crashes Dolphin The first two may be coincidence, the last one may be a different issue, but I maybe that information helps. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 362899] dolphin crashed when I tried to delete file
https://bugs.kde.org/show_bug.cgi?id=362899 --- Comment #2 from Janek Bevendorff --- The crash also occurs when renaming files sometimes. I'm in the process of renaming and moving a lot of files manually and I'm having a really hard time because Dolphin crashes every couple of minutes. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356783] New: Text in Plasma tooltips sometimes becomes a series of smudgy blocks
https://bugs.kde.org/show_bug.cgi?id=356783 Bug ID: 356783 Summary: Text in Plasma tooltips sometimes becomes a series of smudgy blocks Product: plasmashell Version: 5.4.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: jbev_kdebugs...@refining-linux.org This bug randomly happens. When I change to font from Oxygen Sans to something else, it goes away, but comes back when I change the font back to Oxygen Sans. Not sure if it really has something to do with the font, though. I attached an image that shows how it looks. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 356783] Text in Plasma tooltips sometimes becomes a series of smudgy blocks
https://bugs.kde.org/show_bug.cgi?id=356783 --- Comment #1 from Janek Bevendorff --- Created attachment 96131 --> https://bugs.kde.org/attachment.cgi?id=96131&action=edit Smudgy text blocks -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353983] Turning off compositing breaks Plasma panel rendering
https://bugs.kde.org/show_bug.cgi?id=353983 --- Comment #30 from Janek Bevendorff --- Since 5.5 (or 5.6?) I also have the issue that not all windows are shown on the task manager when compositing is turned off (mostly those which were opened after turning it off) and the clock isn't updating. Everything seems to be in the state at which it was when disabling compositing for the first time. So enabling and disabling it again doesn't help. If my clock was at 3:45 when I turned it off, it stays at 3:45 until I turn compositing back on. And when I disable compositing a second time, it's again shows 3:45, even though it was, e.g., 5:32 when I re-enabled compositing temporarily. Using nvidia-358.16 on a GTX 650. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 359744] New: Cannot delete SMTP accounts
https://bugs.kde.org/show_bug.cgi?id=359744 Bug ID: 359744 Summary: Cannot delete SMTP accounts Product: kmail2 Version: 5.1 Platform: unspecified OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: jbev_kdebugs...@refining-linux.org Created attachment 97385 --> https://bugs.kde.org/attachment.cgi?id=97385&action=edit Screenshot Deleting SMTP accounts does not work. Instead, every account that I try to delete is simply renamed to "Unnamed" and any data that was contained in this account profile is cleared. I attached a screenshot of what my account list looks like right now. -- You are receiving this mail because: You are watching all bug changes.
