[kate] [Bug 480399] New: allow filtering diagnostics by severity / pattern
https://bugs.kde.org/show_bug.cgi?id=480399
Bug ID: 480399
Summary: allow filtering diagnostics by severity / pattern
Classification: Applications
Product: kate
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: application
Assignee: kwrite-bugs-n...@kde.org
Reporter: k...@dhardy.name
Target Milestone: ---
SUMMARY
***
Request: allow diagnostics to be ignored by [diagnostic
severity](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnosticSeverity)
and/or pattern.
Rust supports disabling code at compile-time via feature flags. Its LSP server,
rust-analyzer, will report an *information* diagnostic whenever it encounters
code which is code which is disabled this way (I find this behaviour dubious,
but rust-analyzer is tested against VS Code and is presumably okay there).
In Kate, these diagnostics result in each line of the disabled code section
being underlined and an info pop-up on mouse-over anywhere here. This behaviour
is useless and distracting. (Even if it were easy enough to switch the current
set of feature-flags to enable scanning of this code section, this behaviour
would still not be desirable since it is common to need to edit code both with
and without some feature, and the current underline is quite ugly for a block
of code while the pop-up just gets in the way.)
***
STEPS TO REPRODUCE
1. Set up a project with rust-analyzer
2. Add some code like: #[cfg(feature = "foo")] println("this message is only
printed with feature 'foo'");
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 476620] New: Option to disable diagnostic highlighting, completions
https://bugs.kde.org/show_bug.cgi?id=476620 Bug ID: 476620 Summary: Option to disable diagnostic highlighting, completions Classification: Applications Product: kate Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: k...@dhardy.name Target Milestone: --- SUMMARY - LSP client: add option to disable in-editor diagnostic highlighting. - LSP client: add option to disable completions. MOTIVATION The LSP client adds some extremely useful features like jump-to-definition, find-references, completions. However, some features can, at times, be extremely distracting; for example in-editor error highlighting is useful when compile-checking a new feature but is less useful (and potentially quite annoying) while writing a larger new feature. Completions are powerful, but also get in the way of looking at the surrounding code. Having the option to quickly en-/dis-able these two features during code development (instead of being limited to disabling the whole LSP client) would be much appreciated. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 472608] New: Search in files: Enter key should replace only current item
https://bugs.kde.org/show_bug.cgi?id=472608 Bug ID: 472608 Summary: Search in files: Enter key should replace only current item Classification: Applications Product: kate Version: 22.12.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: search Assignee: kwrite-bugs-n...@kde.org Reporter: k...@dhardy.name Target Milestone: --- In Kate, per-file search-replace works like this: - Press Ctrl+R to activate - Type in search query - Press or to go to next result - Press Tab to move to the "replace" box - Type in a replacement text/pattern - Press to replace the current result with the contents of the "replace" box. In contrast, cross-file search works like this: - Press or click the "Search" button to activate - Type in search query - Press or click "Search" to go to find all results - Press to go to the next result - Press Tab to move to the "replace" box - Type in a replacement text/pattern - Press to replace all results with the replacement pattern. The user experience differs, which is not intuitive. Suggestions for changes to the "Find in files" tool follow. Problem 1 (minor): pressing in the query box does not move to the first/next result. Suggestion: should perform the search if the query has changed, then move to the next result. Problem 2: pressing from the replacement box updates all results. Suggestion: should behave like per-file search-and-replace: replace the current result only and move to the next. Worse, there is no "all files undo". With the current behaviour it is easy to mistakenly run the wrong operation, and hard to revert if many files are affected. In my opinion, only the "Replace Checked" button (which is hard to press accidentally) should replace everything. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 468705] New: Autocomplete should prefer current input when this is a match
https://bugs.kde.org/show_bug.cgi?id=468705 Bug ID: 468705 Summary: Autocomplete should prefer current input when this is a match Classification: Applications Product: kate Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: part Assignee: kwrite-bugs-n...@kde.org Reporter: k...@dhardy.name Target Milestone: --- SUMMARY When generating autocomplete suggestions, consider words of min-autocomplete-length (default 3 chars) as valid candidates and make the preferred candidate. Currently autocompletion is frustrating enough when typing text with explicit line breaks that I *almost* want to turn it off. STEPS TO REPRODUCE 1. Start a new document and type in a few words including 'the' and these' 2. Write 'the' 3. Press to insert an explicit line-break OBSERVED RESULT 'the' is "completed" to 'these' EXPECTED RESULT Line break, or failing that autocomplete to 'the' (no effect except to close autocompletion) Exact behaviour here is debatable, but personally I find "completion" of a valid word when I just wanted to insert a line-break to be annoying! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456041] It's impossible to move apps grouped in the task manager to another virtual desktop with drag-and-drop
https://bugs.kde.org/show_bug.cgi?id=456041 Diggory Hardy changed: What|Removed |Added CC||k...@dhardy.name --- Comment #1 from Diggory Hardy --- Works for me (5.26.5). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 465329] New: Pager should not allow dragging windows on a single screen
https://bugs.kde.org/show_bug.cgi?id=465329 Bug ID: 465329 Summary: Pager should not allow dragging windows on a single screen Classification: Plasma Product: plasmashell Version: 5.26.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Pager Assignee: plasma-b...@kde.org Reporter: k...@dhardy.name CC: h...@kde.org Target Milestone: 1.0 SUMMARY Pager supports dragging windows from one virtual desktop to another. This is useful. Pager supports dragging a window around on a single virtual desktop & screen. This is not useful and should be removed. Not sure of case with multiple monitors. Motivation: it is common when click+dragging something to have a way to cancel the action; in this case the obvious solution is to drag back to the original virtual desktop. But that moves the window. I can't see how moving the window like this is ever desirable due to the lack of precision. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 461659] New: Kate sessions plugin replaces session of existing kate window instead of starting a new one
https://bugs.kde.org/show_bug.cgi?id=461659 Bug ID: 461659 Summary: Kate sessions plugin replaces session of existing kate window instead of starting a new one Classification: Plasma Product: krunner Version: 5.25.2 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: k...@dhardy.name CC: alexander.loh...@gmx.de Target Milestone: --- SUMMARY 1. In Kate, save two different sessions, lets say Foo and Bar. 2. Close all Kate windows. 3. In the launcher / krunner, search Foo to open the first named Kate session. 4. With this session still open, do the same again for the second named session, Bar. Result: the existing window containing the first session is replaced with the second session. (If I wanted to do this I would do so through the window's menus.) Expected (and old behaviour): launches a new Kate window with the second session. SOFTWARE/OS VERSIONS Fedora 37 beta, Wayland. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 460429] Notifier tray icon appears before notification does
https://bugs.kde.org/show_bug.cgi?id=460429 Diggory Hardy changed: What|Removed |Added CC||k...@dhardy.name --- Comment #4 from Diggory Hardy --- Partially relevant to this issue: Discover gives an "Updates available" notification, then when clicking on it Discover sits at "Fetching updates..." I would expect the notification not to appear until *after* package-update lists have been fetched, otherwise I'm just left waiting on the app when clicking the notification. Distro: Fedora 37 beta -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461061] New: Wayland: per-window scale factor
https://bugs.kde.org/show_bug.cgi?id=461061 Bug ID: 461061 Summary: Wayland: per-window scale factor Classification: Plasma Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: k...@dhardy.name Target Milestone: --- **Feature request:** support per-window scale factors Motivation -- Not all apps support scaling properly. Some (particularly fullscreen games) might have internal settings for scaling, but ignore the compositor-given scale factor. Some might simply not *need* scaling (at low screen scale factors) or be better forced to use 200% scaling where other windows are using 150-175%. Details --- Kwin already has "window rules" for forcing initial position etc. Allow these to force a scale factor too. Complication: coordinate systems. A little linear arithmetic and rounding is needed to translate window positions and sizes. I believe this is solvable. Complication: if the desktop already uses multiple screens with multiple scale factors, forcing some window to use a single scale factor everywhere makes less sense. Still, this is the simplest approach and often good enough. At most, there should be a per-screen look-up table of forced scales or an additional qualifier to the rule (which screen the window is on). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 415692] New: charging/discharging status is not obvious from icon
https://bugs.kde.org/show_bug.cgi?id=415692 Bug ID: 415692 Summary: charging/discharging status is not obvious from icon Product: plasmashell Version: 5.15.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Battery Monitor Assignee: k...@privat.broulik.de Reporter: k...@dhardy.name CC: plasma-b...@kde.org Target Milestone: 1.0 SUMMARY: not obvious whether battery is charging / discharging from icon SOLUTION: use significantly different icons for charging and discharging states Using Plasma with the Breeze theme, the system tray has a small, mostly black, battery icon. When charging, there is a lightning-bolt symbol on the battery. The problem is that the lightning-bolt symbol is very hard to see on a retina-level screen (~270 DPI), thus it is not obvious whether the charger is connected or not. (Yes, one can probably make all icons larger. I don't want that: part of the point of a high-resolution laptop screen is to get lots of content on the screen. Other than this little detail, icons are clear enough at ~20 pixels across.) -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 251496] Periodically save session state
https://bugs.kde.org/show_bug.cgi?id=251496 Diggory Hardy changed: What|Removed |Added CC||k...@dhardy.name --- Comment #5 from Diggory Hardy --- This is still the case with KDE 5. In my case the primary cause of restart seems to be power loss, thus the saved session state can be quite old. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 370716] Automatically overwrite closing brackets
https://bugs.kde.org/show_bug.cgi?id=370716
Diggory Hardy changed:
What|Removed |Added
CC||k...@dhardy.name
--- Comment #11 from Diggory Hardy ---
In Kate 18.12.2, I can got to an existing line like
fn main() {
then insert the cursor between the brackets and type ')'. Result: the cursor is
moved one space to the right (with or without the 'enable automatic brackets'
option).
This behaviour happens even if I just added another bracket! E.g. typing 'x:
(f32, f32)' results in:
fn main(x: (f32, f32) {
(missing closing ')' because the old one was overridden).
I'd been wondering why the compiler has complained about missing brackets so
much lately. This behaviour is horrible (personally I prefer no
autocompletion).
--
You are receiving this mail because:
You are watching all bug changes.
[Akonadi] [Bug 361610] “Server failed the authenticity check” not cancelable
https://bugs.kde.org/show_bug.cgi?id=361610 Diggory Hardy <k...@dhardy.name> changed: What|Removed |Added CC||k...@dhardy.name --- Comment #1 from Diggory Hardy <k...@dhardy.name> --- Same problem, nearly two years later! Under the details/continue/cancel box there is another saying "Login failed, TLS negotiation failed" with account settings / try again / cancel buttons, but this second box can never be accessed because the first keeps focus and is instantly replaced if cancelled. At least the new boxes don't steal focus for me, but this is still very broken. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 347949] plasma panel does not set window size hints when panel is on right screen edge
https://bugs.kde.org/show_bug.cgi?id=347949 --- Comment #5 from Diggory Hardy <k...@dhardy.name> --- I would guess so. -- You are receiving this mail because: You are watching all bug changes.
[kile] [Bug 390323] New: Tab completion broken: inserts full completion after initial characters
https://bugs.kde.org/show_bug.cgi?id=390323 Bug ID: 390323 Summary: Tab completion broken: inserts full completion after initial characters Product: kile Version: 2.1.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: editor Assignee: michel.lud...@kdemail.net Reporter: k...@dhardy.name Target Milestone: --- Kile has two styles of completion: full replacement via Enter key (replacing initial content and potentially adding newlines), and partial completion via Tab key. The latter is broken: Typing: \usep and pressing Tab results in: \usep\usepackage It should result in: \usepackage -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 193342] skip to next random album button
https://bugs.kde.org/show_bug.cgi?id=193342 Diggory Hardy <k...@dhardy.name> changed: What|Removed |Added CC||k...@dhardy.name --- Comment #10 from Diggory Hardy <k...@dhardy.name> --- Eight years on, and this is still open... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 385904] dragging a new window to edge of screen does not always tile as expected
https://bugs.kde.org/show_bug.cgi?id=385904 --- Comment #1 from Diggory Hardy <k...@dhardy.name> --- May be a duplicate of this report: https://bugs.kde.org/show_bug.cgi?id=376104 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 385904] New: dragging a new window to edge of screen does not always tile as expected
https://bugs.kde.org/show_bug.cgi?id=385904 Bug ID: 385904 Summary: dragging a new window to edge of screen does not always tile as expected Product: kwin Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: k...@dhardy.name Target Milestone: --- Open a new window and drag the window to edge of screen to tile the window to that half the screen. If the window is newly opened and happened to already be tiled to half the screen (whether this or the other half), it instead gets 'untiled' (reverting to a default size and position, not half the screen). This only ever happens on the first drag on the window, so is inconsistent and annoying behaviour; it should always tile to half the screen if dragged there IMO (and this is what happens any other time when dragged). Versions: kwin 5.9.5, Fedora 25 -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 385163] email rendering does not respect system font DPI settings
https://bugs.kde.org/show_bug.cgi?id=385163 --- Comment #1 from Diggory Hardy <k...@dhardy.name> --- Further to this — received emails are displayed with very small fonts, as are emails composed with plain text. Emails composed with "rich text" enabled — *also* display with small fonts, but this isn't because of the display scaling — the font size defaults to 6pt! (I only realised recently when a recipient complained about the small font size.) -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 385163] New: email rendering does not respect system font DPI settings
https://bugs.kde.org/show_bug.cgi?id=385163 Bug ID: 385163 Summary: email rendering does not respect system font DPI settings Product: kmail2 Version: 5.4.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: UI Assignee: kdepim-b...@kde.org Reporter: k...@dhardy.name Target Milestone: --- I'm using a high-DPI screen. In System Settings → Fonts, I set "Force fonts DPI" to a larger value (currently 192), and most application text gets increased in size. Not so with emails rendered in KMail2 (I can open the email and zoom with Ctrl+WheelUp, but it's not automatic). FYI Konqueror seems to have the same problem. So does Firefox, but it has its own workarounds (and it's not KDE software). I found two maybe-related bug reports; both about print size: https://bugs.kde.org/show_bug.cgi?id=372662 https://bugs.kde.org/show_bug.cgi?id=78264 Alternatively I guess it would be okay to scale email rendering by the screen DPI, not by the "force font DPI" setting. As a workaround, setting the env var QT_SCALE_FACTOR=2 would "work" — but it's an ugly hack which doubles the size of everything, including the useless margins and all the UI elements which have already been increased in size (through System Settings → Icons, Application Style, "force font DPI", and possibly more); i.e. to use it effectively I'd have to set it desktop-wide at startup and revert all the other tweaks, then put up with huge margins in all the UIs. Summary: automatically scale email rendering by "force font DPI" / default=96, or by screen DPI -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 380892] New: make autocompletion less annoying
https://bugs.kde.org/show_bug.cgi?id=380892 Bug ID: 380892 Summary: make autocompletion less annoying Product: kate Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: part Assignee: kwrite-bugs-n...@kde.org Reporter: k...@dhardy.name Target Milestone: --- New document Type "the", Type "them", Type "the", → autocompletes to "them" Suggestion: do not pop up the autocompletion box when the current state of the word (e.g. "the") is also a completion (or would be a completion if that were enabled for 3 letter words). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 363816] Network monitor widget unreadable when placed on panel
https://bugs.kde.org/show_bug.cgi?id=363816 Diggory Hardy <k...@dhardy.name> changed: What|Removed |Added CC||k...@dhardy.name --- Comment #7 from Diggory Hardy <k...@dhardy.name> --- Created attachment 105731 --> https://bugs.kde.org/attachment.cgi?id=105731=edit vertical, high-DPI It's even worse on a vertical task-bar. (This is a 270 DPI screen, so fonts are small already.) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 375792] New: blue "created from another program" bar not removed from hidden views when reloading a document
https://bugs.kde.org/show_bug.cgi?id=375792 Bug ID: 375792 Summary: blue "created from another program" bar not removed from hidden views when reloading a document Product: kate Version: 16.08 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: k...@dhardy.name Target Milestone: --- 1. Open multiple windows or split views in Kate 2. Open document X in both/all views [X must be saved on disk, not a new document] 3. Change to a different document in one or all views/windows without closing document X 4. Change document X's file with a different program 5. When a window or split document views X, Kate tells you it was modified with a blue bar at the top of the page. Click 'reload'. This bar disappears. 6. In a different window/view which had X open but another document visible, now switch back to X. The blue bar is still shown on this window, and clicking the 'reload' button does nothing. [To remove the blue bar, you have to close document X or close the view/window or modify the document with an external tool again.] Sounds a little complicated, but when working with multiple windows side-by-side on files managed by git I find this happens a lot. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 372331] New: scrolls to bottom of history on click after pressing 'super'
https://bugs.kde.org/show_bug.cgi?id=372331 Bug ID: 372331 Summary: scrolls to bottom of history on click after pressing 'super' Product: konsole Version: 16.08.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: k...@dhardy.name Target Milestone: --- 1. generate enough output in Konsole that scrolling is possible 2. scroll up 3. press the 'super' (Windows) key 4. click (before scrolling again) The click mysteriously causes the window to scroll to the bottom of history. This is fairly old behaviour; may be related to: https://bugs.kde.org/show_bug.cgi?id=236733 I trigger this a lot (I use Super+F1 etc. to switch desktops), and find it annoying when scrolling up the history, switching, coming back and trying to select text. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 372250] readline's history search on up/down arrow keys visually messes up the edit line
https://bugs.kde.org/show_bug.cgi?id=372250 --- Comment #6 from Diggory Hardy <k...@dhardy.name> --- It's surprising behaviour which (at least in my case) wastes a lot of time and could conceivably be solved at a higher level (even if what that means is Bash printing a warning about "PS1" not being the expected length, though IMO Bash should just deal with it). Does that not sound like a bug to you? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 372250] readline's history search on up/down arrow keys visually messes up the edit line
https://bugs.kde.org/show_bug.cgi?id=372250 Diggory Hardy <k...@dhardy.name> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Diggory Hardy <k...@dhardy.name> --- Yes, you're right. It's a bash bug really, and that's a sufficient workaround. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 372250] readline's history search on up/down arrow keys visually messes up the edit line
https://bugs.kde.org/show_bug.cgi?id=372250 --- Comment #2 from Diggory Hardy <k...@dhardy.name> --- I should point out that this happens on two different systems, both running Fedora 23. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 372250] readline's history search on up/down arrow keys visually messes up the edit line
https://bugs.kde.org/show_bug.cgi?id=372250 --- Comment #1 from Diggory Hardy <k...@dhardy.name> --- Correction: even without history-search-on-arrow-key enabled, the visual errors happen when pressing up, and even on short lines. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 372250] New: readline's history search on up/down arrow keys visually messes up the edit line
https://bugs.kde.org/show_bug.cgi?id=372250 Bug ID: 372250 Summary: readline's history search on up/down arrow keys visually messes up the edit line Product: konsole Version: 16.08.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: history Assignee: konsole-de...@kde.org Reporter: k...@dhardy.name Target Milestone: --- 1. Enable history search on up/down arrow by adding this to .inputrc: > "\e[A": history-search-backward > "\e[B": history-search-forward See here: https://wiki.archlinux.org/index.php/Bash#History_completion 2. Start a new konsole session, and enter a long command (one long enough to wrap to the next line within the konsole), and run it 3. Enter the first few characters of the previous command and press the "up" arrow. Readline should complete the command for you. This used to work correctly, but in recent versions of Konsole, the result is visually messed up. The command still works if you try running it (despite looking garbled), but editing it is tricky. There is some mismatch between what letters konsole thinks is on the edit line and what is displayed. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 369104] [Regression] Selected text is not pasted in search field when search is initiated
https://bugs.kde.org/show_bug.cgi?id=369104 Diggory Hardy <k...@dhardy.name> changed: What|Removed |Added CC||k...@dhardy.name -- You are receiving this mail because: You are watching all bug changes.
[klipper] [Bug 194820] Ability to remove formatting from clipboard content
https://bugs.kde.org/show_bug.cgi?id=194820 Diggory Hardy <k...@dhardy.name> changed: What|Removed |Added CC||k...@dhardy.name --- Comment #6 from Diggory Hardy <k...@dhardy.name> --- It appears that this "feature" (clicking an entry in Klipper to remove formatting) was lost in the Plasma 5 update. Can it please be added somehow? Or, as George says, make copy+paste remove all formatting markers by default? -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 359323] Ark should preview XML files in a text viewer, not a web browser
https://bugs.kde.org/show_bug.cgi?id=359323 --- Comment #2 from Diggory Hardy <k...@dhardy.name> --- Awesome. Great that someone took on Ark development! -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 357127] Shortcuts bound to F keys ignore state of ISO_Level3_Shift
https://bugs.kde.org/show_bug.cgi?id=357127 --- Comment #2 from Diggory Hardy <k...@dhardy.name> --- No, it seems to get the right key. If I hit AltGr+F9 it shows '7'; if I hit AltGr+F1 it shows '←' (both correct BTW, not that I use the arrows much). If I hit just F1 it warns me that that's already in use. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 357127] New: Shortcuts bound to F keys ignore state of ISO_Level3_Shift
https://bugs.kde.org/show_bug.cgi?id=357127 Bug ID: 357127 Summary: Shortcuts bound to F keys ignore state of ISO_Level3_Shift Product: frameworks-kglobalaccel Version: unspecified Platform: Fedora RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mgraess...@kde.org Reporter: k...@dhardy.name CC: kdelibs-b...@kde.org I have my keyboard set up with an extra layer; right-Alt is ISO_Level3_Shift, which gives many keys an extra layer (e.g. Alt+F9 is 7); this is because my ErgoDox does not have all the normal keys. [See https://github.com/dhardy/keyboard]. Both global and application-local shortcuts assigned to F-keys ignore the state of the level-3 shift key; that is if I bind a shortcut like "lower window" to F2, then this triggers whenever F2 **or Alt+F2** is pressed, and the application never receives the usual result of Alt+F2. Similarly with application shortcuts; e.g. Kate binds F11 to "show line numbers", and as a result Alt+F11 toggles line numbers and does not enter '9' into the text editor. Additionally, if I map a shortcut to something like Alt+F9, then in the shortcut box the character resulting from this keyboard mapping appears (7), and the shortcut does not work. Reproducible: Always Steps to Reproduce: 1. Configure XKB with a level-3 shift key and configure level 3 of some F-keys (or install my layout config to /usr/share/X11/xkb/symbols/cyborg16 then `setxkbmap cyborg16 colemak4`) 2. Open any application with a shortcut bound to an F-key (e.g. Konsole: F11 → fullscreen) 3. Press Alt+F11 (etc.) and observe that the shortcut is triggered, not the mapped action of Alt+F11 I am running Kate 15.08.3 with KDE Frameworks 5.17.0 (Fedora 23). -- You are receiving this mail because: You are watching all bug changes.
