[frameworks-kio] [Bug 486796] Tiny dialog to attach files
https://bugs.kde.org/show_bug.cgi?id=486796 --- Comment #3 from Grósz Dániel --- I now found it to also happen in Ark's Archive/Add Files... dialog, so it indeed looks like the bug is in the file dialog. That one has a custom Advanced Options button. Perhaps it happens whenever (or in some cases when) the application customizes the file dialog in some way? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 486796] Tiny dialog to attach files
https://bugs.kde.org/show_bug.cgi?id=486796 Grósz Dániel changed: What|Removed |Added Assignee|kdepim-b...@kde.org |kio-bugs-n...@kde.org CC||kdelibs-b...@kde.org Version|6.0.2 |6.1.0 Component|composer|Open/save dialogs Product|kmail2 |frameworks-kio --- Comment #2 from Grósz Dániel --- (In reply to Laurent Montel from comment #1) > Hi, > kmail uses kfiledialog we don't provide it. > => it's not a kmail bug. > Regards Moving the bug to frameworks-kio. However, it doesn't happen anywhere else, so I assume it depends in some way on how KMail uses the dialog in that particular case, though I don't know where the bug actually is. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 486796] New: Tiny dialog to attach files
https://bugs.kde.org/show_bug.cgi?id=486796 Bug ID: 486796 Summary: Tiny dialog to attach files Classification: Applications Product: kmail2 Version: 6.0.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: composer Assignee: kdepim-b...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 169328 --> https://bugs.kde.org/attachment.cgi?id=169328=edit Screenshot SUMMARY Since (I think) the switch to KMail 6.x, the file dialog to attach files in the composer is sized weirdly by default, to the dialog's minimum allowed size (see screenshot). After resizing it, it behaves normally. It doesn't happen with other file dialogs, not even other file dialogs in KMail, such as the one to save attachments. (The screenshot shows the Plastik style and Kontact, but it happens with Breeze and KMail too. KWin rules can't be the culprit either, I've tried with a separate user with no rules.) STEPS TO REPRODUCE 1. Start writing an e-mail. 2. Click the toolbar button/press the shortcut to attach a file. OBSERVED RESULT The Attach File dialog is small, with the list of files invisible. EXPECTED RESULT The Attach File dialog has a normal size. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240506 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 486692] New: Two Kontact windows after quitting Kontact with a Composer window open
https://bugs.kde.org/show_bug.cgi?id=486692 Bug ID: 486692 Summary: Two Kontact windows after quitting Kontact with a Composer window open Classification: Applications Product: kontact Version: 6.0.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: mail Assignee: kdepim-b...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY If I quit Kontact while composing an e-mail, then after starting Kontact again, two mail Kontact windows appear, and two composer windows for each one that was open before quitting Kontact. The windows mostly behave normally, but e-mails don't show up in one of the main windows. The way to exit this state is to close all the Composer windows first, then quit both main windows (at that point Kontact segfaults), then start Kontact again. After that, Kontact behaves normally. STEPS TO REPRODUCE 1. Start a new e-mail in the Mail component of Kontact, or reply to an e-mail. Optionally make some changes in the e-mail, though it doesn't seem to be needed. 2. Quit Kontact, for instance with Ctrl+Q in the main window. 3. Start Kontact again. OBSERVED RESULT Two main Kontact windows, and two Composer windows. EXPECTED RESULT One main Kontact window, and one Composer window with the e-mail I started writing. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240503 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 483782] Kmail Message list does not show anything in "Date" column (migration from 5.x broken
https://bugs.kde.org/show_bug.cgi?id=483782 Grósz Dániel changed: What|Removed |Added Summary|Kmail Message list does not |Kmail Message list does not |show anything in "Date" |show anything in "Date" |column |column (migration from 5.x ||broken -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 483782] Kmail Message list does not show anything in "Date" column (migration from 5.x broken)
https://bugs.kde.org/show_bug.cgi?id=483782 Grósz Dániel changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED --- Comment #3 from Grósz Dániel --- It remains a bug that, if one has used Smart Format in KMail 5.x, the migration is broken, and no date is shown in 6.x. In fact, switching back to another date format, and then back to Smart Format, it works. In my config file, migrated from 5.x, the relevant line is dateFormat=5 while after changing the format and back, it has no line containing dateFormat. I guess now that's the default, determined by having no such line, and the old number this choice had is no longer recognized? -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 483782] Kmail Message list does not show anything in "Date" column (migration from 5.x broken)
https://bugs.kde.org/show_bug.cgi?id=483782 Grósz Dániel changed: What|Removed |Added Summary|Kmail Message list does not |Kmail Message list does not |show anything in "Date" |show anything in "Date" |column (migration from 5.x |column (migration from 5.x |broken |broken) -- You are receiving this mail because: You are watching all bug changes.
[khelpcenter] [Bug 486649] Clicking links not remembered in navigation history
https://bugs.kde.org/show_bug.cgi?id=486649 --- Comment #1 from Grósz Dániel --- I guess this may be the regressions discussed under Bug 484176 and https://invent.kde.org/system/khelpcenter/-/merge_requests/46, and perhaps already fixed? If so, I'm not opening separate reports for the other issues I've found related to navigation: - After switching between help pages via the Contents sidebar, using the Back or Forward buttons switches which page is highlighted on the sidebar, but not what is opened in the actual help page viewer. Especially after jumping between pages in the same application's manual, or applications in the same category, as opposed to pages in different categories. - Also, after using Back multiple times, then Forward multiple times, sometimes some pages in the history are forgotten. - No history menu is shown when clicking the arrow next to the Back or the Forward button. -- You are receiving this mail because: You are watching all bug changes.
[khelpcenter] [Bug 486649] New: Clicking links not remembered in navigation history
https://bugs.kde.org/show_bug.cgi?id=486649 Bug ID: 486649 Summary: Clicking links not remembered in navigation history Classification: Applications Product: khelpcenter Version: 6.0.24022 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kde-doc-engl...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY Clicking a link on a help page doesn't get remembered in the navigation history (Back, Forward buttons). STEPS TO REPRODUCE 1. Open KHelpCenter from an application's help menu (e.g. Help/Kate Handbook), or open the application and open a manual in it. For now, the Back button is disabled. 2. Click a link on the help page. OBSERVED RESULT The Back button remains disabled. EXPECTED RESULT The Back button is enabled, and it can be used to navigate back to the previous page. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240503 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 486648] New: Removing all bookmarks not remembered
https://bugs.kde.org/show_bug.cgi?id=486648 Bug ID: 486648 Summary: Removing all bookmarks not remembered Classification: Applications Product: kate Version: 24.02.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: sessions Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY Bookmarks are normally remembered after reopening a file. However, if I open a file with some bookmarks in it, remove all bookmarks, close the file, then open it again, the bookmarks are there again. It looks like if the set of bookmarks is empty, it doesn't overwrite the saved set of bookmarks. As such, it's impossible to get rid of all bookmarks in a straightforward way. It happens in both Kate and KWrite if I close the file, leaving the application open, then reopen the file. If KWrite is used, or Kate is used with an anonymous session, it also happens if I close the whole application (with the file still open in it), then reopen it. With a named session in Kate, it doesn't happen if I close the application with the file still open, then reopen the session, but it does if I close the file explicitly, and then reopen it. Removal of some bookmarks is remembered if not all bookmarks are removed. STEPS TO REPRODUCE 0. Make sure Configure / Session / Keep meta-information past sessions is enabled. 1. Open a file. 2. Bookmark some line(s). 3. Close the file. 4. Open the file again. 5. Remove all bookmarks in the file. 6. Close the file. 7. Open the file again. OBSERVED RESULT The bookmarks that existed after Step 4 are there again. EXPECTED RESULT There are no bookmarks in the file. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240503 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION Might be related to Bug 433006 (a crash when removing all bookmarks) or its fix. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 486254] New: Composer signs messages by default even if turned off in settings
https://bugs.kde.org/show_bug.cgi?id=486254 Bug ID: 486254 Summary: Composer signs messages by default even if turned off in settings Classification: Applications Product: kmail2 Version: 6.0.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: composer Assignee: kdepim-b...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY Since the upgrade to KMail 6.x, when writing an e-mail the Sign Message option is turned on, even though it's disabled in the settings. STEPS TO REPRODUCE 0. Perhaps it depends on having configured GPG keys somewhere at some point in the past. I think I did so at some point, but never really bothered to figure out how e-mail signing works. 1. Make sure Configure / Security / Encryption / Security defaults / Sign all messages is unchecked. 2. Click New Message, or reply to a message. OBSERVED RESULT In the composer window, the Sign Message option is turned on. If left on, when sending, it asks for a password. EXPECTED RESULT Sign Message option is turned off (and can be turned on manually). SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240426 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 447561] Always show (some fragment of) window titles even when buttons are very small
https://bugs.kde.org/show_bug.cgi?id=447561 --- Comment #8 from Grósz Dániel --- Now it seems like the title hiding behavior disappeared completely by plasmashell 6.0.4—I don't know if either this change or the one I reported in Comment 7 were intentional, but it now works as I'd like it. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 464224] Inconsistent tab behavior when reopening session
https://bugs.kde.org/show_bug.cgi?id=464224 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com --- Comment #4 from Grósz Dániel --- Newly created, unsaved files still don't get tabs when reopening the session on 24.02.1. They appear in the Documents sidebar and the contents are preserved, they just don't appear on the tab bar until opened from the Documents sidebar. I haven't encountered Bug 47 (marked a duplicate of this one but not exactly the same) where extra, empty "Untitled (2)" etc. tabs are created instead. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 485210] Split View dropdown menu actions of an inactive special (diff) view act on active view
https://bugs.kde.org/show_bug.cgi?id=485210 Grósz Dániel changed: What|Removed |Added Platform|Other |openSUSE -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 485211] New: New LSP function parameter tooltip hangs off the screen
https://bugs.kde.org/show_bug.cgi?id=485211 Bug ID: 485211 Summary: New LSP function parameter tooltip hangs off the screen Classification: Applications Product: kate Version: 24.02.1 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 168270 --> https://bugs.kde.org/attachment.cgi?id=168270=edit Screenshot SUMMARY The new function parameter tooltip is nice, but part of it is invisible when the cursor is near the right edge of the screen. See screenshot. As shown in the screenshot, even the completion list slightly hangs off the screen: it opens at the right edge of the screen, but after half a second (perhaps after LSP suggestions are loaded or when the function parameter popup is opened) it grows slightly bigger, while its location (top left corner) doesn't change. STEPS TO REPRODUCE 1. Move the cursor near the opening parenthesis of a function call in a program with LSP support. Make it so that this opening parenthesis is near the right edge of the screen. 2. Press Ctrl+Space. OBSERVED RESULT The function parameter tooltip is opened with its left edge at the cursor, and part of it is cut off if the popup is sufficiently wide. Half of the completion list's scrollbar is also cut off (perhaps depending on the available suggestions?). EXPECTED RESULT The tooltip and the completion list are shifted to the left, such that they are fully visible and their right edge aligns with the screen's edge. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240404 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.2-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 485209] Clicking in special views (diff) doesn't focus its split view
https://bugs.kde.org/show_bug.cgi?id=485209 --- Comment #1 from Grósz Dániel --- Seems related to 485210. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 485210] New: Split View dropdown menu actions of an inactive special (diff) view act on active view
https://bugs.kde.org/show_bug.cgi?id=485210 Bug ID: 485210 Summary: Split View dropdown menu actions of an inactive special (diff) view act on active view Classification: Applications Product: kate Version: 24.02.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY Normally, the actions in the small Split View dropdown menu at the end of a tab bar or navigation bar act on the split view the tool button belongs to, regardless of which view is active (as is expected if there's a separate menu for each split view). However, if that split view has a special view (a diff, Welcome, or an expanded Find in Files result view), and another split is active, the actions act on the active view. Curiously, clicking inside a diff view, and then on the Split View menu button, makes the menu act on the diff view, even though clicking inside the diff view doesn't activate it for all purposes (see Bug 485209). STEPS TO REPRODUCE 1. Create a split (I used Split Vertical). 2. Open a diff view (I did it using the Git sidebar). 3. Click inside another split view (which contains a regular editor). 4. Click on the small Split View icon at the end of the tab bar of the diff view. 5. Click Hide Inactive Views (or Split Horizontal etc.) OBSERVED RESULT The view in the other side (not the diff view) of the split fills the window (or gets further split horizontally etc). EXPECTED RESULT The diff view fills the window (or gets further split horizontally etc). SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240404 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.2-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION Seems related to Bug 485209. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 485209] New: Clicking in special views (diff) doesn't focus its split view
https://bugs.kde.org/show_bug.cgi?id=485209 Bug ID: 485209 Summary: Clicking in special views (diff) doesn't focus its split view Classification: Applications Product: kate Version: 24.02.1 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY When a diff view (or another special view: the Welcome view or an expanded Find in Files result view) is opened on one side of a split view, clicking inside the diff view doesn't make it the focused split. The main problem this causes is that activating Hide Inactive Views from the menu, a shortcut, or (if put there) the main toolbar, it makes the other split view fill the window, rather than the diff view. Since the diff view further splits the view in two, I'd often like to use Hide Inactive Views with it. Another effect is that Ctrl+Tab switches documents in the other split. The diff view does actually receive keyboard focus: Up and Down keys work to scroll it. It's just somehow not recognized by Kate as the active view. Workarounds are to click the tab in the tab bar to activate it, or to click inside the diff view and then use the navigation bar's dropdown menu to activate Hide Inactive Views. STEPS TO REPRODUCE 1. Create a split (I used Split Vertical). 2. Open a diff view (I did it using the Git sidebar). 3. Click somewhere inside the text in the diff view. 4. Click View/Split View/Hide Inactive Views. OBSERVED RESULT The view in the other side of the split fills the window. EXPECTED RESULT The diff view fills the window. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240404 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.2-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 372496] Support tmux control mode
https://bugs.kde.org/show_bug.cgi?id=372496 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 485010] Rename or remove Session settings panel in KWrite
https://bugs.kde.org/show_bug.cgi?id=485010 --- Comment #2 from Grósz Dániel --- (In reply to Waqar Ahmed from comment #1) > From past experience, removing any settings is in general not a good idea so > I am not sure we should do this at all. I tend to agree, but a setting that has no (observable) effect at all in KWrite should be removed in KWrite. It seems to me that the "Close documents with the window they belong to" setting is like that. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 485010] New: Rename or remove Session settings panel in KWrite
https://bugs.kde.org/show_bug.cgi?id=485010 Bug ID: 485010 Summary: Rename or remove Session settings panel in KWrite Classification: Applications Product: kate Version: 24.02.1 Platform: openSUSE OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: kwrite Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 168125 --> https://bugs.kde.org/attachment.cgi?id=168125=edit Screenshot of the Session panel KWrite doesn't have sessions, so it might be confusing that the Configure dialog has a Session panel. This is a suggestion to at least rename it. Also, some options seem to be irrelevant in KWrite, so perhaps remove the Session panel and move the options that are still relevant to Open/Save. "Close documents with the window they belong to": Note that even in Kate, this is only applied if a file has no modifications. As far as I can tell, KWrite doesn't have a (user-observable) concept of a set of open documents as different from whichever files are opened in a tab in a window, for files that aren't modified, so there is no difference between internally closing a file when the only window in which it is open is closed, and not internally closing it. This option should always be treated as enabled in KWrite, and the checkbox should be removed. (When a file does have modifications, both Kate and KWrite internally keep it open if there are multiple windows created with File/New Window, and you close the only window the file is opened in. In KWrite, the only signs that the file is kept open are that if you close the remaining windows, it asks you if you want to save it, and that if you open the file anew, the modifications are there. It would be more natural to ask the user whether to save the file as soon as the window the file belongs to is closed if the "Close documents with the window they belong to" option is enabled, in both KWrite and Kate.) "Maximum number of entries in recent file list": This is definitely relevant in KWrite too. "Keep meta-information past sessions": relevant in KWrite too (to remember bookmarks, perhaps some other things as well), but the name is rather cryptic. I'm not sure there is a point in the option to disable it, though. "Show welcome view for new windows" (disabled by default in KWrite), "Close the application entirely when the last file is closed" (enabled by default): they technically make sense in KWrite too, but I'm not sure there is much need for them in a relatively minimalistic editor. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240329 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482686] The shade option works incorrectly on X11
https://bugs.kde.org/show_bug.cgi?id=482686 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com --- Comment #2 from Grósz Dániel --- (In reply to S. Christian Collins from comment #1) > What window decoration are you using? The Breeze decoration doesn't seem to > have this problem. It happens to me with Breeze with vertically (but not fully) maximized windows as long as either window borders or Breeze's outline (in the Breeze window decoration's settings) is enabled. I've noticed it since the update to KDE 6, though in KDE 5 I had neither borders nor an outline on my windows, so Idk if it existed in kwin 5 too. Also, the frame doesn't jerk around when moving the window for me, it just moves normally with the title. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 467635] On X11, cursor stuck dragging when hovering over Task Manager after streaming with Moonlight
https://bugs.kde.org/show_bug.cgi?id=467635 --- Comment #4 from Grósz Dániel --- Oh crap, this isn't gone even in Plasma 6. It happens about once a month. Operating System: openSUSE Tumbleweed 20240321 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 484668] New: Dragging icon in file dialog's location bar does not supply name
https://bugs.kde.org/show_bug.cgi?id=484668 Bug ID: 484668 Summary: Dragging icon in file dialog's location bar does not supply name Classification: Frameworks and Libraries Product: frameworks-kio Version: 6.0.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Open/save dialogs Assignee: kio-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com CC: kdelibs-b...@kde.org Target Milestone: --- Created attachment 167893 --> https://bugs.kde.org/attachment.cgi?id=167893=edit Screen recording SUMMARY When the location bar of a file dialog is in path editing mode (rather than breadcrumbs mode), it has an icon on the left. That icon can be dragged and dropped, for example to add the current location to the Places sidebar. However, when doing that, the icon in the Places sidebar will appear without a name. The entry created otherwise works. See screen recording. STEPS TO REPRODUCE 1. In a file dialog, put the location bar in path editing mode (click the empty space after the path if it's in Navigate (breadcrumbs) mode. 2. Drag the icon on the left to the Places sidebar, to add the current location to the Places. OBSERVED RESULT The current location is added to Places, but it only has an icon, not a name. EXPECTED RESULT The entry is added with the name of the folder. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240321 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION This doesn't happen in Dolphin, only in the file dialogs. The problem seems to be on the source side (the icon in the location bar), rather than on the target side (the Places sidebar): if I drag the icon from a file dialog's location bar to the sidebar in a Dolphin window, it's also added without a name, while if I drag from a Dolphin window's location bar to the Places sidebar in a file dialog, the name of the folder is shown. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kiconthemes] [Bug 484639] Fallback to Breeze ignored by KIconLoader because of wrong global initialization order
https://bugs.kde.org/show_bug.cgi?id=484639 --- Comment #7 from Grósz Dániel --- Well, I interpreted Nate as saying that, while it might make sense to use Breeze a fallback even if it's not explicitly specified as an inherited theme, it's also desirable for every theme to explicitly specify a presumably complete theme (Breeze, Adwaita) as an inherited theme. Perhaps that would also help ensure that every icon works when using Oxygen icons in non-KDE applications running under KDE, or even in other DEs? So I thought it would make sense to have a separate report for the request to add a fallback (besides hicolor) to Oxygen from the other request to use Breeze as a fallback even if it isn't specified. But perhaps I'm not familiar with the details, so perhaps I'm wrong about this and I leave it to you to decide. -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 484639] New: Oxygen icons should fall back to (inherit from) Breeze
https://bugs.kde.org/show_bug.cgi?id=484639 Bug ID: 484639 Summary: Oxygen icons should fall back to (inherit from) Breeze Classification: Plasma Product: Oxygen Version: 6.0.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: icons Assignee: n...@oxygen-icons.org Reporter: groszdaniel...@gmail.com Target Milestone: --- There have been bug reports of missing icons in Plasma 6 with the Oxygen theme: Bug 481402, Bug 483496. (IIRC there were a few missing icons in Plasma 5 as well, but less prominent ones.) Besides, of course, providing those icons in Oxygen style, a (partial) solution would be to fall back to a style that provides them, such as Breeze. On Bug 451463, Nate commented: "Ultimately it's up to icon themes to set a sane fallback. However I do see something we could do to improve the situation, given the world we live in where there are 527603 crappy incomplete icon themes that don't set their fallback to something sane (typically Breeze or Adwaita, which can both be considered to be more or less complete)." Oxygen is a nice but incomplete icon theme, and it currently only has hicolor as its fallback theme. Please set its fallback to something sane, such as Breeze (perhaps hicolor first, then breeze). (Bug 451463 asked to use Breeze as a fallback even when it's not set by the icon theme. That would let people use old icon themes that may have become unmaintained before Breeze or Adwaita even existed, and still not have missing icons. However, since Oxygen is still provided by KDE, its fallback should be changed.) SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240321 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 455890] Toggling navigation bar visibility breaks UI
https://bugs.kde.org/show_bug.cgi?id=455890 --- Comment #7 from Grósz Dániel --- Created attachment 167869 --> https://bugs.kde.org/attachment.cgi?id=167869=edit Screen recording -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 455890] Toggling navigation bar visibility breaks UI
https://bugs.kde.org/show_bug.cgi?id=455890 Grósz Dániel changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|WORKSFORME |--- CC||groszdaniel...@gmail.com Ever confirmed|1 |0 --- Comment #6 from Grósz Dániel --- Still happens in both Kate or KWrite 24.02.1. I'll attach a screen recording. It depends on that - Auto hide tabs is enabled in Configure/Behavior/Tabs, so that the tab bar is hidden when there is only one file open - there is only one file open There are two variants of the glitch: - one that happens when disabling the navigation bar in the above conditions - one that happens when enabling the navigation bar, with the additional condition that the navigation bar hasn't been visible since starting Kate or KWrite, or that the last time the navigation bar was visible, the tab bar was also visible. Normally the four buttons that appear stretched in the glitch are - at the ends of the tab bar if the tab bar is visible - at the ends of the navigation bar if the tab bar is hidden but the navigation bar is visible - hidden if neither the tab bar, nor the navigation bar is visible. These happen if a given state (w.r.t. the visibility of the tab bar and the navigation bar) is reached via opening Kate or KWrite in a given state, via opening or closing a tab, or toggling the Auto hide tabs option. I guess the bug exists because - when the navigation bar gets disabled when the tab bar is invisible, the buttons don't get hidden - when the navigation bar gets enabled and the tab bar is invisible, the buttons don't get moved to the navigation bar if they are currently invisible in some cases (perhaps when they are in the invisible tab bar rather than in the hitherto invisible navigation bar?) Operating System: openSUSE Tumbleweed 20240321 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 447561] Always show (some fragment of) window titles even when buttons are very small
https://bugs.kde.org/show_bug.cgi?id=447561 --- Comment #7 from Grósz Dániel --- This became worse with Plasma 6. When the "feature" of hiding titles completely when there is relatively little space started, the threshold was around 7 letters; that is, if there was space for less than ~7 letters, the titles would be completely hidden. After a while, that threshold was reduced to ~5 letters, I guess because it bothered some people. Now it seems to be back to ~7 letters. (But I still think the right behavior would be to not have any such title hiding when window grouping is disabled.) -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 483782] Kmail Message list does not show anything in "Date" column
https://bugs.kde.org/show_bug.cgi?id=483782 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com --- Comment #1 from Grósz Dániel --- Happens here too. KMail or Kontact 6.0.0 Operating System: openSUSE Tumbleweed 20240321 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 484506] New: Changing command doesn't get applied until restart
https://bugs.kde.org/show_bug.cgi?id=484506 Bug ID: 484506 Summary: Changing command doesn't get applied until restart Classification: Frameworks and Libraries Product: frameworks-kglobalaccel Version: 6.0.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY If I change the command in a shortcut for a custom command/script, the change isn't applied until logging out and in. STEPS TO REPRODUCE 1. In System Settings / Keyboard / Shortcuts, click Add New / Command or Script. Enter a command, like "kdialog --msgbox AAA", and click Add. 2. Use "Add custom shortcut" to add a shortcut. 3. Click the little Edit icon in the list of shortcuts/applications, and change the command to, say, "kdialog --msgbox BBB". 4. Press the shortcut. OBSERVED RESULT In the list of shortcuts/applications on the left, the command changes. However, in the main, shortcut editing part of the window to the right, the title remains the earlier command. Upon pressing the shortcut, the earlier command is executed (the dialog says "AAA"). After the Plasma session is started anew, the change is applied. EXPECTED RESULT The change is applied everywhere immediately, and a subsequent activation of the shortcut executes the new command. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240321 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 446961] Add option to select screen in custom notification positioning UI
https://bugs.kde.org/show_bug.cgi?id=446961 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466771] Some windows are painted black on X11, processes freeze
https://bugs.kde.org/show_bug.cgi?id=466771 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 481069] Consider re-adding the feature to execute commands in notifications
https://bugs.kde.org/show_bug.cgi?id=481069 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 455904] Window List should group windows by Virtual Desktop
https://bugs.kde.org/show_bug.cgi?id=455904 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 444358] When printing multiple pages per sheet (such as 2X2) the described order of pages is misleading when printing in landscape mode
https://bugs.kde.org/show_bug.cgi?id=444358 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com --- Comment #1 from Grósz Dániel --- Happened to me too. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 477224] Crash after pressing both mouse buttons
https://bugs.kde.org/show_bug.cgi?id=477224 --- Comment #4 from Grósz Dániel --- (In reply to Christoph Cullmann from comment #3) > Yes, as comment how we might fix the stuff in > LSPClientPluginViewImpl::prepareContextMenu that seems to crash below. Ah, OK. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 477224] Crash after pressing both mouse buttons
https://bugs.kde.org/show_bug.cgi?id=477224 --- Comment #2 from Grósz Dániel --- (In reply to Christoph Cullmann from comment #1) > Hmmm, instead of that self managing, can we not just add these actions to > the xmlgui file like the ctags plugin does it? > > > > > > We can even add some merge area if we need that. Did you mean to post this under this bug? -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 469588] drkonqi submits a crash report and then gets stuck at "Submitting bug report..."
https://bugs.kde.org/show_bug.cgi?id=469588 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 477224] New: Crash after pressing both mouse buttons
https://bugs.kde.org/show_bug.cgi?id=477224 Bug ID: 477224 Summary: Crash after pressing both mouse buttons Classification: Applications Product: kate Version: 23.08.1 Platform: openSUSE OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Application: kate (23.08.1) Qt Version: 5.15.10 Frameworks Version: 5.110.0 Operating System: Linux 6.5.4-1-default x86_64 Windowing System: X11 Distribution: "openSUSE Tumbleweed" DrKonqi: 5.27.8 [KCrashBackend] -- Information about the crash: I accidentally pressed the right and the left mouse buttons at the same time over the text editor area. Kate immediately crashed. I think I pressed the right one first. I don't know whether the mouse moved slightly over the context menu in the meantime (where the first action would be Cut), nor if anything was selected. Pressing both of them at the same time is NOT configured to emulate middle click. It's a regular mouse (not touchpad), and the system is X11. The crash does not seem to be reproducible. -- Backtrace: Application: Kate (kate), signal: Segmentation fault [KCrash Handler] #4 QObjectPrivate::setParent_helper(QObject*) (this=0x55c1384a82a0, o=0x55c1382dba00) at kernel/qobject.cpp:2168 #5 0x7fdf88723629 in QObject::setParent(QObject*) (this=, parent=) at kernel/qobject.cpp:2124 #6 0x7fdf41bc3897 in LSPClientPluginViewImpl::prepareContextMenu(KTextEditor::View*, QMenu*) (this=0x55c138479110, view=, menu=0x55c1382dba00) at /usr/src/debug/kate-23.08.1/addons/lspclient/lspclientpluginview.cpp:2460 #7 0x7fdf88725812 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffc92b17f90, r=0x55c138479110, this=0x55c138bcb150) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #8 doActivate(QObject*, int, void**) (sender=0x55c138c810c0, signal_index=12, argv=0x7ffc92b17f90) at kernel/qobject.cpp:3925 #9 0x7fdf8871e47f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=, m=, local_signal_index=local_signal_index@entry=5, argv=argv@entry=0x7ffc92b17f90) at kernel/qobject.cpp:3985 #10 0x7fdf87a221b7 in KTextEditor::View::contextMenuAboutToShow(KTextEditor::View*, QMenu*) (this=, _t1=, _t2=) at /usr/src/debug/ktexteditor-5.110.0/build/src/KF5TextEditor_autogen/include/moc_view.cpp:428 #11 0x7fdf88725812 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffc92b18040, r=0x55c138c810c0, this=0x7fdf740402b0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #12 doActivate(QObject*, int, void**) (sender=0x55c1382dba00, signal_index=7, argv=0x7ffc92b18040) at kernel/qobject.cpp:3925 #13 0x7fdf8871e47f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=sender@entry=0x55c1382dba00, m=m@entry=0x7fdf89ac7be0 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x0) at kernel/qobject.cpp:3985 #14 0x7fdf89724240 in QMenu::aboutToShow() (this=this@entry=0x55c1382dba00) at .moc/moc_qmenu.cpp:270 #15 0x7fdf89729d3e in QMenuPrivate::popup(QPoint const&, QAction*, std::function) (this=0x55c13d507c30, p=..., atAction=atAction@entry=0x0, positionFunction=...) at widgets/qmenu.cpp:2409 #16 0x7fdf8972ab9e in QMenu::popup(QPoint const&, QAction*) (this=this@entry=0x55c1382dba00, p=..., atAction=atAction@entry=0x0) at widgets/qmenu.cpp:2353 #17 0x7fdf879d8e78 in KateViewInternal::contextMenuEvent(QContextMenuEvent*) (this=, e=) at /usr/src/debug/ktexteditor-5.110.0/src/view/kateviewinternal.cpp:3371 #18 0x7fdf895e6d68 in QWidget::event(QEvent*) (this=0x55c138c6d110, event=0x7ffc92b18610) at kernel/qwidget.cpp:9045 #19 0x7fdf895a519e in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=this@entry=0x55c136ec58a0, receiver=receiver@entry=0x55c138c6d110, e=e@entry=0x7ffc92b18610) at kernel/qapplication.cpp:3640 #20 0x7fdf895adaaa in QApplication::notify(QObject*, QEvent*) (this=, receiver=, e=0x7ffc92b18610) at kernel/qapplication.cpp:3246 #21 0x7fdf886ed568 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x55c138c6d110, event=0x7ffc92b18610) at kernel/qcoreapplication.cpp:1064 #22 0x7fdf886ed5b2 in QCoreApplication::forwardEvent(QObject*, QEvent*, QEvent*) (receiver=, event=, originatingEvent=) at kernel/qcoreapplication.cpp:1079 #23 0x7fdf895fff59 in QWidgetWindow::handleMouseEvent(QMouseEvent*) (this=this@entry=0x55c138c06600, event=event@entry=0x7ffc92b18900) at kernel/qwidgetwindow.cpp:692 #24 0x7fdf89602d1f in QWidgetWindow::event(QEvent*) (this=0x55c138c06600, event=0x7ffc92b18900) at kernel/qwidgetwindow.cpp:300 #25 0x7fdf895a519e in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=, receiver=0x55c138c06600, e=0x7ffc92b18900) at
[dolphin] [Bug 429453] Bookmarks should have a top-level menu item rather than being hidden in the Go menu
https://bugs.kde.org/show_bug.cgi?id=429453 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com --- Comment #10 from Grósz Dániel --- (In reply to Jens Lallensack from comment #6) > A downside is that the "Bookmarks" entry, if you add it to the toolbar, does > not have a shortcut associated with it, and I am unable to define one. Actually you can: go to Configure Toolbar, and set the text of the entry to Then Alt+B works, even if the toolbar shows icons only. This is not exactly a discoverable feature, though, even for power users: it only occurred to me to try because I know a bit about GUI programming. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 454412] Bookmarks should have a top-level menu item rather than being hidden in the Go menu
https://bugs.kde.org/show_bug.cgi?id=454412 --- Comment #11 from Grósz Dániel --- Another workaround: put Bookmarks on the toolbar (if you have one), and set the text to Then Alt+B works, even if the toolbar shows icons only. Another one is to edit the personal kxmlgui files, but that tends to get reset after updates. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 476979] New: Display of dragged text wrong when word-wrap is enabled
https://bugs.kde.org/show_bug.cgi?id=476979 Bug ID: 476979 Summary: Display of dragged text wrong when word-wrap is enabled Classification: Frameworks and Libraries Product: frameworks-ktexteditor Version: 5.110.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 163141 --> https://bugs.kde.org/attachment.cgi?id=163141=edit Screen recording SUMMARY In KTextEditor-based editors (tried Kate, KWrite, KDevelop) when dragging selected text, the dragged text is shown near the mouse cursor. However, if word-wrap is enabled and there are some wrapped lines above the selection, the location of the dragged text is wrong. If the selected text is across multiple lines involving automatically wrapped lines, the content of the displayed text is wrong as well. It's best explained with a screen recording. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20231001 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.4-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION Bug 468196 was a similar issue. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 476606] New: Group or thread by subject
https://bugs.kde.org/show_bug.cgi?id=476606 Bug ID: 476606 Summary: Group or thread by subject Classification: Applications Product: kmail2 Version: 5.23.3 Platform: openSUSE OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: message list Assignee: kdepim-b...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY Please add an option to group messages by subject (preferably ignoring Re:, Fw:, Fwd: prefixes). As far as I understand, the current threading option seems to thread by Message-ID and In-Reply-To headers, rather than subjects. In any case, in some cases messages with the same subject aren't displayed together. For most use cases, this may be right. However, for some use cases, grouping by subject, regardless of the presence of those headers, is desirable. My use case is notifications from a forum about comments, with the subject of a notification being the subject of the thread; these are not replies to each other as e-mails, so they currently aren't grouped even if threading is enabled. STEPS TO REPRODUCE 1. View / Message List / Aggregation / Configure... 2. Choose a mode 3. Go to the Groups & Threading tab OBSERVED RESULT No option to group by subject in either the Grouping or the Threading dropdown list. EXPECTED RESULT An option to group by subject, perhaps in the Grouping list. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20231001 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.4-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION There are references to grouping by subject in earlier bug reports (Bug 313516), but it seems to have gone MIA. -- You are receiving this mail because: You are watching all bug changes.
[kmail] [Bug 270215] Threaded view takes too much space in long conversations
https://bugs.kde.org/show_bug.cgi?id=270215 Grósz Dániel changed: What|Removed |Added Resolution|--- |UNMAINTAINED Status|REPORTED|RESOLVED --- Comment #4 from Grósz Dániel --- Sorry for reopening this, I forgot that there was a separate product for KMail2. Bug 209938 is equivalent and has been already moved to KMail2. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 209938] Long threads push messages off the view in threaded view because of indent accumulation
https://bugs.kde.org/show_bug.cgi?id=209938 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kmail] [Bug 270215] Threaded view takes too much space in long conversations
https://bugs.kde.org/show_bug.cgi?id=270215 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com Status|RESOLVED|REPORTED Ever confirmed|1 |0 Resolution|WAITINGFORINFO |--- --- Comment #3 from Grósz Dániel --- Still valid. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 467635] On X11, cursor stuck dragging when hovering over Task Manager after streaming with Moonlight
https://bugs.kde.org/show_bug.cgi?id=467635 Grósz Dániel changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #3 from Grósz Dániel --- This happened to me again, in plasmashell 5.27.8, kwin 5.27.8, X11. I don't know what triggers it, but once it's triggered, the symptoms are the same as those of the reporter. It doesn't seem to be a duplicate of Bug 466675. That one is about dragging TO a taskbar item not working. In this one, among other symptoms, moving the mouse over taskbar items without clicking behaves like dragging a taskbar item itself. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 475175] Interactions between LSP Go to Definition and conventional Ctrl+Drag behavior
https://bugs.kde.org/show_bug.cgi?id=475175 --- Comment #2 from Grósz Dániel --- Thanks for the quickest fix ever. But it may be an overkill to disable Ctrl+Click even when the click isn't in the selection, and the mouse isn't moved. Other editors seem to handle Ctrl+Click when the mouse is released, and ignore it if something is being dropped. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 475215] New: LSP: copying nested diagnosics
https://bugs.kde.org/show_bug.cgi?id=475215 Bug ID: 475215 Summary: LSP: copying nested diagnosics Classification: Applications Product: kate Version: 23.08.1 Platform: openSUSE OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 162087 --> https://bugs.kde.org/attachment.cgi?id=162087=edit Screenshot SUMMARY When there are diagnostic messages nested in another message (see screenshot; I don't know what they are called in LSP terminology) there is no option in the context menu to copy the nested diagnostic. Also, there is a Copy option in the context menu of the parent, but it only copies the parent, so there is no way to copy the child. - There should be a Copy option in the context menu of the nested message. - Perhaps the Copy option of the parent should copy the descendants as well, or there should be a separate option to copy it along with the descendants. This would make it easier when there are many nested messages. STEPS TO REPRODUCE 1. Produce code that results in nested diagnostics. 2. Right-click the nested diagnostic. 3. Right-click the parent diagnostic, and click Copy. OBSERVED RESULT After 2: No Copy option. After 3: only the parent is copied. EXPECTED RESULT After 2: There's a Copy option. After 3: Perhaps the nested message(s) are copied as well, in separate lines. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20231001 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.4.11-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 475213] New: LSP Cleint: Break lines in long error messages
https://bugs.kde.org/show_bug.cgi?id=475213 Bug ID: 475213 Summary: LSP Cleint: Break lines in long error messages Classification: Applications Product: kate Version: 23.08.1 Platform: openSUSE OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 162085 --> https://bugs.kde.org/attachment.cgi?id=162085=edit Screenshot SUMMARY When a diagnostic message is too long to fit in one line, please display it on multiple lines instead of truncating it. (See screenshot.) STEPS TO REPRODUCE 1. Produce an error/warning message too long to fit in one line. (Make the window smaller if necessary.) OBSERVED RESULT The message is truncated with a "..." at the end. EXPECTED RESULT The entire message is shown in multiple lines. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20231001 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.4.11-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 475175] New: Interactions between LSP Go to Definition and conventional Ctrl+Drag behavior
https://bugs.kde.org/show_bug.cgi?id=475175 Bug ID: 475175 Summary: Interactions between LSP Go to Definition and conventional Ctrl+Drag behavior Classification: Applications Product: kate Version: 23.08.1 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY The LSP feature of going to the definition on Control+Click interacts poorly with the pre-existing effects of Control+Drag: - If you attempt to Control+Drag some selected text to copy it, and happen to have the mouse over an identifier when you start it, the editor goes to the definition, and then offers to drop the dragged text there (often in a different file). - If you Control+Click an identifier without it being selected, and then slightly move the mouse after it goes to the definition, it selects the text between the target (at the center of the editor) and the mouse position, which is unintended and looks weird. STEPS TO REPRODUCE With selection: 1. Select some text, including an identifier. 2. Press Ctrl and the mouse button over the identifier. 3. Move the mouse and then release the button. Without selection: 1. Press Ctrl and the mouse button over the identifier. 2. Move the mouse a little. OBSERVED RESULT With selection: goes to the definition (or declaration), and then copies the selected text there. Without selection: goes to the definition, and then selects text between the location of the definition (typically vertically at the center of the editor) and the mouse cursor. EXPECTED RESULT With selection: drags and copies the selection, without going to the definition. Without selection: Goes to the definition, and doesn't select text. POSSIBLE SOLUTIONS - Activate Go to Definition on mouse release, rather than mouse press, and then only if it hasn't been moved. (Perhaps a minor downside is that moving the mouse even slightly, within the identifier, disables Go to Definition.) - Only activate Go to Definition on mouse release if the click is inside a selection, and then only if no drag is started. If the click isn't inside a selection, activate it on mouse press, but don't start a selection afterwards if the mouse is dragged. - Always activate Go to Definition on mouse release, only if it's not dragging a selection, and if the mouse is still within the same identifier as when it was pressed. (If there was no selection, this is consistent with clicking a button.) SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230929 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.4.11-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 474754] New: Selecting files with Ctrl, Shift+Click in Git sidebar shouldn't open diff
https://bugs.kde.org/show_bug.cgi?id=474754 Bug ID: 474754 Summary: Selecting files with Ctrl, Shift+Click in Git sidebar shouldn't open diff Classification: Applications Product: kate Version: 23.08.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY Selecting multiple files in the Git sidebar with Ctrl+Click is useful to e.g. stage them all using the context menu. However, it's currently inconvenient because a click also executes the configured single click action (Show Diff by default) even if Ctrl or Shift is pressed. STEPS TO REPRODUCE 1. In the Git sidebar, Ctrl+Click or Shift+Click on a file. OBSERVED RESULT It becomes selected (or deselected if it's already selected, and in the case of Shift+Click some other files become selected), and the single click action is performed on the file clicked. EXPECTED RESULT The selection is changed, but the single click action isn't performed. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230915 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.4.11-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 473897] Cannot add Google Groupware, "Configured account does not exist" then "Resource is not configured"
https://bugs.kde.org/show_bug.cgi?id=473897 --- Comment #21 from Grósz Dániel --- Some related earlier bug reports: Bug 357819, Bug 444288. These are earlier reports, while the current iteration of the issue only started recently, so it's unclear if these (or the Bug 373348 already marked as a duplicate) really are the same issue. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 357819] Korganizer doesn't send calendar events to Google account
https://bugs.kde.org/show_bug.cgi?id=357819 --- Comment #11 from Grósz Dániel --- @Jack, @Peter Ries: Note that these recent issues are likely to be Bug 473897. Idk if this Bug 357819 was related. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 474461] New: Search in files in folder: support ~ (tilde)
https://bugs.kde.org/show_bug.cgi?id=474461 Bug ID: 474461 Summary: Search in files in folder: support ~ (tilde) Classification: Applications Product: kate Version: 23.08.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: search Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY In the Search plugin in In Folder mode, the Folder field should support ~ and ~username to specify the current or another user's home directory. It's especially confusing that it's currently unsupported because text completion in the field does show subdirectories of directories specified with ~ or ~username. It would also be a good idea to show an error (e.g. make the field red) if the starting path doesn't exist or is invalid. STEPS TO REPRODUCE 1. Open the Search sidebar. 2. Set the mode to In Folder. 3. Specify ~, or a path starting with ~. 4. Click Search. OBSERVED RESULT The search result will be empty. EXPECTED RESULT Search in the path specified inside the home directory. Alternatively, don't have completion complete paths as if ~ is interpreted as the home directory, and show an error if the search path doesn't exist. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230910 KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 Kernel Version: 6.4.11-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 473897] Cannot add Google Groupware, "Configured account does not exist" then "Resource is not configured"
https://bugs.kde.org/show_bug.cgi?id=473897 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 357819] Korganizer doesn't send calendar events to Google account
https://bugs.kde.org/show_bug.cgi?id=357819 --- Comment #9 from Grósz Dániel --- Yes, there seems to be a new bug since a few days or weeks ago. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 444288] Akonadi "losing connection" to Google Calendars after some uptime / waking from sleep until either akonadictrl restart is used or Google Groupware is restarted in Korganizer.
https://bugs.kde.org/show_bug.cgi?id=444288 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 357819] Korganizer doesn't send calendar events to Google account
https://bugs.kde.org/show_bug.cgi?id=357819 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401391] Window detection function does not work
https://bugs.kde.org/show_bug.cgi?id=401391 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468458] Events are capped at 5 per day and show a random assortment when the day has more than 5 events
https://bugs.kde.org/show_bug.cgi?id=468458 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com --- Comment #1 from Grósz Dániel --- It's reasonable that the calendar only shows a limited number of dots per day (tough there would be other options, like shrinking the dots or displaying a number if there are many), but the event list should show all events. -- You are receiving this mail because: You are watching all bug changes.
[kdialog] [Bug 472715] KDialog shows file selector instead of folder selector
https://bugs.kde.org/show_bug.cgi?id=472715 --- Comment #3 from Grósz Dániel --- It looks like KDirSelectDialog was in KDELibs4Support. -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 470190] Dr. Konqi doesn't always show up when plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=470190 Grósz Dániel changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED CC||groszdaniel...@gmail.com --- Comment #7 from Grósz Dániel --- I have the same issue, though I haven't noticed DrKonqi appear for a moment. It has to be a relatively recent issue: I reported plasmashell crash Bug 468180 in April using DrKonqi (then plasmashell 5.27.3, DrKonqi 5.27.3; now I have 5.27.7 of both.). Also, DrKonqi works for other applications. This is from the console when killing plasmashell: gd@ah0:~ $ killall -SEGV plasmashell gd@ah0:~ $ Unable to start Dr. Konqi Re-raising signal for core dump handling. [5]- Segmentation fault (core dumped) krusader This is the corresponding backtrace in journalctl: Aug 17 18:59:13 ah.lan systemd-coredump[11218]: [] Process 11106 (plasmashell) of user 500 dumped core. Stack trace of thread 11106: #0 0x7fb3e0897308 pthread_sigmask@GLIBC_2.2.5 (libc.so.6 + 0x97308) #1 0x7fb3e083f40d sigprocmask (libc.so.6 + 0x3f40d) #2 0x7fb3e35bd87b _ZN6KCrash15setCrashHandlerEPFviE (libKF5Crash.so.5 + 0x587b) #3 0x7fb3e35bfd33 _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 0x7d33) #4 0x7fb3e083f1f0 __restore_rt (libc.so.6 + 0x3f1f0) #5 0x7fb3e090a0af __poll (libc.so.6 + 0x10a0af) #6 0x7fb3dfe6cd0e n/a (libglib-2.0.so.0 + 0x5dd0e) #7 0x7fb3dfe6ce2c g_main_context_iteration (libglib-2.0.so.0 + 0x5de2c) #8 0x7fb3e1346496 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x346496) #9 0x7fb3e12ebf8b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2ebf8b) #10 0x7fb3e12f4420 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2f4420) #11 0x555dcab1ba91 main (plasmashell + 0x29a91) #12 0x7fb3e08281f0 __libc_start_call_main (libc.so.6 + 0x281f0) #13 0x7fb3e08282b9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x282b9) #14 0x555dcab1be25 _start (plasmashell + 0x29e25) Stack trace of thread 11109: #0 0x7fb3e088c54e __futex_abstimed_wait_common (libc.so.6 + 0x8c54e) #1 0x7fb3e088f290 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x8f290) #2 0x7fb3d90c7eeb n/a (iris_dri.so + 0xc7eeb) #3 0x7fb3d91110d7 n/a (iris_dri.so + 0x1110d7) #4 0x7fb3e088ffa4 start_thread (libc.so.6 + 0x8ffa4) #5 0x7fb3e09187fc __clone3 (libc.so.6 + 0x1187fc) Stack trace of thread 11107: #0 0x7fb3e090a0af __poll (libc.so.6 + 0x10a0af) #1 0x7fb3dfe6cd0e n/a (libglib-2.0.so.0 + 0x5dd0e) #2 0x7fb3dfe6ce2c g_main_context_iteration (libglib-2.0.so.0 + 0x5de2c) #3 0x7fb3e13464ae _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x3464ae) #4 0x7fb3e12ebf8b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2ebf8b) #5 0x7fb3e1102d5e _ZN7QThread4execEv (libQt5Core.so.5 + 0x102d5e) #6 0x7fb3e2724517 n/a (libQt5DBus.so.5 + 0x1a517) #7 0x7fb3e1103f8d operator() (libQt5Core.so.5 + 0x103f8d) #8 0x7fb3e088ffa4 start_thread (libc.so.6 + 0x8ffa4) #9
[krusader] [Bug 473482] Crash while copying a big folder from FTP
https://bugs.kde.org/show_bug.cgi?id=473482 --- Comment #1 from Grósz Dániel --- Created attachment 161028 --> https://bugs.kde.org/attachment.cgi?id=161028=edit Plasmashell backtrace from journalctl I attach the unprocessed backtrace (from journalctl) of the plasmashell crash; I don't know if it's a cause or effect of the Krusader crash. -- You are receiving this mail because: You are watching all bug changes.
[krusader] [Bug 473482] New: Crash while copying a big folder from FTP
https://bugs.kde.org/show_bug.cgi?id=473482 Bug ID: 473482 Summary: Crash while copying a big folder from FTP Classification: Applications Product: krusader Version: unspecified Platform: openSUSE OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: krusader-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com CC: krusader-bugs-n...@kde.org Target Milestone: --- Application: krusader (2.8.0 "A New Day") Qt Version: 5.15.10 Frameworks Version: 5.108.0 Operating System: Linux 6.4.8-1-default x86_64 Windowing System: X11 Distribution: "openSUSE Tumbleweed" DrKonqi: 5.27.7 [KCrashBackend] -- Information about the crash: While copying a big folder (thousands of folders, tens of thousands of files, several GB) from an FTP server to my machine, Krusader crashed some 30% of the way in. Plasmashell crashed too. A progress notification had been open. I only have an unprocessed backtrace about the plasma crash, but it looks similar to Bug 468180, a recent source of common Plasmashell crashes when closing notifications (but in this case I didn't close the notification). The reporter is unsure if this crash is reproducible. -- Backtrace: Application: Krusader (krusader), signal: Segmentation fault [KCrash Handler] #4 0x7f0325b20d8f in QObject::property (this=this@entry=0x564e4d121b80, name=name@entry=0x7f032705a016 "desktopFileName") at kernel/qobject.cpp:4125 #5 0x7f032705433c in KUiServerV2JobTracker::registerJob (this=0x564e4d107680, job=) at /usr/src/debug/kjobwidgets-5.108.0/src/kuiserverv2jobtracker.cpp:186 #6 0x7f0327051a1c in operator() (__closure=0x564e4d0b1180) at /usr/src/debug/kjobwidgets-5.108.0/src/kuiserverv2jobtracker.cpp:227 #7 QtPrivate::FunctorCall, QtPrivate::List<>, void, KUiServerV2JobTracker::registerJob(KJob*):: >::call (arg=, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:146 #8 QtPrivate::Functor, 0>::call, void> (arg=, f=...) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:256 #9 QtPrivate::QFunctorSlotObject, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=, this_=0x564e4d0b1170, r=, a=, ret=) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:443 #10 0x7f0325b257a2 in QtPrivate::QSlotObjectBase::call (a=0x7ffe49948080, r=0x564e4d107680, this=0x564e4d0b1170) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #11 doActivate (sender=0x7f0327061060 <_ZZN12_GLOBAL__N_117Q_QGS_serverProxy13innerFunctionEvE6holder.lto_priv.1>, signal_index=3, argv=0x7ffe49948080) at kernel/qobject.cpp:3925 #12 0x7f0325b257a2 in QtPrivate::QSlotObjectBase::call (a=0x7ffe499481a0, r=0x7f0327061060 <_ZZN12_GLOBAL__N_117Q_QGS_serverProxy13innerFunctionEvE6holder.lto_priv.1>, this=0x564e4d072b30) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #13 doActivate (sender=0x564e4c535510, signal_index=5, argv=0x7ffe499481a0) at kernel/qobject.cpp:3925 #14 0x7f0326dc845f in QDBusServiceWatcher::serviceOwnerChanged(QString const&, QString const&, QString const&) () from /lib64/libQt5DBus.so.5 #15 0x7f0326dc8e8e in ?? () from /lib64/libQt5DBus.so.5 #16 0x7f0326dc9243 in QDBusServiceWatcher::qt_metacall(QMetaObject::Call, int, void**) () from /lib64/libQt5DBus.so.5 #17 0x7f0326d7a46b in ?? () from /lib64/libQt5DBus.so.5 #18 0x7f0325b192b0 in QObject::event (this=0x564e4c535510, e=0x7f031c058190) at kernel/qobject.cpp:1347 #19 0x7f03267a519e in QApplicationPrivate::notify_helper (this=, receiver=0x564e4c535510, e=0x7f031c058190) at kernel/qapplication.cpp:3640 #20 0x7f0325aed4f8 in QCoreApplication::notifyInternal2 (receiver=0x564e4c535510, event=0x7f031c058190) at kernel/qcoreapplication.cpp:1064 #21 0x7f0325aed6be in QCoreApplication::sendEvent (receiver=, event=) at kernel/qcoreapplication.cpp:1462 #22 0x7f0325af0af1 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x564e4bac6f50) at kernel/qcoreapplication.cpp:1821 #23 0x7f0325af1038 in QCoreApplication::sendPostedEvents (receiver=, event_type=) at kernel/qcoreapplication.cpp:1680 #24 0x7f0325b46c83 in postEventSourceDispatch (s=0x564e4bc40d20) at kernel/qeventdispatcher_glib.cpp:277 #25 0x7f0324316988 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #26 0x7f0324316d98 in ?? () from /lib64/libglib-2.0.so.0 #27 0x7f0324316e2c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #28 0x7f0325b46496 in QEventDispatcherGlib::processEvents (this=0x564e4bc46160, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #29 0x7f0325aebf8b in QEventLoop::exec (this=this@entry=0x7ffe49948760, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #30 0x7f0325af4420 in QCoreApplication::exec () at
[kate] [Bug 473116] New: Find Next searches in other split
https://bugs.kde.org/show_bug.cgi?id=473116 Bug ID: 473116 Summary: Find Next searches in other split Classification: Applications Product: kate Version: 23.04.3 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: search Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY When using a split view (say, a vertical split into a left and right view), under particular conditions, the Find Next button continues a search in the inactive view, rather than the intended one. STEPS TO REPRODUCE 1. Create a vertical split (left and right half). 2. Click in the left half. (The other way around, starting in the right half, doesn't reproduce the bug.) 3. Start either a simple Find (Ctrl+F) or a Replace (Ctrl+R). 4. Either enter some text, or clear the Find field. 5. Leave the search open, or close it with the X button or, only if you cleared the Find field in 4., close it with Escape. (If I enter some text and close it with Escape, the bug doesn't reproduce.) 6. Click in the right half. (Switching with a Next Split View shortcut doesn't reproduce the bug.) 7. Start a simple Find (Ctrl+F). (Using Replace doesn't reproduce it.) 8. Enter some characters. It starts to search in the file in the right split view. 9. Press F3 (Find Next). Optionally repeat it. 10. Click in the left split view. OBSERVED RESULT In 9., each press of F3 continues the search in the left split view (or does nothing if the Find field in the left split view is empty), rather than the search in the right split view. After 10., the Find box corresponding to the right-side view remains visible. EXPECTED RESULT In 9., the search on the right split view is continued. In 10., it switches back to the left split view's Find or Replace box (or hides any Find or Replace box, if it was closed in the left-side view). SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230806 KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.4.3-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 472712] Filesystem tree jumps to selected folder when expanding another folder
https://bugs.kde.org/show_bug.cgi?id=472712 Grósz Dániel changed: What|Removed |Added Summary|Filesystem tree jumps to|Filesystem tree jumps to |selected folder when|selected folder when |expanding a folder |expanding another folder -- You are receiving this mail because: You are watching all bug changes.
[kdialog] [Bug 472715] New: KDialog shows file selector instead of folder selector
https://bugs.kde.org/show_bug.cgi?id=472715 Bug ID: 472715 Summary: KDialog shows file selector instead of folder selector Classification: Applications Product: kdialog Version: 23.04.3 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: br...@frogmouth.net Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 160573 --> https://bugs.kde.org/attachment.cgi?id=160573=edit Screenshot SUMMARY kdialog --getexistingdirectory shows a regular file dialog instead of a folder dialog. And it's hard to use if a single click is configured to open a file/folder, since clicking a folder opens it inside the dialog rather than selecting it, and Open doesn't work if no folder is selected. STEPS TO REPRODUCE 1. kdialog --getexistingdirectory 2. Click a folder. 3. Click Open. OBSERVED RESULT 1. The sort of dialog used to select a regular file. 2. The folder is opened. 3. Nothing. EXPECTED RESULT 1. A folder selection dialog. 2. The folder is selected. 3. The dialog returns the selected folder. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230724 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.4.3-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION Just like Bug 419874, except that affected more (all?) applications. This time, I've only seen it in kdialog; the usual folder selection dialog is used both by KDE applications and Firefox. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 472712] New: Filesystem tree jumps to selected folder when expanding a folder
https://bugs.kde.org/show_bug.cgi?id=472712 Bug ID: 472712 Summary: Filesystem tree jumps to selected folder when expanding a folder Classification: Frameworks and Libraries Product: frameworks-kio Version: 5.108.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kio-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com CC: kdelibs-b...@kde.org Target Milestone: --- Created attachment 160572 --> https://bugs.kde.org/attachment.cgi?id=160572=edit Screen recording (Kate Filesystem panel) SUMMARY This report pertains to the filesystem browser's tree view mode in the Open/Save dialogs and the Filesystem (or Open File) panels in Kate, KDevelop and Kile. It doesn't come up in Dolphin(part). Sometimes a folder gets into a selected state, and from then on, the filesystem view scrolls to that folder whenever you expand another folder in the tree if the selected folder off the screen. This is inconvenient because it scrolls away from the folder you expanded. (It's mostly an issue in the Filesystem panels, which are persistently open; it's less of an issue in the file dialogs.) See attached screen recording. - If you click a file in (e.g.) the Kate Filesystem panel, it opens, but the file is immediately deselected, so the problem doesn't occur. - If you right-click a file or folder to open its context menu, and then close the context menu, it remains selected, but the selection disappears if you expand a folder, so the problem doesn't occur. - If you click on a folder in the Filesystem panel to open it, then use the Back or Up button to go back, then it stays selected. That's when the problem occurs. (I'm not sure if there are other ways to trigger it.) STEPS TO REPRODUCE 0. Go to a folder that contains many files either directly or in subfolders. 1. Click on a subfolder. 2. Click Up or Back to go back to the folder containing it. (The folder you previously opened stays selected.) 3. Scroll the panel's contents such that the selected folder is off the screen. (Expand some folders beforehand if necessary.) 4. Click on the + or > sign to expand a folder. OBSERVED RESULT The filesystem browser jumps (scrolls) to the selected folder. EXPECTED RESULT The filesystem browser's contents stay where they are (except of course files/folders below the folder you expand are shifted down) so you can see the contents of the folder you expand immediately, just like when nothing is selected. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230724 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.4.3-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kontact] [Bug 472500] New: Undo send popup not shown
https://bugs.kde.org/show_bug.cgi?id=472500 Bug ID: 472500 Summary: Undo send popup not shown Classification: Applications Product: kontact Version: 5.23.3 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: mail Assignee: kdepim-b...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY KMail has an Undo Send feature, which delays sending e-mail by (by default) 10 seconds, during which a popup is shown, which can be used to cancel sending the e-mail. However, when using it through Kontact, sending is delayed, but the popup is not shown, so it can't actually be cancelled. STEPS TO REPRODUCE 1. Configure Kontact / Mail / Accounts / Sending / Enable Undo Send. 2. Send an e-mail. OBSERVED RESULT No popup to undo sending. EXPECTED RESULT Popup shown. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230718 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.3.7-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 471901] Clicking Compact View temporarily behaves like Icons View (text below icons)
https://bugs.kde.org/show_bug.cgi?id=471901 Grósz Dániel changed: What|Removed |Added Severity|minor |normal --- Comment #4 from Grósz Dániel --- (In reply to Szczepan Hołyszewski from comment #3) > While this bug doesn't cause any substantial denial of functionality, the > sheer annoyance factor warrants classifying is as something bigger than > "minor". I changed it to Normal. I reported it as minor because it doesn't matter if one doesn't regularly switch between view modes (which I don't). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 471901] Clicking Compact View temporarily behaves like Icons View (text below icons)
https://bugs.kde.org/show_bug.cgi?id=471901 --- Comment #2 from Grósz Dániel --- Created attachment 160060 --> https://bugs.kde.org/attachment.cgi?id=160060=edit Icons View -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 471901] Clicking Compact View temporarily behaves like Icons View (text below icons)
https://bugs.kde.org/show_bug.cgi?id=471901 --- Comment #1 from Grósz Dániel --- Created attachment 160059 --> https://bugs.kde.org/attachment.cgi?id=160059=edit The usual appearance of Compact View -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 471901] New: Clicking Compact View temporarily behaves like Icons View (text below icons)
https://bugs.kde.org/show_bug.cgi?id=471901 Bug ID: 471901 Summary: Clicking Compact View temporarily behaves like Icons View (text below icons) Classification: Frameworks and Libraries Product: frameworks-kio Version: 5.107.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Open/save dialogs Assignee: kio-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com CC: kdelibs-b...@kde.org Target Milestone: --- Created attachment 160058 --> https://bugs.kde.org/attachment.cgi?id=160058=edit The buggy appearance of Compact View SUMMARY In an Open or Save dialog, there are three buttons on the toolbar for Icons View (text below icons, typically bigger icons), Compact View (text normally next to icons, typically small icons) and Details View. However, if I click Compact View, the dialog switches to an appearance where the file names appear below the icons (like in the Icons View), but the icons' size is as in the Compact View. This happens whether the dialog is already in Compact View mode or not. However, if I close the window in this state, and later open it again, it's in the normal Compact View mode. STEPS TO REPRODUCE 1. Open an Open or Save dialog. 2. In the toolbar, click the Compact View button. OBSERVED RESULT File names below the icons. EXPECTED RESULT File names next to the icons. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230629 KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 Kernel Version: 6.3.7-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 471234] Moving between Deltas in the Diff Windows doesn't work if Word Wrap is on
https://bugs.kde.org/show_bug.cgi?id=471234 --- Comment #2 from Grósz Dániel --- No, I just built the latest master (9e64a479ad3c1588b436cb1b1e4c3b57972ff20b, with Qt 5), and this bug is present there too. The bug where no text was shown is fixed in both 1.10.4 and master. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 471234] New: Moving between Deltas in the Diff Windows doesn't work if Word Wrap is on
https://bugs.kde.org/show_bug.cgi?id=471234 Bug ID: 471234 Summary: Moving between Deltas in the Diff Windows doesn't work if Word Wrap is on Classification: Applications Product: kdiff3 Version: 1.10.4 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: reeves...@gmail.com Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY If Word Wrap Diff Windows is on, the Move to Next Delta and similar buttons scroll to the top of the diff panes instead of scrolling to a difference, also the active difference isn't highlighted. Scrolling and highlighting the differences only works in the Output pane. STEPS TO REPRODUCE 1. Check Diffview/Word Wrap Diff Windows. 2. Press the Go to Next Delta button (or Go to Next Conflict, Go to Active Delta, Go to Previous Delta etc.). OBSERVED RESULT The diff panes are scrolled to the top, and no delta is highlighted. EXPECTED RESULT Works just like if word wrap is off, except lines are wrapped. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230613 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.9 Kernel Version: 6.3.7-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION May be related to Bug 469817 (no text shown at all when word wrap was on) and Bug 442582 (similar bug except that it was the Output pane that was scrolled to the top instead of the next delta, rather than the Diff windows; also, the bug I'm reporting was mentioned in its Comment 4). -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 471060] New: Filesystem sidebar context menu / Open with / [App] shows Choose Application dialog
https://bugs.kde.org/show_bug.cgi?id=471060 Bug ID: 471060 Summary: Filesystem sidebar context menu / Open with / [App] shows Choose Application dialog Classification: Applications Product: kate Version: 23.04.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY If I try to open a file with a different application (or a directory with a file manager) using the Filesystem sidebar's context menu, it asks what application I want to open it with (as if I clicked Open With/Other) even if I've already clicked on an application. STEPS TO REPRODUCE 1. In the Filesystem panel, right click on a file, directory, or the empty space below the icons. 2. In Open With, click on an application. OBSERVED RESULT Shows the Choose Application dialog. EXPECTED RESULT Opens the file/directory with the chosen application. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230613 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.9 Kernel Version: 6.3.7-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION Works as expected in the Projects and the Documents panels. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 470390] New: Other splits forgotten if I quit in "Hide Inactive Views" mode
https://bugs.kde.org/show_bug.cgi?id=470390 Bug ID: 470390 Summary: Other splits forgotten if I quit in "Hide Inactive Views" mode Classification: Applications Product: kate Version: 23.04.1 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: sessions Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY If you use saved sessions and split views, and quit Kate while the "Hide Inactive Views" mode is active, and then reopen Kate, the other split views are forgotten, as if they had been closed completely, rather than just hidden. The list of open files is preserved though, so files that were only open in a hidden split view remain available in the Documents plugin and in the Ctrl+Tab switcher Additionally, if there was only one tab in the visible view (and thus after reopening Kate), then the katepart menu and toolbar items are not loaded when reopening Kate. STEPS TO REPRODUCE 1. Open a saved session. 2. Click Split Vertical (if you don't have split views already). 3. Click Hide Inactive Views. Optionally, open some documents in each view. 4. Quit Kate. 5. Open Kate again with the same session. OBSERVED RESULT The Hide Inactive Views action is inactive and disabled, as when there is only one view. The Split Vertical and Split Horizontal actions are enabled. If, at this point, there is only one visible tab, actions provided by katepart are missing from the menus and the toolbar, albeit the file is visible and can be edited. EXPECTED RESULT The Hide Inactive Views action is enabled and active. The Split actions are disabled, as when Hide Inactive Views is enabled. Clicking Hide Inactive Views inactivates it, and the other split view(s) are there again. The katepart actions are available. Even if saving the Hide Inactive Views state in sessions isn't implemented, I'd expect all split views to be remembered, rather than just the one that was visible before quitting. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230527 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.3.1-2-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 469817] No text shown when word wrap is on
https://bugs.kde.org/show_bug.cgi?id=469817 --- Comment #2 from Grósz Dániel --- Maybe related to the recently fixed Bug 468492. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 469817] No text shown when word wrap is on
https://bugs.kde.org/show_bug.cgi?id=469817 --- Comment #1 from Grósz Dániel --- Created attachment 158979 --> https://bugs.kde.org/attachment.cgi?id=158979=edit Screenshot with the same files, with word wrap off -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 469817] New: No text shown when word wrap is on
https://bugs.kde.org/show_bug.cgi?id=469817 Bug ID: 469817 Summary: No text shown when word wrap is on Classification: Applications Product: kdiff3 Version: 1.10.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: reeves...@gmail.com Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 158978 --> https://bugs.kde.org/attachment.cgi?id=158978=edit Screenshot with word wrap on SUMMARY When word wrap is turned on, all text in the diff view disappears. STEPS TO REPRODUCE 1. Open some files in a 2- or 3-way diff. 2. Turn on Diffview/Word Wrap Diff Windows. OBSERVED RESULT No text in the diff views; all white (see screenshot). EXPECTED RESULT The text is shown, with word wrap. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230513 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.3.1-2-default (64-bit) Graphics Platform: X11 Graphics Processor: Mesa Intel® UHD Graphics 620 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 468672] "Save Copy As" does not create new file or does not save into existing file
https://bugs.kde.org/show_bug.cgi?id=468672 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com --- Comment #1 from Grósz Dániel --- Same here. Maybe related to the fixing of Bug 466571. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 467635] On X11, cursor stuck dragging when hovering over Task Manager after streaming with Moonlight
https://bugs.kde.org/show_bug.cgi?id=467635 Grósz Dániel changed: What|Removed |Added CC||groszdaniel...@gmail.com --- Comment #1 from Grósz Dániel --- The same thing has happened to me a few times lately, I don't know what triggers it in my case. Operating System: openSUSE Tumbleweed 20230403 KDE Plasma Version: 5.27.3 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.8-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468180] New: Plasmashell crashed after closing a notification
https://bugs.kde.org/show_bug.cgi?id=468180 Bug ID: 468180 Summary: Plasmashell crashed after closing a notification Classification: Plasma Product: plasmashell Version: 5.27.3 Platform: openSUSE OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: groszdaniel...@gmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 Application: plasmashell (5.27.3) Qt Version: 5.15.8 Frameworks Version: 5.104.0 Operating System: Linux 6.2.8-1-default x86_64 Windowing System: X11 Distribution: "openSUSE Tumbleweed" DrKonqi: 5.27.3 [KCrashBackend] -- Information about the crash: Plasmashell occasionally crashes when closing an e-mail notification from KMail. It has happened at least three times, once in a few days. The backtrace is very similar to Bug 461072. But it still happens on plasmashell 5.27.3 (and it only started happening in the last few weeks, or at least it became more frequent), while that bug was fixed/worked around in January. The crash can be reproduced sometimes. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault [KCrash Handler] #4 0x7f5fd8e9364d in QScopedPointer >::operator->() const (this=0x8) at /usr/include/qt5/QtCore/qscopedpointer.h:118 #5 qGetPtrHelper > >(QScopedPointer >&) (ptr=...) at /usr/include/qt5/QtCore/qglobal.h:1149 #6 QQmlEngine::d_func() (this=0x0) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/qml/qqmlengine.h:172 #7 QQmlEnginePrivate::get(QQmlEngine*) (e=0x0) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/qml/qqmlengine_p.h:424 #8 QtQml::qmlExecuteDeferred(QObject*) (object=object@entry=0x563a12a8ee70) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/qml/qqmlengine.cpp:1592 #9 0x7f5fd9378a99 in QQuickTransition::prepare(QList&, QList&, QQuickTransitionManager*, QObject*) (this=this@entry=0x563a12a8ee70, actions=..., after=..., manager=manager@entry=0x7f5fc403b860, defaultTarget=defaultTarget@entry=0x563a12b36340) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/quick/util/qquicktransition.cpp:259 #10 0x7f5fd936e2d7 in QQuickTransitionManager::transition(QList const&, QQuickTransition*, QObject*) (this=0x7f5fc403b860, list=, transition=0x563a12a8ee70, defaultTarget=0x563a12b36340) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/quick/util/qquicktransitionmanager.cpp:207 #11 0x7f5fd7918d2b in QObject::event(QEvent*) (this=0x563a12b36340, e=0x7ffec425bd10) at kernel/qobject.cpp:1369 #12 0x7f5fd85a52ce in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=, receiver=0x563a12b36340, e=0x7ffec425bd10) at kernel/qapplication.cpp:3640 #13 0x7f5fd78ecb28 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x563a12b36340, event=0x7ffec425bd10) at kernel/qcoreapplication.cpp:1064 #14 0x7f5fd79454a9 in QTimerInfoList::activateTimers() (this=0x563a0c853860) at kernel/qtimerinfo_unix.cpp:643 #15 0x7f5fd7945d8c in timerSourceDispatch (source=) at kernel/qeventdispatcher_glib.cpp:183 #16 idleTimerSourceDispatch(GSource*, GSourceFunc, gpointer) (source=) at kernel/qeventdispatcher_glib.cpp:230 #17 0x7f5fd6359f96 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #18 0x7f5fd635a358 in () at /lib64/libglib-2.0.so.0 #19 0x7f5fd635a3ec in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #20 0x7f5fd79460b6 in QEventDispatcherGlib::processEvents(QFlags) (this=0x563a0c853cb0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #21 0x7f5fd78eb5cb in QEventLoop::exec(QFlags) (this=this@entry=0x7ffec425bf50, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #22 0x7f5fd78f3a50 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #23 0x7f5fd7d6fe4c in QGuiApplication::exec() () at kernel/qguiapplication.cpp:1870 #24 0x7f5fd85a5245 in QApplication::exec() () at kernel/qapplication.cpp:2832 #25 0x563a0c56447d in main(int, char**) (argc=, argv=) at /usr/src/debug/plasma-workspace-5.27.3/shell/main.cpp:235 [Inferior 1 (process 13998) detached] The reporter indicates this bug may be a duplicate of or related to bug 461072, bug 462715, bug 463956, bug 465706. Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 467322] LSP: show regular tooltip alongside error/warning
https://bugs.kde.org/show_bug.cgi?id=467322 --- Comment #2 from Grósz Dániel --- Created attachment 157266 --> https://bugs.kde.org/attachment.cgi?id=157266=edit VS Codium showing both (showing that the server provides both) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 467322] LSP: show regular tooltip alongside error/warning
https://bugs.kde.org/show_bug.cgi?id=467322 --- Comment #1 from Grósz Dániel --- Created attachment 157265 --> https://bugs.kde.org/attachment.cgi?id=157265=edit Regular tooltip (after using the variable) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 467322] New: LSP: show regular tooltip alongside error/warning
https://bugs.kde.org/show_bug.cgi?id=467322 Bug ID: 467322 Summary: LSP: show regular tooltip alongside error/warning Classification: Applications Product: kate Version: 22.12.3 Platform: openSUSE OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 157264 --> https://bugs.kde.org/attachment.cgi?id=157264=edit Tooltip with warning only The LSP plugin can show tooltips hovering over identifiers, such as the type of a variable. Also, when hovering over code with an error or warning, it shows the message in a different kind of tooltip. However, the tooltip containing the error message *replaces* the regular tooltip; if a variable is in a part of the code that results in a warning, one can't see the tooltip containing the type of the variable, even when it would still be meaningful, and it's still provided by the language server. A common occurrence where this is a problem is when I define a new variable with an automatically deduced type (in Typescript, but it could also be C++), and I'd like to see the deduced type, the language server immediately warns me that it's unused, and so I can't view the deduced type until I use the variable. I suggest showing a tooltip that contains both the regular tooltip (e.g. the type of a variable) and the error message when possible. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230312 KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.1-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 466621] New: Crash when closing a particular PDF file·
https://bugs.kde.org/show_bug.cgi?id=466621 Bug ID: 466621 Summary: Crash when closing a particular PDF file· Classification: Applications Product: okular Version: 22.12.2 Platform: openSUSE OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Application: okular (22.12.2) Qt Version: 5.15.8 Frameworks Version: 5.103.0 Operating System: Linux 6.1.8-1-default x86_64 Windowing System: X11 Distribution: "openSUSE Tumbleweed" DrKonqi: 5.27.1 [KCrashBackend] -- Information about the crash: Okular crashes when closing a particular file, which contains forms and a digital signature. This seems to be new in Okular 22.12.2. The file contains mildly sensitive data, so I'd rather not attach it publicly, but I can send it to Okular developers if it's needed. The crash can be reproduced every time. -- Backtrace: Application: Okular (okular), signal: Segmentation fault [KCrash Handler] #4 0x7fad087e65dc in PORT_FreeArena_Util (arena=0x2800100, zero=0) at /usr/src/debug/nss-3.87/nss/lib/util/secport.c:370 #5 0x7fad08385e5f in pkix_pl_Cert_Destroy (object=0x563fbdd39a68, plContext=0x563fbdca4120) at ../libpkix/pkix_pl_nss/pki/pkix_pl_cert.c:1167 #6 0x7fad0839a08b in PKIX_PL_Object_DecRef (object=0x563fbdd39a68, plContext=0x563fbdca4120) at ../libpkix/pkix_pl_nss/system/pkix_pl_object.c:891 #7 0x7fad083770fb in pkix_List_Destroy (object=0x563fb028, plContext=0x563fbdca4120) at ../libpkix/pkix/util/pkix_list.c:89 #8 0x7fad0839a08b in PKIX_PL_Object_DecRef (object=0x563fb028, plContext=0x563fbdca4120) at ../libpkix/pkix_pl_nss/system/pkix_pl_object.c:891 #9 0x7fad08377148 in pkix_List_Destroy (object=0x563fbdf36ec8, plContext=0x563fbdca4120) at ../libpkix/pkix/util/pkix_list.c:93 #10 0x7fad0839a08b in PKIX_PL_Object_DecRef (object=0x563fbdf36ec8, plContext=0x563fbdca4120) at ../libpkix/pkix_pl_nss/system/pkix_pl_object.c:891 #11 0x7fad08360d44 in pkix_BuildResult_Destroy (object=0x563fbdc267b8, plContext=0x563fbdca4120) at ../libpkix/pkix/results/pkix_buildresult.c:36 #12 0x7fad0839a08b in PKIX_PL_Object_DecRef (object=0x563fbdc267b8, plContext=0x563fbdca4120) at ../libpkix/pkix_pl_nss/system/pkix_pl_object.c:891 #13 0x7fad083770fb in pkix_List_Destroy (object=0x563fbddd82d8, plContext=0x563fbdca4120) at ../libpkix/pkix/util/pkix_list.c:89 #14 0x7fad0839a08b in PKIX_PL_Object_DecRef (object=0x563fbddd82d8, plContext=0x563fbdca4120) at ../libpkix/pkix_pl_nss/system/pkix_pl_object.c:891 #15 0x7fad08377148 in pkix_List_Destroy (object=0x563fbddd8248, plContext=0x563fbdca4120) at ../libpkix/pkix/util/pkix_list.c:93 #16 0x7fad0839a08b in PKIX_PL_Object_DecRef (object=0x563fbddd8248, plContext=plContext@entry=0x563fbdca4120) at ../libpkix/pkix_pl_nss/system/pkix_pl_object.c:891 #17 0x7fad0839a831 in pkix_pl_HashTable_Destroy (object=0x563fbddaba08, plContext=0x563fbdca4120) at ../libpkix/pkix_pl_nss/system/pkix_pl_hashtable.c:77 #18 0x7fad0839a08b in PKIX_PL_Object_DecRef (object=0x563fbddaba08, plContext=0x563fbdca4120) at ../libpkix/pkix_pl_nss/system/pkix_pl_object.c:891 #19 0x7fad083bb674 in PKIX_Shutdown.isra.0 (plContext=0x563fbdca4120) at ../libpkix/pkix/top/pkix_lifecycle.c:186 #20 0x7fad082f40f0 in nss_Shutdown () at /usr/src/debug/nss-3.87/nss/lib/nss/nssinit.c:1157 #21 0x7fad082f4eb0 in NSS_Shutdown () at /usr/src/debug/nss-3.87/nss/lib/nss/nssinit.c:1221 #22 NSS_Shutdown () at /usr/src/debug/nss-3.87/nss/lib/nss/nssinit.c:1200 #23 0x7fad02645869 in shutdownNss () at /usr/src/debug/poppler-23.02.0/poppler/SignatureHandler.cc:269 #24 0x7fad44645795 in __run_exit_handlers () from /lib64/libc.so.6 #25 0x7fad44645910 in exit () from /lib64/libc.so.6 #26 0x7fad4462caf7 in __libc_start_call_main () from /lib64/libc.so.6 #27 0x7fad4462cbb9 in __libc_start_main_impl () from /lib64/libc.so.6 #28 0x563fbc165d05 in _start () at ../sysdeps/x86_64/start.S:115 [Inferior 1 (process 24582) detached] Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 466553] New: Switching sessions when a file has been modified or deleted creates mixed session
https://bugs.kde.org/show_bug.cgi?id=466553 Bug ID: 466553 Summary: Switching sessions when a file has been modified or deleted creates mixed session Classification: Applications Product: kate Version: 22.12.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: sessions Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY If an open file has been modified in Kate and/or deleted on disk, and you switch sessions, Kate asks you to confirm. If you click Cancel, Kate proceeds with opening the session you chose anyway. However, the files that were already open remain open according to the Documents sidebar, and get added to the newly opened session. Switching back-and-forth in this manner can even result in the same file being open multiple times, independently. STEPS TO REPRODUCE 1. Open some files, and save the session (Session 1). 2. Delete some of the open files on disk. (Alternatively, modify some files.) 3. Open another session from Sessions/Recent Sessions (Session 2). 4. When Kate asks "The file '...' was deleted on disk. Do you really want to continue to close this file? Data loss may occur.", click Cancel. (If you both modified some files and deleted them on disk, Kate first asks if you want Overwrite, Reload or Ignore Changes; then it asks if you want to Save, Discard or Cancel, choose Cancel.) OBSERVED RESULT Kate opens the files from Session 2, but files from Session 1 stay in the list of open files in the Documents sidebar, without being associated with any tab. Even if you quit Kate, and then start it again and choose Session 2, the files from Session 1 are opened too. If you open such a file from the Documents sidebar, it gets opened in a tab, and its contents are preserved if you haven't quit Kate and started it again, but if you did, and it's a file that was deleted on disk and not modified in Kate, it's opened as an empty file. EXPECTED RESULT Kate cancels the operation entirely. Session 1 remains open, and Session 2 isn't opened. If the deleted files are not modified, it's also acceptable to close them without asking for confirmation. That's what happens if you delete a file on the disk that's open and not modified, and then close Kate without focusing the file's editor tab in the meantime. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230226 KDE Plasma Version: 5.27.1 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.8-1-default (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 466316] New: Sidebar section arrangement forgotten when switching sessions
https://bugs.kde.org/show_bug.cgi?id=466316 Bug ID: 466316 Summary: Sidebar section arrangement forgotten when switching sessions Classification: Applications Product: kate Version: 22.12.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: sessions Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY A recent Kate release changed how one can open multiple sidebars on the same side of the window: in the context menu of a sidebar tab, one can click (Move To) Own Section; one can then move some other sidebars into the new section, and one can open one sidebar from each section. These arrangements are properly saved into sessions when quitting and reopening Kate. However, if I switch between sessions using the Sessions menu, these arrangements are forgotten. STEPS TO REPRODUCE 1. Have multiple sessions, and open one. 2. Right-click a sidebar tab (icon/label), and click Own Section, and (optionally) open a sidebar in each section. 3. Switch to a different session using the Sessions menu (using Recent Sessions, All Sessions or Manage Sessions...). 4. Switch back to the previously used session (in which you created sidebar sections) using the Sessions menu. OBSERVED RESULT The sidebars on a given side of the window are in a single section again, and only one is open. EXPECTED RESULT The sidebars (how they are arranged into sections and which ones are open) are as they were when the session was last used. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230222 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.8-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION The workaround, of course, is to avoid switching sessions using the Sessions menu; just quit Kate if you don't need the current session to be open any more, and start it again with the desired session. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 465814] Ctrl+Tab order should be separate per split view
https://bugs.kde.org/show_bug.cgi?id=465814 --- Comment #4 from Grósz Dániel --- (In reply to Waqar Ahmed from comment #3) > We have decided to keep the behaviour for now. See linked MR: > https://invent.kde.org/utilities/kate/-/merge_requests/1113 Regarding the comments there (not sure if I should respond here or there): I didn't propose changing the Documents sidebar at all (I like its current behavior of opening any file you click in the focused split), only the Ctrl+Tab behavior. VSCode has tabs, and Ctrl+Tab works like I proposed (separate orders, and only showing the tabs in the current split view). Qt Creator doesn't have a concept of which files are open in a given split view, but the Ctrl+Tab order is per-split there too. Visiting a file in one split doesn't bring it forward in the Ctrl+Tab order of another split. KDevelop, OTOH, works like Kate currently; there, the equivalent of my proposal is a confirmed request since 2013: Bug 323218. Eclipse seems to behave rather differently, such that views can be arranged in many ways, and it seems to have a single Ctrl+Tab order, but it will switch to a different (split) view if necessary, rather than open a file in the current view. In LyX (not a plain text editor, but also has tabs and splits), Ctrl+Tab switches in the order tabs are on the tab bar, per-split, rather than in the order they have been last used. (Kate has different shortcuts for this by default.) However, I was wrong that the current Kate Ctrl+Tab behavior started last year: I built 21.12 and it also worked like this. I guess I thought it started with 22.04 because the most noticeable effect—Ctrl+Tab reopening a tab I just closed with Ctrl+W—didn't happen until then because closing a tab closed it everywhere. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 465368] File dialogs don't handle sftp/fish redirects well
https://bugs.kde.org/show_bug.cgi?id=465368 --- Comment #1 from Grósz Dániel --- I wrote that Dolphin was unaffected, but since then I found that it's actually affected by a similar issue (or in a sense an inverse of this one): there, the Location bar doesn't reflect the redirect, but otherwise (e.g. if a file is opened) it behaves correctly: Bug 465915. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 465915] New: Location bar not reflecting sftp/fish redirect
https://bugs.kde.org/show_bug.cgi?id=465915 Bug ID: 465915 Summary: Location bar not reflecting sftp/fish redirect Classification: Applications Product: dolphin Version: 22.12.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: bars: location Assignee: dolphin-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY If you enter an sftp or fish URL without any path in the Location bar, one is normally redirected to the user's home directory on the server, as SFTP clients usually behave. However, this is not reflected in the Location bar. Also, the Up action becomes inactive. The bug only comes up if you enter the URL without any path, not even a trailing slash. If you enter a trailing slash, it opens the server's root directory without any redirection, and it behaves normally. STEPS TO REPRODUCE Write sftp://user@host in the location bar or the Name input field, and press Enter. OBSERVED RESULT The contents of a directory like sftp://user@host/home/user are listed, but the Location bar continues to contain sftp://user@host, and the Go/Up menu item (or toolbar button, if visible) is disabled. EXPECTED RESULT The Location bar changes to sftp://user@host/home/user; the Up action is active, and (in this example) goes to sftp://user@host/home. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230215 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.8-1-default (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION I don't know if the issue affects any protocol other than sftp and fish. I don't remember if ftp has a similar redirect functionality, as I haven't used it in ages; I've no idea about stuff like smb, ldap, webdav or gdrive. In Konqueror, Gwenview and Krusader, the redirect is reflected in the Location bar, only Dolphin seems to be affected. A similar bug (or rather the inverse of it) affects file dialogs: the redirect is reflected in the Location bar, but when a file is selected, the dialog behaves as if one was in the server's root directory: Bug 465368. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 465814] Ctrl+Tab order should be separate per split view
https://bugs.kde.org/show_bug.cgi?id=465814 --- Comment #1 from Grósz Dániel --- > EXPECTED RESULT > If you hold Ctrl, the files are listed in the order B, A, with A selected. > When you release the Ctrl, File B becomes the active tab on the right side. Sorry, I meant that File A should become active on the right side. And only B and A should be listed. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 465814] New: Ctrl+Tab order should be separate per split view
https://bugs.kde.org/show_bug.cgi?id=465814 Bug ID: 465814 Summary: Ctrl+Tab order should be separate per split view Classification: Applications Product: kate Version: 22.12.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY The Ctrl+Tab tab switcher (aka Last Used Views) currently navigates through open files in reverse order of when they were last focused *across all split views*, not just the current one. It is also willing to create new tabs, as it allows switching to a file that's open in another split view, but not the currently focused one. In particular, closing a file with Ctrl+W, then pressing Ctrl+Tab, results in reopening the file just closed if it's open in another split. (However, files that have been closed in every view can't be switched to.) Instead, there should be separate Ctrl+Tab orders for each split view. Each one should only contain the files that are open in that view, in reverse order of when they were last active in that view. STEPS TO REPRODUCE Many ways. For example: 1. Start Kate with a new session. 2. Open File A. 3. Click Split Vertical. 4. Open File B on the right side. 5. Click on the left side, then open File C there. 6. Click on the right side to focus it. 7. Press Ctrl+Tab. OBSERVED RESULT If you hold Ctrl, the files are listed in the order B, C, A, with C selected. When you release the Ctrl, File C is opened on the right side, becoming the active tab. EXPECTED RESULT If you hold Ctrl, the files are listed in the order B, A, with A selected. When you release the Ctrl, File B becomes the active tab on the right side. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230214 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Graphics Platform: X11 ADDITIONAL INFORMATION I'm not entirely sure if this should be filed as a bug or a wish, but the current behavior is weird, unusual, and in particular the fact that an Alt+Tab-style switcher can (re)open a new tab definitely feels like a bug. IIRC the current behavior started with one of last year's major releases, IIRC the one that made it so that closing a tab in one split view doesn't close the file in other split view(s) where it's open. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 465812] New: Files in Filesystem panel duplicated when starting new session
https://bugs.kde.org/show_bug.cgi?id=465812 Bug ID: 465812 Summary: Files in Filesystem panel duplicated when starting new session Classification: Applications Product: kate Version: 22.12.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: sessions Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 156288 --> https://bugs.kde.org/attachment.cgi?id=156288=edit Screenshot SUMMARY If the Filesystem sidebar is open, and you start a new session, files start to appear twice in the sidebar. This only happens if the Filesystem sidebar doesn't switch to a different directory when starting a new session. (If a saved session is open, the sidebar may switch to a different directory, I guess to the last location that was open in the Filesystem sidebar when an anonymous session was used.) Only files are duplicated, not directories. The issue goes away once you change the location in the sidebar. STEPS TO REPRODUCE 1. Make sure the Filesystem sidebar is open. 2. Click Sessions/New Session. 3. If the sidebar goes to a different location, click Sessions/New Session again. OBSERVED RESULT Files appear twice in the sidebar. (See screenshot.) EXPECTED RESULT Files appear once in the sidebar. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230214 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 465811] New: Kate sometimes fails to load katepart when closing a tab in another split in a session
https://bugs.kde.org/show_bug.cgi?id=465811 Bug ID: 465811 Summary: Kate sometimes fails to load katepart when closing a tab in another split in a session Classification: Applications Product: kate Version: 22.12.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- Created attachment 156287 --> https://bugs.kde.org/attachment.cgi?id=156287=edit Screenshot SUMMARY Under some circumstances, when Kate would have to load a tab in another split view that hasn't been active since Kate was started (which can happen if the tab comes from a saved session), it fails to load the editor component. See screenshot. STEPS TO REPRODUCE 1. Start Kate with a new session. 2. Open File A. 3. Click Split Vertical. Now file A is open on both sides, and the right side is focused. 4. Open File B. 5. Click in the editor on the left side to focus it. 6. Open File B there too. 7. Click the tab with File A on the right side split to activate and focus it. 8. Save the session. 9. Close Kate. 10. Open Kate again, and open the session just created. A and B are open on both sides, B is active on the left side, A on the right side, and the right side has keyboard focus. 11. Click in the editor on the left side to focus it. 12. Close Tab A on the right side with the X button. OBSERVED RESULT On the right side,, Kate switches to Tab B, but it fails to load the katepart, resulting in an empty area where the editor should be. (See screenshot.) EXPECTED RESULT The editor on the right side view is loaded. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230214 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Graphics Platform: X11 ADDITIONAL INFORMATION Might be related to Bug 465807 or Bug 465808. In many circumstances (such as if you skip Step 6, so B is not opened on the left side), Bug 465808 occurs too, i.e. Kate switches to a different file on the focused side. (Katepart is loaded correctly there.) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 465807] Closing tab sometimes switches to next split
https://bugs.kde.org/show_bug.cgi?id=465807 Grósz Dániel changed: What|Removed |Added Platform|Other |openSUSE --- Comment #1 from Grósz Dániel --- May be related to Bug 465808; this one is about closing a tab in the view with keyboard focus, that one about closing a tab in the other view. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 465808] New: Closing tab in other split changes tabs in current split
https://bugs.kde.org/show_bug.cgi?id=465808 Bug ID: 465808 Summary: Closing tab in other split changes tabs in current split Classification: Applications Product: kate Version: 22.12.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: groszdaniel...@gmail.com Target Milestone: --- SUMMARY If there are split views, and I close a tab in the split view *other than* the one that currently has keyboard focus, it (sometimes) switches tabs also on the side that has had keyboard focus: namely it switches to the file on the focused side that becomes active on the other side (which may be a newly activated tab if the active tab was closed, or the tab that was already active in the other split view if an inactive tab was closed). This may even involve opening a file on the focused side that hasn't previously been open there. Also, keyboard focus usually moves to the right-hand split view (in the case of a vertical split). The issue as described above doesn't always happen; I'm not sure about the exact conditions, but at least it's not reliably reproducible if some of the tabs involved come from a saved session, and haven't been active since Kate was opened. STEPS TO REPRODUCE 1. Start Kate with an empty session. 2. Open File A. 3. Click Split Vertical. Now file A is open on both sides, and the right side is focused. 4. Open File C. 5. Click in the editor on the left side to focus it. 6. Open File B. Now A and B are opened on the left, A and C on the right, with B and C respectively being the active tabs, and B having keyboard focus. 7. Close C by clicking on the X button in the tab. (Alternative: 7'. Click in the editor on the right to focus it, then close B by clicking on the X button in the tab.) OBSERVED RESULT On the left side, Tab A becomes active (while B remains open). On the right side, C is closed, A becomes active, and obtains keyboard focus. (In the alternative version: On the right side, Tab A becomes active, while C remains open. On the left side, B is closed, A becomes active. Keyboard focus goes to A on the right side.) EXPECTED RESULT The left split view remains unchanged. On the right side, C is closed, and A becomes active. (In the alternative version: The right split view remains unchanged. On the left side, B is closed, and A becomes active.) Also, keyboard focus should be handled consistently: it should either always remain in the view that previously had it (probably the more reasonable option), or always switch to the view in which a tab was closed. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230214 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Graphics Platform: tried both X11 and Wayland; it doesn't matter ADDITIONAL INFORMATION May be related to Bug 465807; that one is about closing a tab in the view with keyboard focus, this one about closing a tab in the other view. In particular, the keyboard focus always ending up on the right is probably the same issue. The ancient Bug 77525 also seems similar. -- You are receiving this mail because: You are watching all bug changes.
