[plasmashell] [Bug 456408] New: [ Request ] Task manager arranges
https://bugs.kde.org/show_bug.cgi?id=456408 Bug ID: 456408 Summary: [ Request ] Task manager arranges Product: plasmashell Version: 5.25.1 Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: plasma-b...@kde.org Reporter: shattered_min...@yahoo.com Target Milestone: 1.0 SUMMARY This isn't a bug, it's a request. I was told I should bring this idea here but I don't see any way to submit requests. So hopefully this is fine. I apologize if it's not. Anyways, my idea is there should be an option to make the task manager automatically move its entries based on where on the screen the window is on. For example, if you have Dolphin on the left and Firefox on the right, then the task manger will also have the entry for Dolphin on the left and Firefox on the right. And if you swap the two window positions, the task manager entries will also swap. I think that would be a good way to help the user mentally organize things on the screen. That's the idea. Thank you for your time. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456408] [ Request ] Task manager arranges entries by where they're placed on the screen.
https://bugs.kde.org/show_bug.cgi?id=456408 mouse changed: What|Removed |Added Summary|[ Request ] Task manager|[ Request ] Task manager |arranges|arranges entries by where ||they're placed on the ||screen. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456408] [ Request ] Task manager arranges entries by where they're placed on the screen?
https://bugs.kde.org/show_bug.cgi?id=456408 mouse changed: What|Removed |Added Summary|[ Request ] Task manager|[ Request ] Task manager |arranges entries by where |arranges entries by where |they're placed on the |they're placed on the |screen. |screen? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456408] [ Request ] Task manager arranges entries by where they're placed on the screen?
https://bugs.kde.org/show_bug.cgi?id=456408 mouse changed: What|Removed |Added Resolution|INTENTIONAL |--- Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #2 from mouse --- (In reply to Nate Graham from comment #1) > It's an interesting idea but I think it would violate the conceptual model > of how a Task Manager works. If you want to pick windows spatially (i.e. > based on position on screen) we have a bunch of ways you do can do that. the > Overview, Present Windows, and Desktop Grid effects implement that paradigm. > I don't think it would make sense to bring it to the Task Manager too. But > thanks for the idea anyway! Thank you for your response. I hate to disagree and I don't want to offend but I've seen those desktop effects and, while they're neat, they're also cumbersome, slow, and hard to work into my usual workflow. Especially since they can't be active at all times or be bound to the mouse wheel (without the use of an external program). They also don't address the concern I was trying to express earlier. I'll try to reframe my request by presenting an admittedly specific use case; borderless window tiling: https://i.imgur.com/8Z6jFkK.png Since the tiling kwin script handles window size and placement automatically (mostly), there's even less need for a border than before. The title bar still holds some value though, such as the ability to single click close a program with only the mouse, or being able to access a window's alt+space menu also with only the mouse. It's important to note the title bar is useful ONLY because of the task manager's shortcomings. It's value is solely being able to quickly access a few basic window management functions with a single click, such as minimizing, closing, shading, etc. With the task manager also being able to handle some of these functions (all if you count the right click menu), you end up with two redundant on-screen entities doing the same job. It makes sense to combine these two fragmented entities into one cohesive unit. This single cohesive unit would most naturally order the window entries in the task manager by their location on the screen. I see nothing that suggests this isn't the most logical evolution of the modern desktop environment. I was reluctant to present this scenario before because I knew it only make it easier to brush off the request, but since I already have, I would also like to request that the window's title bar buttons be placed in the task manager. There's no single mouse click way to maximize or pin a window via the task manager. Mirroring the title bar buttons to the window's entry in the task manager would immediately rectify this problem. tl;dr: The unnecessary redundancies of the title bar can finally be resolved, and all it would require is adding the ability to mirror title bar buttons in the task manager and automatically organize task bar entries by window placement. This would maximize desk space without compromising ease of use. I hope this frames my request better than before. Thank you for your time, again. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456408] [ Request ] Task manager arranges entries by where they're placed on the screen?
https://bugs.kde.org/show_bug.cgi?id=456408 mouse changed: What|Removed |Added Resolution|INTENTIONAL |--- Status|RESOLVED|REOPENED --- Comment #4 from mouse --- (In reply to Nate Graham from comment #3) > That's quite an exotic use case! :) > > The bad news is that I'm pretty sure we can't support it in the Task Manager > as it's quite out of scope. > > The good news is that I think you can get something even better: > - Remove the Task Manager from your panel > - Add an Active Window Control widget to your panel, which will give you > window control buttons for the active window > - Add a Window List widget to your panel if access to individual windows via > a secondary GUI is still needed > > Plasma is quite flexible for use cases like this so hopefully you can find > something that works for you using the tools it already has This is kind of what I'm talking about: -Task Manager -Icons-only Task Manager -Active Window Control -Window List -Title Bars There are so many entities that are all individually doing almost the full job but not quite. Each one needs at least one of the other to provide full functionality/ease of use. There is a lot of redundancy here and it wastes screen space and development time/resources to maintain each individual widget. That said, I really like Active Window Control. I had no idea it existed and it's so close to being exactly what I want. But I've noticed several issues: -The pin button doesn't actually pin/unpin a window to all desktops. This most certainly seems to be a bug. (I'm on KDE Plasma Version 5.25.2) -There's no mute/unmute button for windows that play audio. -I personally would love if it extended itself to inactive windows as well. I'm sure this goes against its mantra or prime directive or whatever, but that one aspect is the biggest blockade preventing it from making all of the other entities obsolete. Window List is a drop down menu, which is even more clicks to access the same basic functionality the others provide. Icons-only Task Manager is pretty nice but it seems like it should be a toggle setting in Task Manager's configuration menu. One problem though is the mute/unmute button is so small. I wasn't even sure if it was actually there. I have to scale the icon spacing to the largest for the mute/unmute button to scale up to a practical size. But increasing the spacing like this also undermines what I am assuming is its purpose; to conserve space. The combination of Active Window Control and Icons-only Task Manager isn't a bad combo but I still have to switch focus to have access to the same shortcuts in the title bar and that's more extra steps. The less clicks, the better. Anyways, I'm glad you like the screenshot and I'm sorry I keep eating up your time. I believe window tiling is the future and this whole title bar/task manager fuss is one of the awkward growing pains sure to arise along the way to that future. I just wish I wasn't the one making the fuss. >.> -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456408] [ Request ] Task manager arranges entries by where they're placed on the screen?
https://bugs.kde.org/show_bug.cgi?id=456408 --- Comment #6 from mouse --- (In reply to Nate Graham from comment #5) > Yeah, play around with the tools that are already there. Maybe some of them > can be tweaked. But again, I don't think we can change the Task Manager to > implement the requested feature, sorry. :) Check it out. I programmed it in myself after I got your reply. https://i.imgur.com/pvzsE5n.png The buttons need some size and placement tweaking, and I haven't figured out how to apply the proper icons, but they're all fully functional. I even fixed the bug in the Active Window Control plasmoid. Not bad for being only a couple of hours into my first plasmoid ever, right? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456408] [ Request ] Task manager arranges entries by where they're placed on the screen?
https://bugs.kde.org/show_bug.cgi?id=456408 --- Comment #8 from mouse --- (In reply to Nate Graham from comment #7) > Nice! Feel free to submit it at https://store.kde.org/browse?cat=418 Sorry for the lateness of this reply. I've been sick. Anyways, I wouldn't feel right doing that. 95% of the code isn't mine. I simply added some useful functionality on top of what already exists. Speaking of extra functionality, I also gave scrolling up and down a third option; stepping through virtual desktops, not unlike what the pager does. This makes having a pager redundant and more precious screen space is freed up. I never knew how much I wanted this feature until I realized I could add it. Btw, I can't find the code for sorting. Can you help with that? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456408] [ Request ] Task manager arranges entries by where they're placed on the screen?
https://bugs.kde.org/show_bug.cgi?id=456408 --- Comment #10 from mouse --- (In reply to Nate Graham from comment #9) > Lots of widgets on store.kde.org are forks of official ones with some extra > bits. That's no problem. > > I can't help you with development activity here, sorry. I think that could be why so many of them are buggy or broken. It makes sense that a lot them are abandoned since it would be very tedious to apply bug fixes and updates for the widgets they're built on as they roll out. Whereas implementing the features into these various widgets would be much less redundant and easier to maintain. Especially in this case, because these few feature additions make several widgets unnecessary. So maintaining those widgets would also be unnecessary. And where do you provide help with developmental activity? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456408] [ Request ] Task manager arranges entries by where they're placed on the screen?
https://bugs.kde.org/show_bug.cgi?id=456408 --- Comment #12 from mouse --- (In reply to Nate Graham from comment #11) > > Whereas implementing the features into these various widgets would be much > > less redundant and easier to maintain. > Ah, but maintained by who? Once you've contributed code upstream to > implement a particular specific niche feature, it's easy to wander away and > leave the burden to someone else, which is in practice what we tend to see. > That's why we encourage people who are willing to take on the maintenance > burden to fork the widget, add their feature, put it on store.kde.org, and > maintain it. It's true that this maintenance burden isn't trivial. But > that's the nature of maintaining niche features. There's no free lunch. > > You can ask for development assistance in the #kde-devel room on Matrix; see > https://community.kde.org/Get_Involved/development#Communicate_with_the_team You realize you're talking about the burden of an extra developmental workload, while you simultaneously still have at least 5 redundant widgets on this topic alone, right? Two of them are just a copy paste of the same widget, but with an icons-only setting hard enabled. And the pager is made nearly completely pointless just by allowing the user to step through virtual desktops via mousing up and down on the task manager. So that's another widget who's usefulness is negated. But I agree with your sentiment. Neither one of us wants the burden of trying to maintain usability for every possible layout with this, or any, widget. However, one of us gets paid to do it and is asking the other to do it for free (and in the downstream no less). So you can see how your 'no free lunches' sentiment may not be the best argument to make here, right? You're saying 'no free lunches', while also telling me to keep spreading peanut butter onto a thousand different slices of bread. 'No free lunches' means we might as well wave goodbye to store.kde.org. And KDE and even Linux for that matter. Thank you for the link btw. I'll be sure to pick their brains with a bunch of stupid questions later. :P -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 460412] New: Blur effect conflict with scale effect when draw rounded rect with blur behind.
https://bugs.kde.org/show_bug.cgi?id=460412 Bug ID: 460412 Summary: Blur effect conflict with scale effect when draw rounded rect with blur behind. Classification: Plasma Product: kwin Version: unspecified Platform: unspecified OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: sendbypyt...@foxmail.com Target Milestone: --- Created attachment 152798 --> https://bugs.kde.org/attachment.cgi?id=152798&action=edit abnormal blur SUMMARY When I develop my application(which has rounded window), I found some problem (lots of blur horizontal striation) when the app open/close. STEPS TO REPRODUCE 1. Run or stop the app. 2. Watch it. OBSERVED RESULT I have added an attachment. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.18 and 5.26 (only tested on these version) (available in About System) KDE Plasma Version: 5.26 KDE Frameworks Version: 5.98 Qt Version: 5.15.5 ADDITIONAL INFORMATION I tried to modify blur effect's shader, make all fragColor = vec4(0, 1, 0, 1), the horizontal striation not disappear, just turn to green striation. Then I tried to changed scale effect, found that only scale property influence the result. If someone can provide ideas, I'd like to try~ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 460412] Blur effect conflict with scale effect when draw rounded rect with blur behind.
https://bugs.kde.org/show_bug.cgi?id=460412 Mouse Zhang changed: What|Removed |Added CC||sendbypyt...@foxmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 460412] Blur effect conflict with scale effect when draw rounded rect with blur behind.
https://bugs.kde.org/show_bug.cgi?id=460412 --- Comment #1 from Mouse Zhang --- I have an idea: when QRegion represents a circle, it will divide the circle into small rectangles, some with a height of 1, others with a height of 2 or more, and rectangles with a height of 1 will disappear after scaling, while others will remain to form stripes. I don't know if my guess is correct. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 381183] latest libzip4 package breaks applications
https://bugs.kde.org/show_bug.cgi?id=381183 Keen Mouse changed: What|Removed |Added CC||jgrusend...@keenmouse.com --- Comment #4 from Keen Mouse --- I have the same problem. $ php -v PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/zip.so' - libzip.so.4: cannot open shared object file: No such file or directory in Unknown on line 0 PHP 7.0.18-0ubuntu0.16.04.1 (cli) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.0.18-0ubuntu0.16.04.1, Copyright (c) 1999-2017, by Zend Technologies $ ldd -v /usr/lib/php/20151012/zip.so linux-vdso.so.1 => (0x7fff225db000) libzip.so.4 => not found $ locate libzip.so.5 /usr/lib/x86_64-linux-gnu/libzip.so.5 /usr/lib/x86_64-linux-gnu/libzip.so.5.0.0 $ dpkg -S /usr/lib/x86_64-linux-gnu/libzip.so.5 libzip4:amd64: /usr/lib/x86_64-linux-gnu/libzip.so.5 $ apt policy libzip4 libzip4: Installed: 1.2.0-0neon+16.04+xenial+build2 Candidate: 1.2.0-0neon+16.04+xenial+build2 Version table: *** 1.2.0-0neon+16.04+xenial+build2 500 500 http://archive.neon.kde.org/user/lts xenial/main amd64 Packages 100 /var/lib/dpkg/status 1.0.1-0ubuntu1 500 500 http://ca.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages -- You are receiving this mail because: You are watching all bug changes.
