[dolphin] [Bug 417749] Creating a file on a Samba share crashes Dolphin
https://bugs.kde.org/show_bug.cgi?id=417749 Jonathan Chun changed: What|Removed |Added CC||unmonito...@jonathanchun.co ||m -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 421152] Latte dock crashes on restart only
https://bugs.kde.org/show_bug.cgi?id=421152 --- Comment #2 from Jonathan Chun --- Neither of those suggestions worked. As mentioned in the original report, I can't follow the instructions in the crash reporting page because I don't actually see any window. I can open up terminal with krunner and if I use the ps command I see that latte-dock crashed, but I don't see anything else. Changing layouts doesn't seem to help. Additionally, if I manually start latte-dock --replace & from the terminal at this point or from krunner, it starts up perfectly fine. Interestingly enough, I tried installing the current master branch and that seems to have resolved the problem. Haven't had a chance to troubleshoot further. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 421152] New: Latte dock crashes on restart only
https://bugs.kde.org/show_bug.cgi?id=421152 Bug ID: 421152 Summary: Latte dock crashes on restart only Product: lattedock Version: 0.9.11 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: unmonito...@jonathanchun.com Target Milestone: --- SUMMARY Latte dock seems to crash on restart and I'm not sure how to troubleshoot this. STEPS TO REPRODUCE 1. Restart computer that has latte-dock 0.9.11 installed (from source) 2. Latte-dock doesn't start If I grep for latte-dock, I can see that it attempted to start: $ ps aux | grep latte jchun 1809 17.0 0.4 1299944 150452 ? Tl 08:13 0:03 /usr/bin/latte-dock jchun 2001 0.3 0.0 0 0 ?Z08:13 0:00 [latte-dock] jchun 2002 0.4 0.1 604336 43636 ?Sl 08:13 0:00 /usr/lib/x86_64-linux-gnu/libexec/drkonqi -platform xcb -display :0 --appname latte-dock --apppath /usr/bin --signal 11 --pid 1809 --appversion 0.9.11 --programname Latte Dock --bugaddress sub...@bugs.kde.org --startupid 0 --restarted jchun 2060 0.0 0.0 14424 1060 pts/1S+ 08:13 0:00 grep --color=auto latte (however, I can't actually see the crash window or anything to try and get the crash report. are there logs anywhere on the system?) If I just manually run latte-dock from the terminal at this point, it starts perfectly fine. I've tried clearing the cache as documented here: https://github.com/psifidotos/Latte-Dock/wiki/How-to-Report-Crashes with no luck SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon 5.18 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.2 -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 418431] latte-dock show all running apps ( all activities ) but only launchers from current activity
https://bugs.kde.org/show_bug.cgi?id=418431 Jonathan Chun changed: What|Removed |Added CC||unmonito...@jonathanchun.co ||m -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 420004] New: [Feature Request] Only display panel/dock if there is an active window on current monitor
https://bugs.kde.org/show_bug.cgi?id=420004 Bug ID: 420004 Summary: [Feature Request] Only display panel/dock if there is an active window on current monitor Product: lattedock Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: unmonito...@jonathanchun.com Target Milestone: --- Created attachment 127482 --> https://bugs.kde.org/attachment.cgi?id=127482=edit Reference Screenshot I came across a use-case that I don't think is currently possible in latte-dock. I'd like to create a panel that is only visible if there is an active application on the current monitor. I've created a latte-dock panel at the top of each monitor that contains stuff like "Window Buttons", "Window Title" and "Window AppMenu" along with my standard system tray and other plasmoids. This works great on my primary monitor, but on my secondary monitors, the panel only contains window-related plasmoids, so I wouldn't mind if it was only active if that monitor had windows currently on it. (otherwise the panel is just blank because the window title/appmenu/button plasmoids are configured to only display on active applications. I currently just have it set to always visible because autohide is ugly/buggy for me (see last paragraph for a bit more detail on that**). However, even if autohide worked perfectly, it still allows for the possibility of moving my mouse to that area and seeing a blank panel (which is not optimal. It would be great if it worked exactly like the on-demand sidebars, but the toggle for it is whether there is currently active windows on the current screen or not) ** Finally, I don't know if it is intentional or not, but "activate kwin edge" seems to be forced on my panels, meaning autohide gets buggy (perhaps this needs to be a different bug?) and ugly. See reference screenshot (there's this weird blue color when I hover my mouse near the auto-hide area if kwin edge is active. I haven't managed to get fix it without disabling it. it disables fine on my docks but not with my panels) Not really sure what kwin edge even is. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419659] Need help troubleshooting badge counter notifications in latte-dock.
https://bugs.kde.org/show_bug.cgi?id=419659 Jonathan Chun changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #9 from Jonathan Chun --- Update. After going crazy and testing a bunch of stuff out, I wasn't able to figure out what the problem was because everything looked OK. Then... it magically fixed itself after I started playing around with Python's libunity bindings/dbus/building my own electron app to see if I can reproduce it, I noticed the badge counters were working perfectly! Extremely confused, I went back and looked through to see where I went wrong(right?). Turns out, you need to: sudo apt-get install libunity-dev on Kubuntu/KDE Neon. I had previously thought that I might have been missing libunity on my system, so I did apt search libunity This gave me a TON of results, a lot of which I already had installed such as libunity-protocol-private0, libunity-core-6.0-9, libunity9, so I mistakenly assumed I was OK on that front. Who would have guessed that libunity-dev is required as well... In any case, I've marked this resolved. There are still other issues with the unity launcher API only working with specifically named files and flatpak/snapstore/etc changing it and breaking compatibility, but thanks to all the effort I put into troubleshooting this, I think I have an idea of how to resolve that as well. Thank you for your patience Michail! - One thing to consider. I don't know what the standard is for apt dependencies, but if a major feature like unity launcher API doesn't work without the libunity-dev package, perhaps it should either 1. be documented in FAQ, or 2. added to the package requirements? Depends: plasma-desktop, plasma-pa, plasma-workspace (>= 4:5.9.0~), libc6 (>= 2.14), libkf5activities5, libkf5archive5, libkf5configcore5, libkf5configgui5, libkf5coreaddons5, libkf5crash5, libkf5dbusaddons5, libkf5declarative5, libkf5globalaccel5, libkf5guiaddons5, libkf5i18n5, libkf5iconthemes5, libkf5newstuff5, libkf5notifications5, libkf5package5, libkf5plasma5, libkf5plasmaquick5, libkf5quickaddons5, libkf5service5, libkf5waylandclient5, libkf5windowsystem5, libkf5xmlgui5, libqt5core5a (>= 5.14.1+dfsg), libqt5dbus5 (>= 5.14.1+dfsg), libqt5gui5 (>= 5.14.1+dfsg), libqt5qml5 (>= 5.14.1), libqt5quick5 (>= 5.14.1), libqt5widgets5 (>= 5.14.1+dfsg), libqt5x11extras5, libstdc++6 (>= 5), libx11-6, libxcb-randr0, libxcb1 -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419659] Need help troubleshooting badge counter notifications in latte-dock.
https://bugs.kde.org/show_bug.cgi?id=419659 --- Comment #8 from Jonathan Chun --- I am not familiar enough with C++ to know how to test my theory, but I think you can rest assured that this is not a latte-dock problem. I suspect it is an issue upstream with Electron. I'm not 100% sure where it's failing, but my guess is that in the KDE environment, this function here where it is looking for the desktop file is returning the wrong value. https://github.com/electron/electron/blob/b6246dcf122e584c672566877cb60d33dbc4705e/shell/browser/linux/unity_service.cc#L90 I was able to get badge counters (albeit fake numbers) to show up on the apps in question (Mailspring/Discord), both of which use electron with a quick python script to check the unity launcher api, Both libunity and straight through dbus work fine with a quick python script: https://paste.ubuntu.com/25473314/ https://paste.ubuntu.com/25615125/ I got the snippets from https://github.com/micheleg/dash-to-dock/pull/590 from the guy who wrote the unity launcher feature for dash to dock, so fairly certain that it's up to spec with the Unity Launcher API. I get "true" if i console.log IsUnityRunning(), so it's not being blocked by the fact that I'm running KDE. https://github.com/electron/electron/blob/b6246dcf122e584c672566877cb60d33dbc4705e/shell/browser/linux/unity_service.cc#L118 Here, we can see that KDE4/KDE5 are considered valid unity environments: https://github.com/electron/electron/blob/b6246dcf122e584c672566877cb60d33dbc4705e/shell/browser/linux/unity_service.cc#L65 - Mostly just documenting this stuff here so that if someone comes across it in the future, they can at least see what I tried. I'll do a little bit more testing and probably open an issue with Electron for further troubleshooting assistance, so I think we can close it out here on the KDE side if you agree. I can circle back here with a new ticket if I get anything more concrete pointing at lattedock. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419812] Latte crashes when trying to use "Window Buttons" applet with multiple monitors
https://bugs.kde.org/show_bug.cgi?id=419812 --- Comment #7 from Jonathan Chun --- Thank you again. I'll start figuring out the correct location to report things eventually. I tested the same procedure multiple times on breeze/other decorations and was not able to reproduce. Will open this ticket against the correct repo. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419812] Latte crashes when trying to use "Window Buttons" applet with multiple monitors
https://bugs.kde.org/show_bug.cgi?id=419812 --- Comment #5 from Jonathan Chun --- Created attachment 127369 --> https://bugs.kde.org/attachment.cgi?id=127369=edit kcrash2 -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419812] Latte crashes when trying to use "Window Buttons" applet with multiple monitors
https://bugs.kde.org/show_bug.cgi?id=419812 --- Comment #4 from Jonathan Chun --- Created attachment 127368 --> https://bugs.kde.org/attachment.cgi?id=127368=edit kcrash1 It just happened again, but unfortunately everything crashed including Kwin and things got really weird. Not sure I fully follow what you , what I did manage to do is get 3 new pieces of information. 1. I think that what might be related is that I restarted plasma with the following commands: kwin --replace & plasmashell --replace & I've found from various sources that those commands are the "right way" the restart plasma without a full restart of the computer. If this is incorrect, please let me know. I've noticed that the above commands can help fix screen tearing/other glitches with my desktop that happen occasionally. 2. I tried clearing the cache and restarting as recommended in the link, but that doesn't seem to help. Once latte-dock gets into this state, it seems to constantly crash if I try to interact with the "Window Buttons" applet until I restart my computer fully. 3. Attached 2 kcrash dumps that I managed to pull before reboot. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419812] Latte crashes when trying to use "Window Buttons" applet with multiple monitors
https://bugs.kde.org/show_bug.cgi?id=419812 --- Comment #3 from Jonathan Chun --- Thank you. I've bookmarked and will report back if it happens again. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419812] Latte crashes when trying to use "Window Buttons" applet with multiple monitors
https://bugs.kde.org/show_bug.cgi?id=419812 --- Comment #1 from Jonathan Chun --- Created attachment 127366 --> https://bugs.kde.org/attachment.cgi?id=127366=edit Reference Screenshot 2 This is a second screenshot showing some terminal output I was getting when I tried to restart latte-dock from the terminal before rebooting. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419812] New: Latte crashes when trying to use "Window Buttons" applet with multiple monitors
https://bugs.kde.org/show_bug.cgi?id=419812 Bug ID: 419812 Summary: Latte crashes when trying to use "Window Buttons" applet with multiple monitors Product: lattedock Version: git (master) Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: unmonito...@jonathanchun.com Target Milestone: --- Created attachment 127365 --> https://bugs.kde.org/attachment.cgi?id=127365=edit Reference Screenshot SUMMARY I'm unfortunately not able to reproduce this consistently, but it seems to happen after usage of my computer for a while and active switching between windows. STEPS TO REPRODUCE 1. Set up 2 monitors 2. Set up a latte panel at the top 3. Add "Windows Buttons" applet to top panel 4. In Latte Dock Settings, enable "support borderless maximized windows in different layouts" 5. Do random activity here (unsure of what I did) 6. While having a window maximized on my second monitor (the one without the latte panel), try and use either the windows buttons applet OR just clicking/dragging to move the window with empty space feature 7. Get crash. View attached screenshot. 8. After a few reboots I'm actually no longer able to reproduce this, but I will report it anyways because there was clearly a problem at some point. SOFTWARE/OS VERSIONS KDE Neon 5.18 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION Both were built from source today: https://github.com/KDE/latte-dock https://github.com/psifidotos/applet-window-buttons -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419796] Allow rearranging of unpinned icons in latte tasks plasmoid
https://bugs.kde.org/show_bug.cgi?id=419796 --- Comment #1 from Jonathan Chun --- For clarity, the process of pinning an app seems to be to right click -> Check the "pin launcher" box. I can't find an easier way to do it. This means the workflow to pin a new currently running app to your latte-dock is to right-click -> pin launcher, then find where your launcher moved to (because it bounces to the position right at the beginning of all the other unpinned icons), THEN dragging/dropping to the position you want. Instead, the new workflow would be to simply drag/drop the currently running/unpinned icon and moving it to the position you want. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419796] New: Allow rearranging of unpinned icons in latte tasks plasmoid
https://bugs.kde.org/show_bug.cgi?id=419796 Bug ID: 419796 Summary: Allow rearranging of unpinned icons in latte tasks plasmoid Product: lattedock Version: git (master) Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: plasmoid Assignee: mvourla...@gmail.com Reporter: unmonito...@jonathanchun.com Target Milestone: --- Currently, if the latte tasks plasmoid is configured to show running apps and pinned apps together, the pinned apps come first and are then followed by all of the unpinned apps. You can drag and drop to rearrange pinned apps, and you can drag and drop to rearrange unpinned apps, but you can't drag and drop unpinned apps -> pinned apps with first pinning them. This feels quite clunky. Note: I am assuming that all pinned apps must show up before unpinned apps. If this is not true, then I guess some of my proposal is not relevant. 1. If you click on an unpinned apps to drag and drop rearrange it, but you hover over the pinned apps area and release, it should automatically pin the app AND place it in the location you released it. 2. If you click a pinned app and drag it over to the unpinned area, assuming that it must come before all other unpinned apps, bounce it to the last available position in the pinned apps area. If the latte tasks plasmoid can handle any ordering, then just leave it there. Perhaps this is a completely different feature request and I'll open a new one if necessary, but related since we're talking about gestures/actions to drag/drop and rearrange the dock: dragging a pinned app and moving it out of the bar currently gives you a "Copy Here", "Link Here", "Add Icon" Widget context menu. This should also include a "unpin from launcher" option, or perhaps even be configurable to just be replaced with a default action of unpinning from launcher since if you're dragging an icon out of your dock, that's probably what you're trying to accomplish in the first place. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419659] Need help troubleshooting badge counter notifications in latte-dock.
https://bugs.kde.org/show_bug.cgi?id=419659 --- Comment #6 from Jonathan Chun --- (In reply to Michail Vourlakos from comment #5) > 1. The applications that fail where to they install their desktop file? > 2. If you pin them as launchers in the taskmanager are they associated > correctly with their windows? The applications are installed in /usr/share/applications. Yes, they are correctly associated with their windows and I can add to favorites/launch/etc. They all have their proper StartupWMClass set. I'll see if I can find time to dig into the implementation you linked and try and figure out what's different. I only opened the ticket here against latte dock because my initial reaction when 2 applications work in Ubuntu 18/20 but don't work in the KDE version when they're using the same Unity Launcher API is that perhaps the implementation here is different/more strict than whatever's being used in ubuntu-dock. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419659] Need help troubleshooting badge counter notifications in latte-dock.
https://bugs.kde.org/show_bug.cgi?id=419659 --- Comment #3 from Jonathan Chun --- (In reply to Michail Vourlakos from comment #2) > Latte supports the same apis that plasma taskmanagers already support, that > is the Unity api and the knotifications one. Any ideas on why Discord/Mailspring don't work in Latte if it supports the same Unity Launcher APIs that's being used in ubuntu-dock (Ubuntu 18.04/20.04). I saw some chatter about how the .desktop file needed to be named correctly and how at least in Plank, it looks for a very specific .desktop file naming convention or something. Is there any restrictions like that within Latte? Mostly referring to comments like this one: https://github.com/Foundry376/Mailspring/issues/420#issuecomment-441687528 -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419659] New: Need help troubleshooting badge counter notifications in latte-dock.
https://bugs.kde.org/show_bug.cgi?id=419659 Bug ID: 419659 Summary: Need help troubleshooting badge counter notifications in latte-dock. Product: lattedock Version: git (master) Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: unmonito...@jonathanchun.com Target Milestone: --- SUMMARY Clarification/Help wanted on troubleshooting badge counter indicators in latte-dock. All of my research ends up pointing me towards the "Unity Launcher API", but whenever I try to search for that API with regards to KDE I'm drawing mostly blanks. Could we get an authoritative answer on whether latte-dock supports it, and if it doesn't, what API DOES it support for getting badge counter notifications to work? Screenshot of badge counter just so everyone is clear what I'm talking about: https://user-images.githubusercontent.com/523210/58916011-bf527200-8722-11e9-95cf-201584345743.png Here are some threads I looked at: https://github.com/signalapp/Signal-Desktop/issues/3387 https://github.com/telegramdesktop/tdesktop/issues/4554 https://www.reddit.com/r/linux/comments/6z015m/badge_notification_feature_of_unity_comes_to_the/ Here is a related bug I found, but restarting didn't fix it for me: https://bugs.kde.org/show_bug.cgi?id=396963 I know that latte-dock supports badge counters, but I'm just having trouble figuring out how and what API controls it. Here's what I've found out so far. STEPS TO REPRODUCE 1. Have 3 distros ready. KDE Neon 18.04, Ubuntu 18.04, Ubuntu 20.04 1. Install Telegram from snap store. 2. Install discord from .deb file (0.0.10) 2a. It is important that it is installed from .deb. I couldn't reproduce the same results installing from snap store. 3. Install mailspring from .deb file (1.7.4) 3a. For Ubuntu 20.04, needed to follow https://github.com/Foundry376/Mailspring/issues/1880 to install mailspring 3b. For Ubuntu 18.04/20.04, needed to follow https://github.com/Foundry376/Mailspring/issues/420 (sudo mv /usr/share/applications/mailspring.desktop /usr/share/applications/Mailspring.desktop). OBSERVED RESULT Please refer to below table of results of whether I was able to get badge counters displayed or not after applying any relevant fixes documented above^ https://gist.github.com/Jonchun/686db25d9a815f35ce52bcb3c8863cbf EXPECTED RESULT I was hoping it would work for all of them. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 20.04, KDE Neon 18.04, Ubuntu 18.04, 20.04 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 (Only listed the highest version from KDE Neon. The Kubuntu ones are older for both 18.04/20.04.) -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419657] New: Problem building from master branch on Kubuntu 18.04
https://bugs.kde.org/show_bug.cgi?id=419657 Bug ID: 419657 Summary: Problem building from master branch on Kubuntu 18.04 Product: lattedock Version: 0.9.10 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: unmonito...@jonathanchun.com Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Install all prerequisites (Everything I installed is listed in here: https://github.com/Jonchun/macify-linux/blob/1286ed3dbf1b928634f221c7c29942a6353e9e75/macifylinux/modules/lattedock.py#L12) 2. git clone https://github.com/KDE/latte-dock.git 3. cd latte-dock 4. ./install.sh OBSERVED RESULT ``` [ 14%] Building CXX object app/CMakeFiles/latte-dock.dir/wm/waylandinterface.cpp.o /home/jchun/sources/latte-dock/app/wm/waylandinterface.cpp: In member function ‘bool Latte::WindowSystem::WaylandInterface::isAcceptableWindow(const KWayland::Client::PlasmaWindow*)’: /home/jchun/sources/latte-dock/app/wm/waylandinterface.cpp:794:31: error: ‘const class KWayland::Client::PlasmaWindow’ has no member named ‘skipSwitcher’ bool hasSkipSwitcher = w->skipSwitcher(); ^~~~ app/CMakeFiles/latte-dock.dir/build.make:1685: recipe for target 'app/CMakeFiles/latte-dock.dir/wm/waylandinterface.cpp.o' failed make[2]: *** [app/CMakeFiles/latte-dock.dir/wm/waylandinterface.cpp.o] Error 1 CMakeFiles/Makefile2:533: recipe for target 'app/CMakeFiles/latte-dock.dir/all' failed make[1]: *** [app/CMakeFiles/latte-dock.dir/all] Error 2 Makefile:140: recipe for target 'all' failed make: *** [all] Error 2 ``` If I tried git checkout v0.9.10, It gets further along in the build process % wise, but then fails out with the same error. ``` [ 73%] Building CXX object app/CMakeFiles/latte-dock.dir/wm/waylandinterface.cpp.o In file included from /home/jchun/sources/latte-dock/app/wm/abstractwindowinterface.h:27:0, from /home/jchun/sources/latte-dock/app/wm/waylandinterface.h:26, from /home/jchun/sources/latte-dock/app/wm/waylandinterface.cpp:21: /home/jchun/sources/latte-dock/app/wm/windowinfowrap.h: In copy constructor ‘Latte::WindowSystem::WindowInfoWrap::WindowInfoWrap(const Latte::WindowSystem::WindowInfoWrap&)’: /home/jchun/sources/latte-dock/app/wm/windowinfowrap.h:264:17: warning: ‘Latte::WindowSystem::WindowInfoWrap::m_activities’ will be initialized after [-Wreorder] QStringList m_activities; ^~~~ /home/jchun/sources/latte-dock/app/wm/windowinfowrap.h:259:13: warning: ‘QString Latte::WindowSystem::WindowInfoWrap::m_display’ [-Wreorder] QString m_display; ^ /home/jchun/sources/latte-dock/app/wm/windowinfowrap.h:64:5: warning: when initialized here [-Wreorder] WindowInfoWrap(const WindowInfoWrap ) noexcept ^~ /home/jchun/sources/latte-dock/app/wm/windowinfowrap.h: In constructor ‘Latte::WindowSystem::WindowInfoWrap::WindowInfoWrap(Latte::WindowSystem::WindowInfoWrap&&)’: /home/jchun/sources/latte-dock/app/wm/windowinfowrap.h:264:17: warning: ‘Latte::WindowSystem::WindowInfoWrap::m_activities’ will be initialized after [-Wreorder] QStringList m_activities; ^~~~ /home/jchun/sources/latte-dock/app/wm/windowinfowrap.h:259:13: warning: ‘QString Latte::WindowSystem::WindowInfoWrap::m_display’ [-Wreorder] QString m_display; ^ /home/jchun/sources/latte-dock/app/wm/windowinfowrap.h:94:5: warning: when initialized here [-Wreorder] WindowInfoWrap(WindowInfoWrap &) noexcept ^~ /home/jchun/sources/latte-dock/app/wm/waylandinterface.cpp: In member function ‘virtual void Latte::WindowSystem::WaylandInterface::setWindowOnActivities(QWindow&, const QStringList&)’: /home/jchun/sources/latte-dock/app/wm/waylandinterface.cpp:318:55: warning: unused parameter ‘window’ [-Wunused-parameter] void WaylandInterface::setWindowOnActivities(QWindow , const QStringList ) ^~ /home/jchun/sources/latte-dock/app/wm/waylandinterface.cpp:318:82: warning: unused parameter ‘activities’ [-Wunused-parameter] void WaylandInterface::setWindowOnActivities(QWindow , const QStringList ) ^~ /home/jchun/sources/latte-dock/app/wm/waylandinterface.cpp: In member function ‘virtual void Latte::WindowSystem::WaylandInterface::requestMoveWindow(Latte::WindowSystem::WindowId, QPoint) const’: /home/jchun/sources/latte-dock/app/wm/waylandinterface.cpp:592:63: warning: unused parameter ‘from’ [-Wunused-parameter] void WaylandInterface::requestMoveWindow(WindowId wid, QPoint from) const ^~~~
[lattedock] [Bug 419619] Panel background starts tiling/tearing under the "Plasma" color theme.
https://bugs.kde.org/show_bug.cgi?id=419619 --- Comment #6 from Jonathan Chun --- Thank you for figuring it out so quickly. I'll check it out. I'm 0 for 3 on reporting latte-dock bugs today and am starting to feel like a terrible person. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419619] Panel background starts tiling/tearing under the "Plasma" color theme.
https://bugs.kde.org/show_bug.cgi?id=419619 --- Comment #1 from Jonathan Chun --- Looks like with any plasmoid added, to the panel that can expand, such as Event Calendar or most time/date related ones, when you click on them to expand it, the entire panel changes color back to the same tiling pattern as you see in the reference screenshot. I'm unsure of whether the problem is in Latte Dock or in the plasmoids I'm using, but it seems to be consistent across multiple plasmoids. I've also tried using it without the grouping plasmoid with the same result. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419619] New: Panel background starts tiling/tearing under the "Plasma" color theme.
https://bugs.kde.org/show_bug.cgi?id=419619 Bug ID: 419619 Summary: Panel background starts tiling/tearing under the "Plasma" color theme. Product: lattedock Version: git (master) Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: containment Assignee: mvourla...@gmail.com Reporter: unmonito...@jonathanchun.com Target Milestone: --- Created attachment 127257 --> https://bugs.kde.org/attachment.cgi?id=127257=edit Reference Screenshot SUMMARY STEPS TO REPRODUCE 1. Create a on-demand panel on right side (haven't actually tested other panels) 2. Make it ~300px wide 3. Use the "Plasma" color scheme. OBSERVED RESULT You get a tiling background texture (see reference screenshot) EXPECTED RESULT Should look normal SOFTWARE/OS VERSIONS Linux: KDE neon 5.18 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION It works fine under the "Reverse" Color scheme and "Smart" scheme. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419606] White Custom Icons with theme set to dark/reverse or "smart"
https://bugs.kde.org/show_bug.cgi?id=419606 --- Comment #2 from Jonathan Chun --- Thank you so much for your quick response! I didn't know what to search and my google-fu failed me. Variations of "white icon" were too generic :(. Blacklisting the coloring worked great. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419606] New: White Custom Icons with theme set to dark/reverse or "smart"
https://bugs.kde.org/show_bug.cgi?id=419606 Bug ID: 419606 Summary: White Custom Icons with theme set to dark/reverse or "smart" Product: lattedock Version: git (master) Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: unmonito...@jonathanchun.com Target Milestone: --- Created attachment 127253 --> https://bugs.kde.org/attachment.cgi?id=127253=edit Reference Screenshot SUMMARY STEPS TO REPRODUCE 1. Add a widget that supports custom icons to latte dock 2. Set latte dock Appearance tab theme -> Reverse 3. The custom icons look like this attachment. OBSERVED RESULT the icons go all white EXPECTED RESULT I expect that it would show up as normal if it can't find a dark-mode version. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon 5.18 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION This is the latest master branch of latte-dock built from source. I am not 100% sure whether the problem is latte-dock or the plasmoids, but I have tested 3 different plasmoids that support custom icons (custom user switcher, launchpad plasma, and application dashboard. I've also tested that it is not my icon pack having issues and tried setting it to some arbitrary icons from the Breeze icon pack, and they all have the same problem. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 419601] New: [Feature Request] Allow configurable thickness margins to contain all the content.
https://bugs.kde.org/show_bug.cgi?id=419601 Bug ID: 419601 Summary: [Feature Request] Allow configurable thickness margins to contain all the content. Product: kdeplasma-addons Version: 5.18.4 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Grouping Assignee: plasma-b...@kde.org Reporter: unmonito...@jonathanchun.com Target Milestone: --- Created attachment 127250 --> https://bugs.kde.org/attachment.cgi?id=127250=edit Reference Screenshot SUMMARY Currently, the Grouping Plasmoid doesn't allow for custom thickness margins of the widgets it contains. I was told here (https://bugs.kde.org/show_bug.cgi?id=419569) that this the responsibility of the plasmoid and not the container. In CSS terms, I guess the plasmoid philosophy is to add padding and containers don't have the option to force margins? Please see attached screenshot for what I'm referring to. Most of the widgets I've tried look really bad and about to spill over outside the grouping plasmoid, but they would look perfect if they were forced inside with configurable margins. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 419569] New: Width/Length margins not working when panel size is large
https://bugs.kde.org/show_bug.cgi?id=419569 Bug ID: 419569 Summary: Width/Length margins not working when panel size is large Product: lattedock Version: git (master) Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: containment Assignee: mvourla...@gmail.com Reporter: unmonito...@jonathanchun.com Target Milestone: --- SUMMARY https://youtu.be/8sEE2p9yCxw?t=82 See this feature video at 1:22. The "Width" margins are set fairly high at 13%, but if you look at the side panel, the widgets are expanding to fill the entire width of the panel. When the panel is small enough so that only icons display, this does not happen. STEPS TO REPRODUCE 1. Create a panel 2. Size panel to something large. >250px or so so that widgets display rather than just the icon 3. Add a widget to the panel OBSERVED RESULT - Widget fully expands width with 0 margins EXPECTED RESULT - Widget should have margins and be kept inside the panel based on the setting. SOFTWARE/OS VERSIONS Linux: KDE neon 5.18 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION Latte Dock was built from source: https://github.com/KDE/latte-dock master branch on commit 688a45289a63d57f74237efa75d3b7d3d014688d. Haven't had a chance to test if this applies to older versions. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kiconthemes] [Bug 402172] Compiling against Qt 5.12 breaks QIcon::themeName with Plasma platform plugin
https://bugs.kde.org/show_bug.cgi?id=402172 Jonathan Chun changed: What|Removed |Added CC||unmonito...@jonathanchun.co ||m --- Comment #15 from Jonathan Chun --- albert -r Albert version: 0.16.1 Build date: Mar 30 2020 02:58:04 Qt version: 5.14.1 QT_QPA_PLATFORMTHEME: Binary location: /usr/local/bin/albert PWD: /home/jchun/Documents/Projects SHELL: /bin/bash LANG: en_US.UTF-8 XDG_SESSION_TYPE: x11 XDG_CURRENT_DESKTOP: KDE DESKTOP_SESSION: /usr/share/xsessions/plasma XDG_SESSION_DESKTOP: KDE OS: KDE neon User Edition 5.18 OS (type/version): neon/18.04 Build ABI: x86_64-little_endian-lp64 Arch (build/current): x86_64/x86_64 Kernel (type/version): linux/5.3.0-45-generic Bumping this to confirm it doesn't work with 5.14 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 419435] Ability to select file/folders in details view without clicking EXACTLY on the file's name.
https://bugs.kde.org/show_bug.cgi?id=419435 --- Comment #3 from Jonathan Chun --- (In reply to Jonathan Chun from comment #2) > (In reply to Nate Graham from comment #1) > > Our own open/save dialog does this too, so it's a bit odd that Dolphin > > doesn't. > > > > One concern is that this could make multi-selection using a box more > > difficult. Indeed, the file dialog doesn't even implement this at all. > > Nonetheless, the other file managers you mentioned seem to have solved this > > problem in a fairly elegant way: > > - click-and-drag upwards in an empty area = drag a selection box > > - click-and-drag sideways in an empty area = drag-and-drop > > - click-and-drag in any direction on an item's icon or label = drag-and-drop > > > > I think it would make sense if Dolphin implemented this too (and then the > > file dialog, for that matter) > > To add on to that, in most file browsers I've used, shift+click will select > from your current row and invert-select up to the row you shift+clicked on, > which eliminates the need for click+dragging altogether. I'm not saying it > shouldn't be implemented -- just providing an alternative answer to the > "selecting multiple files might be hard" problem. In fact, I actually just tested it in Dolphin and Dolphin does already implement this behavior which is nice. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 419435] Ability to select file/folders in details view without clicking EXACTLY on the file's name.
https://bugs.kde.org/show_bug.cgi?id=419435 --- Comment #2 from Jonathan Chun --- (In reply to Nate Graham from comment #1) > Our own open/save dialog does this too, so it's a bit odd that Dolphin > doesn't. > > One concern is that this could make multi-selection using a box more > difficult. Indeed, the file dialog doesn't even implement this at all. > Nonetheless, the other file managers you mentioned seem to have solved this > problem in a fairly elegant way: > - click-and-drag upwards in an empty area = drag a selection box > - click-and-drag sideways in an empty area = drag-and-drop > - click-and-drag in any direction on an item's icon or label = drag-and-drop > > I think it would make sense if Dolphin implemented this too (and then the > file dialog, for that matter) To add on to that, in most file browsers I've used, shift+click will select from your current row and invert-select up to the row you shift+clicked on, which eliminates the need for click+dragging altogether. I'm not saying it shouldn't be implemented -- just providing an alternative answer to the "selecting multiple files might be hard" problem. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 419435] New: Ability to select file/folders in details view without clicking EXACTLY on the file's name.
https://bugs.kde.org/show_bug.cgi?id=419435 Bug ID: 419435 Summary: Ability to select file/folders in details view without clicking EXACTLY on the file's name. Product: dolphin Version: 19.12.3 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: view-engine: details mode Assignee: dolphin-bugs-n...@kde.org Reporter: unmonito...@jonathanchun.com CC: kfm-de...@kde.org Target Milestone: --- Created attachment 127123 --> https://bugs.kde.org/attachment.cgi?id=127123=edit Reference Screenshot Currently in the details view, in order to select a file, I need to click in the blue area in the screenshot (the highlighted area). However, in most (all other?) file managers that I've used such as in macOS, Windows, Nautilus, Nemo, Pantheon, in this details/row view, you can click anywhere in the entire ROW rather than exactly on the file name in order to select the item. For lack of better terminology, I want it to act like a block-level element and not an inline element. Since this behavior might not be wanted by others, perhaps this should be a toggle-able option in the Details View settings. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 392531] Add option to have "Move" as default DND action instead of the pop-up menu
https://bugs.kde.org/show_bug.cgi?id=392531 Jonathan Chun changed: What|Removed |Added CC||unmonito...@jonathanchun.co ||m --- Comment #14 from Jonathan Chun --- I found this bug while I was about to submit one as I was pointed in direction from my post on reddit: https://www.reddit.com/r/kde/comments/frbn8s/questions_about_dolphin_help_with_configuring_it/ I just wanted to chime in on David Edmundson's concern and my takes on it as an end user who will be affected by the "unpredictable magic behaviour". 1. While having Windows/macOS-like "magic behavior" is nice, I don't feel it's necessary. Personally, I would be more than happy to have it default to ALWAYS MOVE, even if it is a destructive operation on the source directory because it's being moved to another partition/disk. 2. Assuming that the "magic behavior" does get implemented, while I understand the concerns, I think there are ways around it, some of which have been mentioned already. I'm in favor of just showing the context menu/choices iff the move operation is going to another partition/disk. It likely won't affect everyday normal use of Dolphin when browsing in the /home directory, and remove any uncertainties when browsing through other directories. -- You are receiving this mail because: You are watching all bug changes.
