[plasmashell] [Bug 394119] Panel should not stop auto-hiding even when a window wants attention
https://bugs.kde.org/show_bug.cgi?id=394119 --- Comment #13 from Michael Zanetti --- (In reply to lucian303 from comment #12) > So let me get this straight. The *intended* behavior is that I click on > every single window that demands attention each time it does so that > autohide works? So every Whatsapp, Slack, Signal, Keybase message that comes > in I have to switch to it to hide the panel> Every time FF or other app > starts up I need to stop what I'm doing and click through these things? The > whole point of having autohide is to remove distractions. This creates > distractions. Look at the OSX toolbar. It autohides and doesn't pop up for a > millisecond when u have notices. Same thing with Windows. You can see what > notices you have when you unhide it with the mouse. That's the whole reason > for autohiding. At the very least there should be an option to not show it > when apps demand attention. It should be up to the user not the apps to show > the panel. Sometimes apps like FF and PHPStorm demand attention for no > reason just because they're starting up. I just get the dots and the panel > is visible and I have to click on it and get distracted, and then try to > get back to work. It took me two weeks simply to understand what was > happening. At first I thought it was just random (also because the dots > indicating an app wants attention are almost invisible). No desktop > environment I have ever used does what this panel does. It's neither > intuitive nor expected. This UX is beyond bizarre and frankly, unusable. Now, I agree with pretty much you are saying here. I'd still like to remind you that we're all supposed to be friends here and be nice to each other :). I also understand that's hard at times, because, I also agree this bug can be so annoying that it makes one angry when it's interrupting a focus demanding workflow. @triffid.hunger, after reading the review comments from David on your patch, I understand your patch will prevent all plasmoids from popping up, not just the panel. I can understand that this is not a solution that will be accepted upstream. Do you think you could try and fix this in a way that could be accepted upstream? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 394119] Panel should not stop auto-hiding even when a window wants attention
https://bugs.kde.org/show_bug.cgi?id=394119 Michael Zanetti changed: What|Removed |Added CC||mzane...@kde.org --- Comment #7 from Michael Zanetti --- Happens here too. In my case it's not a single application that can be blamed. It's rather regular things that cause the panel to pop in (regular notifications which I do want to see). The issue is more that just because a notification comes in, it doesn't imply that I want to immediately act on it. The panel popping in then covers part of the application I'm working with and I need to switch app and back just to mark that event as "seen" and continue my work. IMHO the panel should always auto-hide again, there is no reason why anything should prevent it from hiding again except the mouse hovering it. Actually I even think the panel should never auto-show unless I push the mouse to the border (or invoke it explicitly with the keyboard). Such highlights would be better implemented by adding a glow to the edge or something. It happens too often that I want to click something and just that moment the panel pops in and I click on the panel instead... Atm I even disabled panel autohiding completely and just shrunk it to a size which wouldn't take away too much screen space to work around this issue. -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 386350] Focus jumps between splits on open/close
https://bugs.kde.org/show_bug.cgi?id=386350 --- Comment #6 from Michael Zanetti <mzane...@kde.org> --- (In reply to Luis from comment #5) > I can confirm that this happens on Kubuntu 17.04 (yakuake 3.0.4) and that > disabling compositor animations on yakuake is a workaround to this. Could you please share how to disable animations just for yakuake? This issue is driving me nuts but disabling animations for the whole desktop isn't an option either. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 386350] New: Focus jumps between splits on open/close
https://bugs.kde.org/show_bug.cgi?id=386350 Bug ID: 386350 Summary: Focus jumps between splits on open/close Product: yakuake Version: 3.0.4 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: h...@kde.org Reporter: mzane...@kde.org Target Milestone: --- Steps to reproduce: * Open yakuake with a split for 2 (or more) sessions * input focus is in one of them * hide yakuake * show yakuake again => expected outcome: focus should still be in the same split as before => actual outcome: focus has moved to the next split This hasn't happened with earlier versions of yakuake, but I don't know which version introduced it as I have been using the KDE-4 version of yakuake until recently. It was working fine there and in version before. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384805] cursor jumps upon edge activation
https://bugs.kde.org/show_bug.cgi?id=384805 --- Comment #4 from Michael Zanetti <mzane...@kde.org> --- Hey, so, I've edited screenedge.cpp and commented out the pushback of the cursor, and indeed the issue is gone (obviously at the cost that the one pixel pushback doesn't work any more either). I also tried to add debug prints for the cursor position when it hits the edge and those seem to be correct. Which leads me to believe that the issue must be somewhere on the path of of Cursor::setPos(). Not saying it's necessarily in kwin itself, but at least it seems to happen when writing the position, and not when reading it. I tried to follow the path but I got lost. All the connections to Cursor::posChanged don't seem to actually set the cursor (except in the software cursor case which doesn't seem to be case here, at least I couldn't see the m_softwareCursor path in platform.cpp being triggered) and the drm/x11standalone backends don't actually seem to trigger any cursor position updates, but rather only use that information for the edge glow and such. Hope this helps, not sure where to go from here atm. Br, Michael -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384805] cursor jumps upon edge activation
https://bugs.kde.org/show_bug.cgi?id=384805 --- Comment #2 from Michael Zanetti <mzane...@kde.org> --- Hi Martin, I'm not 100% sure either if it's really kwin... Maybe it's the panel? But perhaps it's something in that 1 pixel push back that break it? like, if it does setCursorPosition(x, y) trying to correct one of them by 1 (depending on the edge) but there's some issue in the calculation of the new x/y values? I'm just guessing here... For all I know is that it only happens on edges where that have an autohide panel and if libinput's properties are set to translate the cursor matrix. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384805] New: cursor jumps upon edge activation
https://bugs.kde.org/show_bug.cgi?id=384805 Bug ID: 384805 Summary: cursor jumps upon edge activation Product: kwin Version: 5.10.5 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: libinput Assignee: kwin-bugs-n...@kde.org Reporter: mzane...@kde.org Target Milestone: --- So I'm using libinput as touchpad driver on a new MacBook Pro and because the touchpad is so huge with high resolution, the cursor moves really slow and systemsetting's mouse module doesn't support changing the cursor speed for libinput. So I'm using this to double the mouse cursor speed: xinput set-prop 12 142 2.00, 0.00, 0.00, 0.00, 2.00, 0.00, 0.00, 0.00, 1.00 That works fine, except for this bug: when revealing an autohiding panel with the mouse, the cursor jumps for half a screen width/height along the edge (depending whether the panel is on the side or bottom). As example, revealing an autohiding panel on the left screen edge by hitting the center of the left edge, as soon as the panel appears, the cursor jumps to the lower left corner of the screen. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384341] In X11, Small/Large Icon window switchers have hardcoded sizes and are super tiny on high-dpi screens
https://bugs.kde.org/show_bug.cgi?id=384341 --- Comment #13 from Michael Zanetti <mzane...@kde.org> --- What I mean is that right now the Small Icons one is unusable on a high-dpi screen. By increasing the size of both (for high-dpi setups) the small one would be the same as the current big one with mostly sharp icons, while the big one will have some pixelated icons, but for those who want it, allow faster navigation through many windows because the larger size makes it just easier. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384341] In X11, Small/Large Icon window switchers have hardcoded sizes and are super tiny on high-dpi screens
https://bugs.kde.org/show_bug.cgi?id=384341 --- Comment #12 from Michael Zanetti <mzane...@kde.org> --- (In reply to Martin Flöser from comment #11) > > So I don't think we lose anything by increasing the size of the icon > > switchers on hidpi displays. > > That depends on whom you ask. We have many users who think that's not > acceptable and it's better to have smaller icons then. Both are valid > approaches. It's just something we must keep in mind. Fixing this issue > creates (or exposes) new issues. Couldn't those users simply select the "Small Icons" switcher? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384355] Hinting glow wrongly sized on autohide panels
https://bugs.kde.org/show_bug.cgi?id=384355 --- Comment #2 from Michael Zanetti <mzane...@kde.org> --- Could be related to the fact that this is a high dpi screen and I have set the scale factor to 2x -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384355] Hinting glow wrongly sized on autohide panels
https://bugs.kde.org/show_bug.cgi?id=384355 --- Comment #1 from Michael Zanetti <mzane...@kde.org> --- Created attachment 107689 --> https://bugs.kde.org/attachment.cgi?id=107689=edit actual panel size -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 384355] New: Hinting glow wrongly sized on autohide panels
https://bugs.kde.org/show_bug.cgi?id=384355 Bug ID: 384355 Summary: Hinting glow wrongly sized on autohide panels Product: plasmashell Version: 5.10.5 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: mzane...@kde.org Target Milestone: 1.0 Created attachment 107688 --> https://bugs.kde.org/attachment.cgi?id=107688=edit hinting glow The hinting glow is wrongly sized on autohide panels. see attached screenshots -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384341] In X11, Small/Large Icon window switchers have hardcoded sizes and are super tiny on high-dpi screens
https://bugs.kde.org/show_bug.cgi?id=384341 --- Comment #7 from Michael Zanetti <mzane...@kde.org> --- Created attachment 107687 --> https://bugs.kde.org/attachment.cgi?id=107687=edit manually patched big_icons tabbox with iconSize: 256 Attached a screenshot for the manually patched file... I for one think it's better to have a blurry firefox icon but have all the Qt/KDE provided icons big and shiny :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384341] In X11, Small/Large Icon window switchers have hardcoded sizes and are super tiny on high-dpi screens
https://bugs.kde.org/show_bug.cgi?id=384341 --- Comment #5 from Michael Zanetti <mzane...@kde.org> --- to be precise, all the icons I have seen so far perfectly provide larger sizes, with the only exception I noticed so far being firefox. That one becomes quite blurry indeed. But at least for the small icons one I guess it should be easily fixable without suffering from that problem. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384341] In X11, Small/Large Icon window switchers have hardcoded sizes and are super tiny on high-dpi screens
https://bugs.kde.org/show_bug.cgi?id=384341 --- Comment #3 from Michael Zanetti <mzane...@kde.org> --- I've manuall edited /usr/share/kwin/tabbox/big_icons/contents/ui/main.qml and doubled the iconSize value... muuch better already... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384341] New: Small/Large Icons have hardcoded sizes and are super tiny on high-dpi screens
https://bugs.kde.org/show_bug.cgi?id=384341 Bug ID: 384341 Summary: Small/Large Icons have hardcoded sizes and are super tiny on high-dpi screens Product: kwin Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: effects-tabbox Assignee: kwin-bugs-n...@kde.org Reporter: mzane...@kde.org Target Milestone: --- Created attachment 107680 --> https://bugs.kde.org/attachment.cgi?id=107680=edit Screenshot of the "Small Icons" TabBox on a high dpi screen Using the Small/Large Icons TabBox on a high dpi screen renders them too small. The Large Icons pretty much looks like the small icons should look like, while the small icons one is so tiny that it's virtually impossible to actually recognize the icons. See the attached screenshot. -- You are receiving this mail because: You are watching all bug changes.
[kopete] [Bug 362535] Kopete 1.9.0 somtimes won't encrypt even though the GUI says otherwise
https://bugs.kde.org/show_bug.cgi?id=362535 --- Comment #3 from Michael Zanetti <mzane...@kde.org> --- (In reply to Pali Rohár from comment #2) > Michael, can you look at this bug? I'm sorry... I'm not really using Kopete (or any of KDE) any more... I'm afraid you're on your own with this. -- You are receiving this mail because: You are watching all bug changes.
