[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #11 from leftcrane --- "Capture the inactive and active window chrome" Capture the color of the chrome, i mean. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #10 from leftcrane --- a) Having KWin do all the work would of course be ideal (the user would still be able to override just like they do now with rules). Capture the inactive and active window chrome at every launch, or capture once at first launch? I can see a problem with the second scenario, since themes and dark/light modes change. Maybe also have an API so the app can directly tell KWin what colors to use? (Of course most will never use it, sadly, but some might.) b) Having the user define the color is less than ideal, but if we have the user defining the color, they should only have to define one value (unless they want to define more, for whatever reason). Both options are an improvement on the current way of doing things, your call. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #8 from leftcrane --- The point is inherit some values regarding contrast from the main theme. That way the user can define as few colors as possible (usually they just need to define one color). - contrast between the active titlebar background, the active titlebar text, the inactive and the inactive titlebar text. - contrast between the titlebar background+text and the window menu background+text. (if you think it's a good idea to color the window options menus based on the titlebar color, your call) So you just define set the active titlebar color to match the window chrome and all the other values are inferred, unless you want to override them. Regarding separation, I guess you're right. These will technically still be defined as regular KDE color schemes on disk. But they shouldn't clutter up the color shemes KCM module, cause they are play a different role for the user. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #15 from leftcrane --- Oh these apps don't follow any system color scheme (different toolkit, or it's a text editor or terminal). And there is mismatch built into some gtk and kvantum themes, that shows up under certain circumstances, though that's another issue. It all looks pretty bad it's just too much work to fix it using the current method. I think it'd be worth it, as frivolous as it sounds. One of the upsides of Gnome CSD is that the the chrome and decoration are in sync with each other. Looks much more professional and offers some possibilities to developers. Such a thing could be done for SSD too, and it might become even more relevant for KWin if DWD ever materializes. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #13 from leftcrane --- Yeah, I see the problem with video players, for example. But these would be these exception. Currently, I have non-matching titlebar/chrome for about 10 apps on my system. To get them to match, I'd have to perform 260 actions with keyboard and mouse using three separate dialogs. With the proposed manual method, it'd be max 50 actions using one dialog (one could optimize it down to 20). So I'd say the proposed manual method would make matching at least doable for the user. But if no then no. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #16 from leftcrane --- Oh yeah, I forgot all the dark theme apps. So it's actually way more than ten apps (I have a rule for those though). -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 402306] New: PackageKit crashes every time while fetching updates for Discover
https://bugs.kde.org/show_bug.cgi?id=402306 Bug ID: 402306 Summary: PackageKit crashes every time while fetching updates for Discover Product: Discover Version: unspecified Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: discover Assignee: aleix...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- This is all I could find in the logs (I didn't kill it): 12/18/18 5:07 PMpackagekitd terminate called after throwing an instance of 'std::length_error' 12/18/18 5:07 PMpackagekitd what(): basic_string::_M_replace 12/18/18 5:07 PMsystemd packagekit.service: Main process exited, code=killed, status=6/ABRT 12/18/18 5:07 PMsystemd packagekit.service: Failed with result 'signal'. system info: Operating System: Kubuntu 18.10 KDE Plasma Version: 5.14.4 Qt Version: 5.11.1 KDE Frameworks Version: 5.52.0 Kernel Version: 4.18.0-12-generic OS Type: 64-bit To reproduce, click the update plasmoid or click update inside Discover. Gnome Software just fails to retrieve the updates (there are 24 updated shown with pkcon update, Gnome Software shows zero). This update bug (packagekit GUIs either not showing updates or crashing at update request) has existed for years on both rpm and deb distros, so not sure if KDE can do anything about it. Might be software sources causing a problem. It only sort of works on Fedora 29 in my experience. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 402306] PackageKit crashes every time while fetching updates for Discover
https://bugs.kde.org/show_bug.cgi?id=402306 leftcrane changed: What|Removed |Added Version|unspecified |5.14.4 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 402306] PackageKit crashes every time while fetching updates for Discover
https://bugs.kde.org/show_bug.cgi?id=402306 --- Comment #3 from leftcrane --- Turned out that it was just this one repository. However, Discover was giving me error messages with at least four apt lines. Unfortunately, I couldn't read or save those messages cause they appeared for only two seconds. -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 402030] New: Cycle tabs in most according to last used order in chromium (like alt tab for kwin)
https://bugs.kde.org/show_bug.cgi?id=402030 Bug ID: 402030 Summary: Cycle tabs in most according to last used order in chromium (like alt tab for kwin) Product: plasma-browser-integration Version: unspecified Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Chrome Assignee: k...@privat.broulik.de Reporter: leftcr...@tutanota.com Target Milestone: --- Flags: Brainstorm+, Usability+ See this extension for reference: https://chrome.google.com/webstore/detail/ctrl%20tab-mru/ialfjajikhdldpgcfglgndennidgkhik I am not sure how cleanly this can be implemented on Chrome, but it would really be nice to have this. -- You are receiving this mail because: You are watching all bug changes.
[kde-cli-tools] [Bug 402034] New: Provide an easy way to restart KWin and Plasma shell to the user (from virtual console)
https://bugs.kde.org/show_bug.cgi?id=402034 Bug ID: 402034 Summary: Provide an easy way to restart KWin and Plasma shell to the user (from virtual console) Product: kde-cli-tools Version: 5.14.4 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: aleix...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Flags: Usability+ there are several different solutions being suggested online and I haven't found a single one that allows me to restart both precesses successfully (compositing gets disabled, complains about no display not being found, plasma gets terminated but wont restart, or plasma gets terminated but the applets start to work in really weird ways) I find myself frequently needing to use this feature due to desktop freezing, either because of third-party software, ram consumption or KDE bugs (hard to figure out). I don't want to log out or reboot cause then I lose all my work. Due to it's single-threaded design, Gnome (on X) has a one liner: --replace KDE needs some kind of script but I can't figure out what that script should be. I suspect many users are in the same position (as evidenced by the popularity of this question and the variety of answers). It is also unclear whether the solution for X and Wayland would be different. People need a simple, reliable way too unbork the shell and WM in case of emergency. It's a wishlist, but I'd like it have a high priority. -- You are receiving this mail because: You are watching all bug changes.
[kde-cli-tools] [Bug 402034] Provide an easy way to restart KWin and Plasma shell to the user (from virtual console)
https://bugs.kde.org/show_bug.cgi?id=402034 --- Comment #1 from leftcrane --- example: https://www.reddit.com/r/kde/comments/a5d2ly/how_do_you_properly_restart_kwin_and_plasmashell/ -- You are receiving this mail because: You are watching all bug changes.
[kde-cli-tools] [Bug 402034] Provide an easy way to restart KWin and Plasma shell to the user (from virtual console)
https://bugs.kde.org/show_bug.cgi?id=402034 leftcrane changed: What|Removed |Added Flags|Usability+ |Usability- -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401991] New: Option to make status overlays non-clickable, or hide them all together (interferes with the primary function of the dock)
https://bugs.kde.org/show_bug.cgi?id=401991 Bug ID: 401991 Summary: Option to make status overlays non-clickable, or hide them all together (interferes with the primary function of the dock) Product: latte-dock Version: git (master) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: plasmoid Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- Flags: Usability+ Created attachment 116853 --> https://bugs.kde.org/attachment.cgi?id=116853=edit chrome with clickable mute overlay. I keep clicking on the mute/sound status overlays in the icons when I am trying to select a window from the dock. Most of these clickable overlays are pretty useless (does one really need to toggle volume from the dock for each specific app? The dock isn't an audio mixer). I think default behavior should be to hide these overlays or make them non-clickable. Or at least make this an option. Let me know if this should be filed upstream instead. Ma -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 401998] Download notification showing up twice
https://bugs.kde.org/show_bug.cgi?id=401998 --- Comment #2 from leftcrane --- I had one notification widget on my desktop and one in the system tray. So they were both sending the same notification. Feel free to close this. -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 401998] Download notification showing up twice
https://bugs.kde.org/show_bug.cgi?id=401998 --- Comment #3 from leftcrane --- However I wasn't getting duplicates for other types of notifications, for whatever reason. -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 401998] New: Download notification showing up twice
https://bugs.kde.org/show_bug.cgi?id=401998 Bug ID: 401998 Summary: Download notification showing up twice Product: plasma-browser-integration Version: unspecified Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Chrome Assignee: k...@privat.broulik.de Reporter: leftcr...@tutanota.com Target Milestone: --- Created attachment 116856 --> https://bugs.kde.org/attachment.cgi?id=116856=edit duplicate notifications SUMMARY STEPS TO REPRODUCE 1. Enable " Show downloads in notification area" 2. Download a file. OBSERVED RESULT The notification is duplicated for every file. EXPECTED RESULT One notification Operating System: Kubuntu 18.10 KDE Plasma Version: 5.14.4 Qt Version: 5.11.1 KDE Frameworks Version: 5.52.0 Kernel Version: 4.18.0-12-generic OS Type: 64-bit Chromium: Version 70.0.3538.110 (Official Build) Built on Ubuntu , running on Ubuntu 18.10 (64-bit) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #18 from leftcrane --- you mean DWD? stuff like titlebar coloring doesn't require toolkit support or DWD. it just seemed like it would be relevant to the overall goal of closer integration between the ssd and apps, which seems worthwhile imo. re: discussion of DWD/DWD-like features I sent you a quick message on reddit. -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 402209] New: Blank menus on Sublime Text (similar behavior as with LibreOffice
https://bugs.kde.org/show_bug.cgi?id=402209 Bug ID: 402209 Summary: Blank menus on Sublime Text (similar behavior as with LibreOffice Product: kded-appmenu Version: 5.14.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: export Assignee: plasma-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Created attachment 116952 --> https://bugs.kde.org/attachment.cgi?id=116952=edit blank menu illustration A few of the menu items and submenus aren't loaded. After switching to another window, then switching back, the menus get loaded. See attached video. Affects both menu plasmoid and locally integrated menu. Same exact problem observed with Open Office. The File menu doesn't get loaded, then when you hit alt+tab twice, it magically appears. A bug has already been filed for Open Office here #401367. It seems like some optimization could be done by KDE here. It seems like it stops loading the menus too soon. If the app is slow to export the menus, they don't get loaded until you switch focus. Sublime Text 3.1.1 Build 3176 Operating System: Kubuntu 18.10 KDE Plasma Version: 5.14.4 Qt Version: 5.11.1 KDE Frameworks Version: 5.52.0 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 402306] PackageKit crashes every time while fetching updates for Discover
https://bugs.kde.org/show_bug.cgi?id=402306 --- Comment #11 from leftcrane --- https://github.com/hughsie/PackageKit/issues/302 PPA's and COPR are supported, but if they misbehave in any way PK updates will stop working entirely. So they are poorly supported and users should be given fair warning. I wasted many hours trying to diagnose this. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 402306] PackageKit crashes every time while fetching updates for Discover
https://bugs.kde.org/show_bug.cgi?id=402306 --- Comment #8 from leftcrane --- Output of "pkcon refresh force" Refreshing cache [=] Loading cache [=] Refreshing software list [=] Downloading packages [=] Running [=] Loading cache [ ] (0%) The daemon crashed mid-transaction! -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 402306] PackageKit crashes every time while fetching updates for Discover
https://bugs.kde.org/show_bug.cgi?id=402306 --- Comment #9 from leftcrane --- OK, turned out this was because the cosmic release was removed from the ppa I was using. (https://launchpad.net/~mdeguzis/+archive/ubuntu/libregeek) If _any_ repository is down, packagekit can't refresh the cache. With COPR repos, if any repository lacks appdata, packagekit will cease to perform updates. Basically, if there is any problem with any repository, you will no longer be able to update your system. It's been like this for years. Should a bug be filed upstream? At the very least, packagekit should have a disclaimer that says "you cannot use unofficial repositories and packagekit on the same system". -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 402306] PackageKit crashes every time while fetching updates for Discover
https://bugs.kde.org/show_bug.cgi?id=402306
--- Comment #6 from leftcrane ---
It's not actually that particular line. Something must have jolted it back into
working order after the apt-update, but now packagekit is back on its bullshit.
I wish I could help more, but this is all I see in the terminal:
org.kde.plasma.discover: Trying to open unexisting file
QUrl("file:///home/USER/%25F")
invalid kns backend! "/etc/xdg/ksysguard.knsrc" because: "Config group not
found! Check your KNS3 installation."
invalid kns backend! "/etc/xdg/servicemenu.knsrc" because: "Config group not
found! Check your KNS3 installation."
adding empty sources model QStandardItemModel(0x563231df9fd0)
no packages for "ardour5.desktop"
no packages for "cockpit.desktop"
no packages for "com.teamviewer.TeamViewer"
no packages for "im.riot.webapp"
could not find "org.kde.development" ""
could not find "org.kde.development" ""
could not find "org.kde.development" ""
Transaction error: "The PackageKit daemon has crashed"
PackageKit::Transaction(0x563236c1bd70)
qml: message: The PackageKit daemon has crashed
no packages for "ardour5.desktop"
no packages for "cockpit.desktop"
no packages for "com.teamviewer.TeamViewer"
no packages for "im.riot.webapp"
PackageKit stopped running!
could not find "org.kde.development" ""
Gnome Software won't list updates either. But the updates are there and
packagekit displays them fine from the terminal. This is some kind of
longstanding bug that affects both Gnome Software and Discover.
--
You are receiving this mail because:
You are watching all bug changes.
[Discover] [Bug 402306] PackageKit crashes every time while fetching updates for Discover
https://bugs.kde.org/show_bug.cgi?id=402306 --- Comment #7 from leftcrane --- Created attachment 117068 --> https://bugs.kde.org/attachment.cgi?id=117068=edit Gnome software example error (one of many) I've just loaded an example from Gnome Software. It says "failed to install", though I didn't ask it to install anything. Discover just reads "PackageKit crashed" every time. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 leftcrane changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #5 from leftcrane --- info has been provided. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #6 from leftcrane --- TL;DR. The user should be able to change the titlebar color (to match window chrome or for other reasons) without having to create a whole new color scheme. Most of the time, all you really need is just the active window color. The inactive titlbar color, text color could be inferred from colors and contrast values of the active color scheme. Just pick one color and you're done. If the user wants they can provide these other values they can, but most of the time it's not necessary for what the user is trying to do. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #3 from leftcrane --- I personally would prefer the titlebar to look different from the chrome, but with the same base color. Sort of like Adwaita does it. There is trend to have matching colors: android, Gnome, Mac, Windows, they all do it. But yeah the most common use for Kwin color theme rules is to make the bar color match the window chrome for applications that don't follow KDE themes well or at all. With global menu it gets worse, cause the menubar - part that usually follows some system color - gets removed. I think it is logical to decouple app-specific titlebar colors from color schemes. This would make assigning such colors easier for both users (and potentially developers), as it would allow you to set the titlebar color without creating a whole scheme. Ultimately, it could even be automated, but that's a much bigger project. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 401367] Libre Office "File" bug (menu being constructed too hastily?)
https://bugs.kde.org/show_bug.cgi?id=401367 --- Comment #4 from leftcrane --- BTW, there is no problem with Mate-HUD, the file menu gets exported. So it may not be a Libre Office bug necessarily. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 401367] Libre Office "File" bug (menu being constructed too hastily?)
https://bugs.kde.org/show_bug.cgi?id=401367 --- Comment #3 from leftcrane --- Actually no, it's a problem in hamburger menu as well. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401191] [feature] - make panel dragging mechanism multi-monitor aware
https://bugs.kde.org/show_bug.cgi?id=401191 --- Comment #2 from leftcrane --- related issue for reference: Bug 401191 I currently have the tilebars just going below the panel anyway (they are still there). If only there was some way to transfer a click from a black space on the panel onto the underlying titlebar, it would act like a true titlebar, indepenendently of the number of monitors. One would also need to prevent the user from inadvertently clicking the close buttons on the windows though, and that would be messy. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 400690] [feature] - Latte Dock should allow the user to click on an application to cycle through instances
https://bugs.kde.org/show_bug.cgi?id=400690 --- Comment #2 from leftcrane --- If you implement this, please don't add minimization to the cycle. I should just cycle between windows in the group not minimize/restore states. I know current behavior allows for minimizing by left click on the dock icon, but this behavior is negatively impacts the primary function of the dock. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 400690] [feature] - Latte Dock should allow the user to click on an application to cycle through instances
https://bugs.kde.org/show_bug.cgi?id=400690 --- Comment #6 from leftcrane --- (In reply to Michail Vourlakos from comment #5) > (In reply to leftcrane from comment #4) > > > > have you used the mouse wheel behavior for cycling grouped tasks that Latte > already provides? Yes, that's the simple version version of the behavior I'd like too see. So yes, just allow the left click do the exactly the same thing that the scroll event does now. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 400690] [feature] - Latte Dock should allow the user to click on an application to cycle through instances
https://bugs.kde.org/show_bug.cgi?id=400690 --- Comment #7 from leftcrane --- PS: keeping the minimization states would be "nice" but it's not essential. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 400690] [feature] - Latte Dock should allow the user to click on an application to cycle through instances
https://bugs.kde.org/show_bug.cgi?id=400690 --- Comment #4 from leftcrane --- i mean the cycle shouldn't permanently affect the minimization state, because the user just wants to see the windows, not minimize or restore. So if you have a group of three windows: * window 1 active, * window 2 is minimized, * window 3 is normal. Left-clicking on the group icon does the following. 1. First click restores and activates window 2 (the user wanted window 2, so they get window 2). the minimization state of other windows is unaffected. 2. Second click activates window 3 and brings window 2 back to its original minimized state (the user just wanted window 3, they did not want to un-minimize/restore window 2) 3. Third click activates window 1. 4. Fourth Click, does the same thing (1) does. If the group has only one window and that window is already active, clucking on the task-bar icon should do NOTHING. == Or it could be even simpler (for the developer): clicking on the taskbar only restores/cycles, but NEVER minimizes. -- You are receiving this mail because: You are watching all bug changes.
[klipper] [Bug 401568] New: action buttons in the popup at cursor position
https://bugs.kde.org/show_bug.cgi?id=401568 Bug ID: 401568 Summary: action buttons in the popup at cursor position Product: klipper Version: 5.14.4 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- It is inconsistent to have the action icons (action, barcode, edit) in the plasmoid but not in the popup. Operating System: Kubuntu 18.10 KDE Plasma Version: 5.14.4 Qt Version: 5.11.1 KDE Frameworks Version: 5.52.0 Kernel Version: 4.18.0-11-generic OS Type: 64-bit -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 401367] Libre Office "File" bug (menu being constructed too hastily?)
https://bugs.kde.org/show_bug.cgi?id=401367 --- Comment #6 from leftcrane --- Just upgraded to 5.14.4 and rebooted. Issue persists. -- You are receiving this mail because: You are watching all bug changes.
[klipper] [Bug 401567] New: allow pinning of clipboard items to top of stack.
https://bugs.kde.org/show_bug.cgi?id=401567 Bug ID: 401567 Summary: allow pinning of clipboard items to top of stack. Product: klipper Version: 5.14.4 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: plasma-widget Assignee: plasma-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- some clipboards have this and it's incredibly useful. just have a "pin" icon next to the item. pinned items stay on top unless they are unpinned. Operating System: Kubuntu 18.10 KDE Plasma Version: 5.14.4 Qt Version: 5.11.1 KDE Frameworks Version: 5.52.0 Kernel Version: 4.18.0-11-generic -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] New: kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 Bug ID: 401576 Summary: kwin rules for app-specific color themes: facilitate color matching between titlebar and app color Product: systemsettings Version: 5.14.4 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Flags: Brainstorm+, VisualDesign+ The current way to get color matching between app color and title-bar color is tedious for users (especially since GTK apps don't follow KDE color schemes). I am wondering if it could be done in a way that requires less user input Some ideas: 1. (KWin feature, invasive, lots of work for developers) A script polls (or examines at first launch) the color under the title-bar - usually in the upper left corner - and sets the appropriate titlebar color, maybe with some user input if at first launch. 2. (KCM, user-input) Setting to change the titlebar color only without having to create a new color scheme. The complementary color values for active/inactive text should be automatically generated based on the the chosen app-specific tile-bar colors and the based on the contrast values implied by the global color scheme. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 401576] kwin rules for app-specific color themes: facilitate color matching between titlebar and app color
https://bugs.kde.org/show_bug.cgi?id=401576 --- Comment #1 from leftcrane --- Separating the app-specific titlebar color from the color schemes may also make it possible to specify the titlebar color at launch, which means app-developers could theoretically define the color value in their launcher script, so things look nice with zero user input. Anyway, sorry if this is a frivolous request. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401352] New: Improve keyboard accessibility.
https://bugs.kde.org/show_bug.cgi?id=401352 Bug ID: 401352 Summary: Improve keyboard accessibility. Product: kwin Version: 5.14.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: appmenu Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Another suggestion to improve the accessibility of the menu (related to Bug 401351) Suggestion is to have to bring up the menu popup, then (or maybe just first letter???) to interact with the menu normally. Also Esc should preferably close the menu popup. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401351] New: Option to make the appmenu button wider and make the top-level menu items bigger.
https://bugs.kde.org/show_bug.cgi?id=401351 Bug ID: 401351 Summary: Option to make the appmenu button wider and make the top-level menu items bigger. Product: kwin Version: 5.14.3 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: appmenu Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- The menu button is hampered by the fact that it's pretty tiny, also the menu items are tiny too. This may be OK for a menubar that's always visible (because it saves space and allows the user to aim beforehand), but it is bad for a hidden menu). There are no space constraints for the menu button or its popup. I think it should be much bigger by default, although an option would be okay too. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401353] New: Option to have mouse hover to reveal main menu (accessibility)
https://bugs.kde.org/show_bug.cgi?id=401353 Bug ID: 401353 Summary: Option to have mouse hover to reveal main menu (accessibility) Product: kwin Version: 5.14.3 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: appmenu Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Another suggestion to improve accessibility. It would make the app menu better approximate real menubars (where you don't have to click to reveal the top-level items). Wouldn be very useful in conjunction with a bigger menu-button. -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 401368] Top menu initially sluggish at the launch of any Jet Brains IDE, cascading menus don't work initially. Crashes observed.
https://bugs.kde.org/show_bug.cgi?id=401368 --- Comment #1 from leftcrane --- The sluggishness might have been a random glitch, but the failure to cascade on hover, inability to exit certain menus normally and crashes are reasonably consistent. This is 100% a topmenu bug, because LIM works. -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 401368] New: Top menu initially sluggish at the launch of any Jet Brains IDE, cascading menus don't work initially. Crashes observed.
https://bugs.kde.org/show_bug.cgi?id=401368 Bug ID: 401368 Summary: Top menu initially sluggish at the launch of any Jet Brains IDE, cascading menus don't work initially. Crashes observed. Product: kded-appmenu Version: 5.14.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: top menubar Assignee: plasma-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- The issue applies only to the horizontal menubar plasmoid, but not to LIM. Immediately after first launch, the user is unable cascade the top-level menu items by hovering over them. You have to click on each top-level individually to open it. Furthermore, sometimes the menus don't close (open "Help", then click anywhere outside the menubar but the Help menu stay open). I have also observed crashes plasmashell, panel and latte dock after using this. After about five minutes and a bit of switching back and forth between various windows, the top menu of JeBrains begins to work normally. It seems like the plasmoid (unlike LIM) is too hasty in constructing the menu and may be constructing it incompletely. This is probably related to the Libre Office bug, since the glitches follow the same pattern: Bug 401367 Operating System: Kubuntu 18.10 KDE Plasma Version: 5.14.3 Qt Version: 5.11.1 KDE Frameworks Version: 5.52.0 Kernel Version: 4.18.0-11-generic OS Type: 64-bit JetBrains. CLion 2018.3 Build #CL-183.4284.140, built on November 20, 2018 JRE: 1.8.0_152-release-1343-b15 amd64 JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o Linux 4.18.0-11-generic -- You are receiving this mail because: You are watching all bug changes.
[kded-appmenu] [Bug 401367] New: Libre Office "File" bug (menu being constructed too hastily?)
https://bugs.kde.org/show_bug.cgi?id=401367 Bug ID: 401367 Summary: Libre Office "File" bug (menu being constructed too hastily?) Product: kded-appmenu Version: 5.14.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: top menubar Assignee: plasma-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- The "File" top-level item won't open in the global menu plasmoid after launch of the Libre Office programs (all of them). However after switching to another application then switching back to LO, the problem gets fixed. The bug appears to have been fixed in the LIM https://www.reddit.com/r/kde/comments/9rj2hb/global_menu_bug_with_libreoffice/ead6bpm/?context=3 Operating System: Kubuntu 18.10 KDE Plasma Version: 5.14.3 Qt Version: 5.11.1 KDE Frameworks Version: 5.52.0 Kernel Version: 4.18.0-11-generic OS Type: 64-bit Libre Office Version: 6.1.2.1 Build ID: 1:6.1.2-0ubuntu1.1 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: en-US (en_US.UTF-8); Calc: group threaded -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401388] New: Need a minimum window width
https://bugs.kde.org/show_bug.cgi?id=401388 Bug ID: 401388 Summary: Need a minimum window width Product: kwin Version: 5.14.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Created attachment 116495 --> https://bugs.kde.org/attachment.cgi?id=116495=edit window shrinks to line Sometimes windows can get resized by accident. Some don't define a minim width, meaning that a window can potentially shrink to a single line (see gif). There should be some stopgap to prevent them from getting too small. Operating System: Kubuntu 18.10 KDE Plasma Version: 5.14.3 Qt Version: 5.11.1 KDE Frameworks Version: 5.52.0 Kernel Version: 4.18.0-11-generic OS Type: 64-bit -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401192] [feature] - support titlebar hiding and dragging from the panel for tiled windows
https://bugs.kde.org/show_bug.cgi?id=401192 --- Comment #2 from leftcrane --- What about just doing it though Kwin? have a series of top panels that only partially cover the maximized/tiled titlbars. The titlebars only go below the windows if they are maximized/tiled. Then merge then modify the window decoration color/opacity/size with the that of the top panel. That way the user only interacts with the actual titlebars, not with the panel. Seems like a much cleaner and more intuitive to just interact with the titlebars. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401188] Titlebar doesn't hide anymore after ticking "Support borderless windows in different layouts" (using buttons plasmoid compliled from git)
https://bugs.kde.org/show_bug.cgi?id=401188 --- Comment #3 from leftcrane --- Using latte git. I resolved the issue by manually editing kwinrc. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 401353] window decoration menu button: Option to have mouse hover replace the button with the actual menu bar itself, right there in the titlebar
https://bugs.kde.org/show_bug.cgi?id=401353 --- Comment #6 from leftcrane --- I worded this feature request badly. please read this clarification. I was thinking of doing more of a popup so that no modifications to the server-side decorations would be required. If one were to modify server-side decorations, then it makes sense to do a more general solution where actual headerbar (DWD-style, but just relying on global menu for now) can be constructed from the menu items and even custom commands. It would also include search. In principle such a headerbar could be customized by the user, but developers and packagers could ship the headerbar layouts via config files. See the (rough) idea here: https://medium.com/@leftcrane/unity-headers-concept-using-server-side-hearderbars-to-create-a-consistent-customizable-and-fbdb0d9696c (NOTE: the HUD popup whould should probably start at the titlebar for visual and space reasons, not be displayed in the center). == TL;DR: Anyway the idea is this: Introduce the functionality first as a Alt/hover activated popup. The popup window just happens to __cover__ the titlebar. It's an overlay of sorts. At the most basic level, the popup just contains a menubar widget. That's it. But it can later be upgraded to a customizable HUD that not only contains flexible and easily clickable menus, but also a menu-search, buttons, single-key accelerators, the tracking of most heavily used menu items and even custom user macros (think Emacs-Helm). After most of this functionality is there, maybe some of the functionality of this popup could be integrated into the actual KWin titlebars (headerbar style), at which point. I don't know though, maybe it makes sense to start with kdecoration with HUD delivered later. The ultimate goal is DWD-lite plus HUD without first needing to finalize the DWD protocol or wait until app and DE developers start implementing it. It could actually serve to popularize the DWD idea and jumpstart work on true DWD. I've been thinking a lot about this as you can tell, since the fragmentation caused by CSD and the demise of Unity HUD has been driving me crazy, and I am just sharing some ideas on how to begin to reverse some of the damage. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401517] New: pass information regarding the window state to GTK applications
https://bugs.kde.org/show_bug.cgi?id=401517 Bug ID: 401517 Summary: pass information regarding the window state to GTK applications Product: kwin Version: 5.14.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: compatibility Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Widgets in GTK apps (using Awaita) are intended to be displayed differently depending on window state. But on KDE they all look the same, regardless of window state. This bug should be resolved for apps to look as intended and for reasons of consistency between QT themes (which can make use state) and GTK themes. Also, it's a nice effect. Operating System: Kubuntu 18.10 KDE Plasma Version: 5.14.3 Qt Version: 5.11.1 KDE Frameworks Version: 5.52.0 Kernel Version: 4.18.0-11-generic OS Type: 64-bit -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 401353] window decoration menu button: Option to have mouse hover replace the button with the actual menu bar itself, right there in the titlebar
https://bugs.kde.org/show_bug.cgi?id=401353 --- Comment #8 from leftcrane --- also, just a note, with HUD the menubar could be converted to a full height sidebar to deliver touch functionality. On a bunch of apps you can easily hide the entire UI and pull it up only when you actually need it. The possibilities are basically limitless. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401188] New: Titlebar doesn't hide anymore after ticking "Support borderless windows in different layouts" (using buttons plasmoid compliled from git)
https://bugs.kde.org/show_bug.cgi?id=401188 Bug ID: 401188 Summary: Titlebar doesn't hide anymore after ticking "Support borderless windows in different layouts" (using buttons plasmoid compliled from git) Product: latte-dock Version: git (master) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Compile and install the latte window buttons applet from git. 2. Add the applet to the latte panel. 3. Verify that window titlebars are hidden when you maximize window. 4. Now go to layouts and tick (turn on) "Support borderless windows in different layouts" 5. The titlbar is no longer hidden 6. Untick the the same option in layouts. 7. The tilebar stay shown. 8. Log in/out, remove/add buttons applet, change layouts. The titlbar will always stay shown. OBSERVED RESULT Titlebar stays shown for maximized windows. EXPECTED RESULT Titlebar should be hidden. SOFTWARE/OS VERSIONS Windows: MacOS: Linux/KDE Plasma: Kubuntu 18.10 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401190] New: cycle grouped windows on app icon click (immediate mode)
https://bugs.kde.org/show_bug.cgi?id=401190 Bug ID: 401190 Summary: cycle grouped windows on app icon click (immediate mode) Product: latte-dock Version: git (master) Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY Latte dock has an option to cycles windows on middle click. There should an option to cycles them on left click. I'd argue this would be the best default for most users too, especially since the widnow overviews on KDE are hard to use due to the hardcoded window dimming behavior. Other alternative are also poor: window thumbnail previews has a delay, while window highlight is crippled by both a delay and transparency (again making stuff harder to see). SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 18.10 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401191] New: Support true multi-monitor for window operations.
https://bugs.kde.org/show_bug.cgi?id=401191 Bug ID: 401191 Summary: Support true multi-monitor for window operations. Product: latte-dock Version: git (master) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY The application should follow the last active window per monitor, not the last active window across all monitors. For example the drag and double click functionality (maximize/restore/move) and buttons applet (compiled from git) works only if the window is activated. Since on KDE only one window is active per screen, you can't use the functionality unless you activate the window first. The panel therefore doesn't have the expected behavior of a titlebar. A titlebar can be used without first having to separately click-activate the window and the panel should be consistent with this behavior. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 18.10 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401192] New: Support titlebar hiding and dragging from the panel for tiled windows
https://bugs.kde.org/show_bug.cgi?id=401192 Bug ID: 401192 Summary: Support titlebar hiding and dragging from the panel for tiled windows Product: latte-dock Version: git (master) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY Gnome has this behavior where if you have two windows tiled, dragging from the left side of the panel grabs and untiles the left window, while dragging from the right untiles the right one. This is consistent with using the top panel as a titlebar/grabbar for the windows. This behavior should be enabled to maintain consistency with the behavior of true titlebars. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 18.10 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401193] New: enable drag from anywhere in the top panel to drag the window.
https://bugs.kde.org/show_bug.cgi?id=401193 Bug ID: 401193 Summary: enable drag from anywhere in the top panel to drag the window. Product: latte-dock Version: git (master) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- In keeping with the theme of making the top bar behave like a titlebar, one should be able to drag maximized/snapped windows from any part of the top panel, even if it's being occupied by a plasmoid. Most plasmoids do not require or benefit from drag behavior. Even a full volume or playback control can be used with left click and and scrollbar, and most users don't use such things anyway. But lots of users do use tile-bars to grab windows. Linux/KDE Plasma: Kubuntu 18.10 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401194] New: Implement outwardly curved panels (like gnome panel) to make maximized look more like actual windows with rounded titlebars.
https://bugs.kde.org/show_bug.cgi?id=401194 Bug ID: 401194 Summary: Implement outwardly curved panels (like gnome panel) to make maximized look more like actual windows with rounded titlebars. Product: latte-dock Version: git (master) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY Low priority and purely for looks/consistency. It's be nice to have the same shape that Gnome uses for the top panel (but generalized to work for any panel corner. So if you have just a top panel, the left and right outer corners are curved outward. If you have a top panel joined with a left-side dock (like Unity), the topmost outer corner of the dock is also curved outward. The objective is to make the shape circumscribed by the panels resemble a window with rounded titlebar. Linux/KDE Plasma: Kubuntu 18.10 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401195] New: make all the on a given screen opaque if windows go below (not just when maximized or snapped)
https://bugs.kde.org/show_bug.cgi?id=401195 Bug ID: 401195 Summary: make all the on a given screen opaque if windows go below (not just when maximized or snapped) Product: latte-dock Version: git (master) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY Minor. If any windows go below the panel, they make the stuff on the panel hard to read, even with blur enabled. The panels on the monitor should all turn opaque if any window goes below a given panel. Useful in the case of a Unity layout, where windows frequently go below the right-hand vertical panel and result in unexpected and distracting colors to be shown inside the panel. Also useful for bottom panels. Linux/KDE Plasma: Kubuntu 18.10 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401195] make all the on a given screen opaque if windows go below (not just when maximized or snapped)
https://bugs.kde.org/show_bug.cgi?id=401195 --- Comment #1 from leftcrane --- The user could of course just not use transparency, which is what I ended up doing. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401195] make all the on a given screen opaque if windows go below (not just when maximized or snapped)
https://bugs.kde.org/show_bug.cgi?id=401195 --- Comment #2 from leftcrane --- TITLE should have been: "make all latte panels the on a given screen turn opaque if windows go below (not just when maximized or snapped)" -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401196] New: do not darken/highlight windows in the present windows selector, draw a box around the selected window instead.
https://bugs.kde.org/show_bug.cgi?id=401196 Bug ID: 401196 Summary: do not darken/highlight windows in the present windows selector, draw a box around the selected window instead. Product: kwin Version: 5.14.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: effects-present-windows Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY The window previews in the overview are hard to see because they are all darkened (unless they are selected). It would be better to draw a box around the selected/hovered window without darkening all the others. Maybe a plugin could be provided to avoid recompiling KWin? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401197] New: setting control the size, position and opacity of icons in window thumbnails. Icons make it easier to pick out windows.
https://bugs.kde.org/show_bug.cgi?id=401197 Bug ID: 401197 Summary: setting control the size, position and opacity of icons in window thumbnails. Icons make it easier to pick out windows. Product: kwin Version: 5.14.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-present-windows Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- SUMMARY The icons in the overview may be too small for some people. So it might be desirable to place them in the center of the window and make them bigger. An extension like this one makes it possible: https://extensions.gnome.org/extension/302/windowoverlay-icons/ Would be nice if this was available for KWin. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401194] Implement outwardly curved panels (like gnome panel) to make maximized look more like actual windows with rounded titlebars.
https://bugs.kde.org/show_bug.cgi?id=401194 --- Comment #2 from leftcrane --- Created attachment 116401 --> https://bugs.kde.org/attachment.cgi?id=116401=edit curved corders it would be the same as gnome: https://www.solvetic.com/uploads/monthly_10_2018/tutorials-7463-0-78798800-1539876483.png imo curved is much nicer than a jagged edge, especially on a unity layout. this won't work as well with complex panel themes. but most themes can can be simplified in the latte dock config. There is also an simple alpha black theme plus control on the kde store that could be used with this: https://www.opendesktop.org/p/1084931/ https://store.kde.org/p/1237963/ -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 401194] Implement outwardly curved panels (like gnome panel) to make maximized look more like actual windows with rounded titlebars.
https://bugs.kde.org/show_bug.cgi?id=401194 --- Comment #3 from leftcrane --- (In reply to Michail Vourlakos from comment #1) > please provide a screenshot because I can not understand what you are > describing see other comment. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 402306] PackageKit crashes every time while fetching updates for Discover
https://bugs.kde.org/show_bug.cgi?id=402306 --- Comment #2 from leftcrane --- Try with this repository. # deb [arch=amd64] https://brave-browser-apt-release.s3.brave.com/ cosmic main For some reason, third-party repositories cause this problem. It's the same on Fedora, you have to tick them on/off one by one. It only affects the frontends of PackageKit, not pkcon or apt. -- You are receiving this mail because: You are watching all bug changes.
[kolourpaint] [Bug 405991] New: Kolour pain window won't activate after canvas resize
https://bugs.kde.org/show_bug.cgi?id=405991 Bug ID: 405991 Summary: Kolour pain window won't activate after canvas resize Product: kolourpaint Version: 18.04 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kolourpaint-supp...@lists.sourceforge.net Reporter: leftcr...@tutanota.com Target Milestone: --- Created attachment 119116 --> https://bugs.kde.org/attachment.cgi?id=119116=edit video of problem Version 18.04.3 Operating System: Kubuntu 18.10 KDE Plasma Version: 5.15.3 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.1 Kernel Version: 4.18.0-17-generic OS Type: 64-bit Open up the program and resize the canvas. The main window will become inactive and stay inactive. The only way to re-activate it is to alt-tab twice. i haven't tested this outside a Latte + Global Menu environment. So I can't be certain that you can reproduce this on stock KDE. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 405687] latte panels go haywire with display on the left
https://bugs.kde.org/show_bug.cgi?id=405687 --- Comment #22 from leftcrane --- No, I should have two. I have two panels on DP-2, both assigned to DP-2. Instead I get four (until I restart latte dock, then I get the correct number, which is 2) -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 405687] latte panels go haywire with display on the left
https://bugs.kde.org/show_bug.cgi?id=405687 --- Comment #23 from leftcrane --- Created attachment 118952 --> https://bugs.kde.org/attachment.cgi?id=118952=edit latter dock conf -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405807] Affix the origin to the primary monitor on X11
https://bugs.kde.org/show_bug.cgi?id=405807 --- Comment #12 from leftcrane --- I "fixed" it on my end by writing a script that sets/unsets a kwin rule forcing all windows to monitor one. Pretty crude and has to be run as hotplug, but it gets the job done. KDE should consider should consider shipping a workaround. Something as simple as a script to move all windows to pramary on display hotplug would be welcome. Users of right-secondary display will never need, but it'd be a a gosend to anyone struggling with a secondary display on the left. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405807] Affix the origin to the primary monitor on X11
https://bugs.kde.org/show_bug.cgi?id=405807 --- Comment #2 from leftcrane --- Is there something in X11 that necessitates this? Why can't the origin be located on the primary monitor (instead of whichever monitor happens to be on the left)? I don't agree that nothing is wrong. Nobody wants all their windows to shift to the secondary monitor, or do they? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405807] Affix the origin to the primary monitor on X11
https://bugs.kde.org/show_bug.cgi?id=405807 --- Comment #3 from leftcrane --- Is it different in Wayland, btw? If you connect a secondary monitor, will your coordinates also shift and cause windows to move to the left? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405807] Affix the origin to the primary monitor on X11
https://bugs.kde.org/show_bug.cgi?id=405807 --- Comment #7 from leftcrane --- Either that, or just change the setup to make sure the primary monitor is always in a specific position in the grid. So if you have three monitors horizontally, you'd actually have to arrange them vertically with the primary one at the top. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405807] New: Affix the origin to the primary monitor on X11
https://bugs.kde.org/show_bug.cgi?id=405807 Bug ID: 405807 Summary: Affix the origin to the primary monitor on X11 Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: multihead Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- The current behavior is that the origin is taken to be the upper-left corner across all displays. If you have a secondary monitor on the left, this means that that monitor becomes the primary one, because you windows will shift to that display on connect. The origin always shifts to the left-most monitor and this is what causes unexpected and undesired behavior for the users. This is the most serious issue for me on Kwin and I haven't observed this issue on any other desktop. Why not affix the origin of the multihead assembly to the center (or at least the left upper corner) of the primary monitor? I don't know if this problem is resolved in Wayland or whether it's possible to backport a fix to Kwin X11. Hopefully it can, since X11 will continue to be relevant for at least a couple more years. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405807] Affix the origin to the primary monitor on X11
https://bugs.kde.org/show_bug.cgi?id=405807 --- Comment #6 from leftcrane --- Sorry to nag, but why can't the origin be located on the primary monitor? Right now I have to move all the windows back to the primary monitor manually after I connect a secondary, because most of them shift. That's at least ten clicks and drags every time I connect. I am going to have to write KWin script to make KWin viable with multihead - something most users will never do themselves. And my script will never be as good as a real solution because it can't allow clients to position themselves intelligently - it'd just stupidly move every window to a specific monitor. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405807] Affix the origin to the primary monitor on X11
https://bugs.kde.org/show_bug.cgi?id=405807 --- Comment #8 from leftcrane --- (actually no that won't work with window snapping. so you'd have to make sure the primary is always leftmost horizontally, regardless of how the monitors are actually positioned on your desk). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 405639] Make it easier to close or invoke default action on notification popups
https://bugs.kde.org/show_bug.cgi?id=405639 --- Comment #2 from leftcrane --- some of them wont even close when you act on them - like chromium notifications -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 405687] latte panels go haywire with display on the left
https://bugs.kde.org/show_bug.cgi?id=405687 --- Comment #25 from leftcrane --- Unfortunately, the issue persists. 1. [ScreenConnectors] 10=DP-1 11=DP-2 12=eDP-1 13=HDMI-1 2. just uploaded. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 405687] latte panels go haywire with display on the left
https://bugs.kde.org/show_bug.cgi?id=405687 --- Comment #26 from leftcrane --- Created attachment 118957 --> https://bugs.kde.org/attachment.cgi?id=118957=edit latte debug 2 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 406238] New: Transparency can't be rolled back.
https://bugs.kde.org/show_bug.cgi?id=406238 Bug ID: 406238 Summary: Transparency can't be rolled back. Product: Breeze Version: 5.15.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: QStyle Assignee: unassigned-b...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Operating System: Kubuntu 18.10 KDE Plasma Version: 5.15.3 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.1 Kernel Version: 4.18.0-17-generic OS Type: 64-bit After you enable transparency in the Breeze config, you can no longer disable it. 1. Enable trasparency in the widget theme, using slider. 2. Observe transparent menus. 3. Disable transparency, using slider. 4. Transparency remains. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 406238] Transparency can't be rolled back.
https://bugs.kde.org/show_bug.cgi?id=406238 leftcrane changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #1 from leftcrane --- Error. I thought the minimum was opaque - it's actually most transparent. Not intuitive, but works fine. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 404540] [feature] - new indicator style from Gnome's Dash to Panel
https://bugs.kde.org/show_bug.cgi?id=404540 --- Comment #5 from leftcrane --- 1. Pinned and non-pinned task items are visually the same. 2. Mnimized tasks non-minimized are visually the same. 3. Shown window: highlight box. (how's "shown window" different from "active"?) 4. Active window: highlight box 5. Grouped active: highlight box 6. Grouped active, one minimized: highlight box. So pretty simple. Grey highlight box for active (and shown?) windows, no effect for inactive. Minimized windows don't need any special effect. Hover effect is also a grey highlight box (see Gnome dock below). https://github.com/home-sweet-gnome/dash-to-panel#Features The indicator styles are all listed there. They all pretty good - I just would NOT recommend mixing and matching different kids like in some of these screenshots. I'd say the Metro: https://raw.githubusercontent.com/home-sweet-gnome/dash-to-panel/master/media/design/png/metro.png and Dashes: https://raw.githubusercontent.com/home-sweet-gnome/dash-to-panel/master/media/design/png/dashes.png are most reasonable. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 404540] [feature] - new indicator style from Gnome's Dash to Panel
https://bugs.kde.org/show_bug.cgi?id=404540 --- Comment #13 from leftcrane --- I would also round the edges of the active window indicator and hover boxes. That way they will look nice in zoom mode. Otherwise when you zoom, you'll have sharp boxes protruding out of the dock. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 404540] [feature] - new indicator style from Gnome's Dash to Panel
https://bugs.kde.org/show_bug.cgi?id=404540 --- Comment #7 from leftcrane --- The dots and lines indicate the number of windows within each group. (some of them are confusing, but you can clearly see what they mean in Metro and Dashes style. These are the two best styles, IMO) -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 404540] [feature] - new indicator style from Gnome's Dash to Panel
https://bugs.kde.org/show_bug.cgi?id=404540 --- Comment #12 from leftcrane --- Created attachment 119163 --> https://bugs.kde.org/attachment.cgi?id=119163=edit mockup -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 404540] [feature] - new indicator style from Gnome's Dash to Panel
https://bugs.kde.org/show_bug.cgi?id=404540 --- Comment #11 from leftcrane --- 1. I think the maximum number is two (for three or more windows) in Metro. 2. The active window is always identifies by the gray highlight box, regardless of which style of window indicator you use. The open window indicator is completely independent from the active window indicator. 3. I think the maximum number is four. If you prefer, you can round out the outer corners of the indicators (see mockup) -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 404540] [feature] - new indicator style from Gnome's Dash to Panel
https://bugs.kde.org/show_bug.cgi?id=404540 --- Comment #15 from leftcrane --- Correct -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 404540] [feature] - new indicator style from Gnome's Dash to Panel
https://bugs.kde.org/show_bug.cgi?id=404540 --- Comment #9 from leftcrane --- 1. Big line is one window. Big line with marks at the end is multiple windows. 2. Shown/minimized windows are exactly the same. I don't think it makes sense to differentiate them - that just makes the dock more confusing. 3. Yes: https://github.com/home-sweet-gnome/dash-to-panel/raw/master/media/design/gif/previews.gif -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405807] Affix the origin to the primary monitor on X11
https://bugs.kde.org/show_bug.cgi?id=405807 --- Comment #14 from leftcrane --- I think a shortcut or trigger to move all windows to primary is simple enough to work as advertised. But it's your call obviously. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405807] Affix the origin to the primary monitor on X11
https://bugs.kde.org/show_bug.cgi?id=405807 --- Comment #10 from leftcrane --- Yeah, I've looked into this and it seems like this is native behavior for X11. So there is no way to set the origin elsewhere? It always has to the be in the left corner? -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 404539] New: Option to require pressure to show the panel.
https://bugs.kde.org/show_bug.cgi?id=404539 Bug ID: 404539 Summary: Option to require pressure to show the panel. Product: latte-dock Version: git (master) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- The gnome dash to dock extension has a setting to require pressure sensitivity to bring up the dock from hidden state. This helps against accidentally bringing up the dock when it's positioned on the left of the screen. The problem is that applications have many controls that also positioned along the left edge, so that when you try to hit an application button in that area it's very easy to bring up the dock by accident. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 404540] New: For Latte dock, option to have alternative indicator style copied from Gnome's Dash to Panel.
https://bugs.kde.org/show_bug.cgi?id=404540 Bug ID: 404540 Summary: For Latte dock, option to have alternative indicator style copied from Gnome's Dash to Panel. Product: latte-dock Version: git (master) Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: plasmoid Assignee: mvourla...@gmail.com Reporter: leftcr...@tutanota.com Target Milestone: --- Gnome's style can be found here: https://github.com/home-sweet-gnome/dash-to-panel (under Customizable running indicators) It offers a few advantages over most Plasma styles and the Latte style. - It is easier to tell which window is active. - The active window indicator does not interfere with the indicator responsible for identifying the number of open windows, which gives more flexibility in terms of indicators. - Indicators are colored from the icon, which makes better visual differentiation of the dock items. - (I think) Mousing over the dock icons draws a box around them. The current latte style just faintly highlights the icon, which makes it much more difficult to tell which icon you're about to select. Highlight boxes provide much better visual feedback. Note that dash to dock's style, except the coloring, is the same as Windows uses. Presumably Windows conducted some usablity surveys and decided this is a good style to use, so I think it makes sense to have this style as an option in Latte. Having used Windows and Gnome extensively in the past, it is my opinion that their docks styles provide a better user experience. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 405380] New: Apt Updates fail to load in Discover
https://bugs.kde.org/show_bug.cgi?id=405380 Bug ID: 405380 Summary: Apt Updates fail to load in Discover Product: Discover Version: 5.15.2 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Updater Assignee: lei...@leinir.dk Reporter: leftcr...@tutanota.com CC: aleix...@kde.org Target Milestone: --- The update plasmoid show a number of packages, but when you click view updates, you don't see any apt updates in Discover. However, if you disable and then enable ANY apt source, the updates will appear. So every time I want to update I have to go to sources, then toggle a random apt repo on and off. Operating System: Kubuntu 18.10 KDE Plasma Version: 5.15.2 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.1 Kernel Version: 4.18.0-16-generic OS Type: 64-bit -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 405252] Add a more definite hover effect to improve visual feedback /accessibility. (normal hover effect, like you see in menubars etc.)
https://bugs.kde.org/show_bug.cgi?id=405252 --- Comment #13 from leftcrane --- lol it's cause I need the cycle effect. The KDE dock has no decent alternative for switching between grouped windows. Also the indicators are really poorly executed. Imo, Latte dock would be ideal if it kept the magnification feature - which is useful on small screens, but stuck to a sane default style, like Gnome dash to dock. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 405252] Add a more definite hover effect to improve visual feedback /accessibility. (normal hover effect, like you see in menubars etc.)
https://bugs.kde.org/show_bug.cgi?id=405252 --- Comment #11 from leftcrane --- Well, I don't know about you but I am constantly clicking on the wrong items in the dock precisely because there is no visual feedback to tell me what I am about to click on. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 405343] Typing invokes filter function (like Gnome Nautilus)
https://bugs.kde.org/show_bug.cgi?id=405343 --- Comment #1 from leftcrane --- Basically you start typing and it searches/filters the current directory, with the first result highlighted. Then you can just press enter and open the result. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 405343] New: Typing invokes filter function (like Gnome Nautilus)
https://bugs.kde.org/show_bug.cgi?id=405343 Bug ID: 405343 Summary: Typing invokes filter function (like Gnome Nautilus) Product: dolphin Version: 18.04.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: bars: filter Assignee: dolphin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- The default typing behavior isn't ideal. To get a file by typing, you have to type the first characters of the file really fast. It would be better typing automatically invoked the filter function, which is much more user friendly. Pressing control + I every time you want to drill down to a file isn't ideal. To see the proposed behavior in action, open Nautilus and start typing. You will get a list of search results, with the ones from the current directory appearing first. It would be tough to implement efficient type-to-search on KDE, so instead i propose type-to-filter (or type-to-search on the current directory). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405428] Secondary monitor positioned to right acts as a primary monitor (windows positions are not remembered either)
https://bugs.kde.org/show_bug.cgi?id=405428 --- Comment #3 from leftcrane --- OK, KWin is feature frozen, so the workaround for this issue becomes: - Ship a KWin script to move all windows to primary monitor. Maybe have this script (optionally) fire when a secondary monitor is reconnected. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 405252] Add a more definite hover effect to improve visual feedback /accessibility. (normal hover effect, like you see in menubars etc.)
https://bugs.kde.org/show_bug.cgi?id=405252 --- Comment #15 from leftcrane --- I know, but this isn't about the indicators - it's about the hover effect. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405428] New: Secondary monitor positioned to right acts as a primary monitor (windows positions are not remembered either)
https://bugs.kde.org/show_bug.cgi?id=405428 Bug ID: 405428 Summary: Secondary monitor positioned to right acts as a primary monitor (windows positions are not remembered either) Product: kwin Version: 5.14.3 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: multihead Assignee: kwin-bugs-n...@kde.org Reporter: leftcr...@tutanota.com Target Milestone: --- Operating System: Kubuntu 18.10 KDE Plasma Version: 5.15.2 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.1 Kernel Version: 4.18.0-16-generic OS Type: 64-bit Display server: X11 This occurs when you have two monitors connected to a laptop (screen inactive) and the right-hand one is primary. Once you disconnect the monitors and reconnect, windows start to appear on the left-hand monitor (even if the mouse is on the primary monitor). This goes for both windows that were already open, which get moved to the right-hand monitor and for some new windows. This includes, notably, the full-screen program launcher. Even though its icon is located on the right screen, the launcher opens on the left after disconnect/reconnect. The same is true for many other programs, with the exception of the latest KDE and Gnome software. They get launched on the secondary monitor. Window positions aren't being remembered either - they always go to the non-primary monitor on the left, for most programs. Interestingly, latte panels from the left secondary monitor shift to the right upon disconnecting the secondary monitor. I can't tell if this is due to the latest KDE upgrade or due to me having switched my secondary monitor from right to left side a week ago. (I have active screen follows mouse enabled). I realize that is is not an exhaustive or terribly clear summary of the bug, but please be on the lookout for it. It's extremely annoying. I am not sure I can document this much further. It's a complex bug and I have a solution that works well enough for me: I just have a hotkey that restarts KWin, Latte, and Plasma every time I disconnect/reconnect monitors. Luckily KDE perfromance is good enough to permit this workaround. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 405428] Secondary monitor positioned to right acts as a primary monitor (windows positions are not remembered either)
https://bugs.kde.org/show_bug.cgi?id=405428 --- Comment #1 from leftcrane --- I'll just add that some apps appear confused about the primary monitor while others (like inkscape opening a file) actively want to appear on the right-hand secondary monitor. (for these latter apps, I have a KWin rule to force them to the primary screen). -- You are receiving this mail because: You are watching all bug changes.
