[systemsettings] [Bug 444517] Font preview kerning is broken
https://bugs.kde.org/show_bug.cgi?id=444517 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #1 from Colin Griffith --- This bugged me too, so I started using KCharSelect to preview kerning, shaping, and so on. It seems to use Harfbuzz, which supports OpenType-styled kerning (which uses character classes in a table instead of kerning pairs), custom ligatures, and other advanced font features, and also supports traditional character pair kerning, so seems to support all fonts I've thrown at it. It'd be nice to have that in Font Management, or at least in `kfontview`, but maybe that messes up when showing the 'All Characters' preview type? Then again, 'All Characters' *already* has characters falling off the edge of the window on the sides, so it's kinda already messed up. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 466254] Error while installing package 'libjpeg.so.8.2.2' - latest release
https://bugs.kde.org/show_bug.cgi?id=466254 --- Comment #2 from Colin Griffith --- I should also mention that I'm using the User edition, rather than the Testing edition. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 466254] Error while installing package 'libjpeg.so.8.2.2' - latest release
https://bugs.kde.org/show_bug.cgi?id=466254 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #1 from Colin Griffith --- KDE Neon only recently started packaging its own copy of libjpeg, and ever since then I've avoided running updates because it keeps wanting to remove things I don't want it to remove. If I stay on the version of libjpeg that comes from Ubuntu's packages, the result is having to keep all of these packages at their old versions: digikam digikam-data gwenview libjpeg-dev libjpeg-turbo8 libjpeg-turbo8-dev libokular5core10 libpoppler-cpp0v5 libpoppler-glib8 libpoppler-qt5-1 libpoppler126 libxsimd-dev okular okular-backends okular-extra-backends poppler-utils showfoto Additionally, because of the way that the packages depend on each other (which is vastly different in the Neon packages compared to the versions in the Ubuntu repositories), you can't have a different version of the i386 libraries and the x86-64 libraries. Since KDE Neon's repositories do not provide an :i386 package, this breaks a number of i386 packages, including Wine. Here are the packages that need to be removed if I try to upgrade to Neon's libjpeg: gstreamer1.0-plugins-good:i386 libavcodec-extra58:i386 libgd3:i386 libgdk-pixbuf-2.0-0:i386 libgdk-pixbuf-xlib-2.0-0:i386 libgdk-pixbuf2.0-0:i386 libgphoto2-6:i386 libjpeg-turbo8:i386 libjpeg8 libjpeg8:i386 librsvg2-2:i386 librsvg2-common:i386 libtiff5:i386 libv4l-0:i386 libv4lconvert0:i386 libwine:i386 wine32:i386 libjpeg8-dev You'll note that libjpeg8 itself is in that list, and that's because libjpeg8 and libjpeg-turbo8 are separate packages, though libjpeg8 seems to mostly exist so that packages have something to point to if they depend on it, and it in turn just depends on libjpeg-turbo8. Removing it doesn't seem to cause any harm directly though; the harm comes from the lack of an i386 package with the same version number as the x86-64 package. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #34 from Colin Griffith --- (In reply to Ben from comment #31) > If this changes anything, I today noticed that it also has an effect on the > mouse cursor-- so long as it is within the borders of an affected window. > This surprises me as I wouldn't have expected the cursor to be part of the > same paint. > > When I moused over VS code during an instance of this bug, the cursor was > flicking between 2 cursor types, in 2 adjacent locations. I tried to record > this but the mouse appeared normal in the recording. I don't see this in any of the programs I use. In the video you posted, it looks almost like it's unsure where the mouse is supposed to be, as it jitters back and forth a lot (doesn't just change cursors). Perhaps VS Code is literally painting its own mouse cursor, like some games do? Alternatively, it might just be an nVidia driver bug, as you said you're using an nVidia card earlier. Also, I would have posted this sooner, but today I've been oddly lucky and have had fewer instances of this bug. Had to wait all day to confirm for sure that this doesn't happen to me. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #28 from Colin Griffith --- Oh, and in my initial post I had mentioned it happening to games; in particular, it happens with RetroArch. So perhaps it happens to any window that's using hardware acceleration. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #27 from Colin Griffith --- Odd. I had thought that my whole desktop froze up rather than individual applications, but now that I've actually tested this myself, it's true.. Some programs are affected, some aren't. It seems to be programs that Can play (but not necessarily ones that Are playing) video, perhaps? Telegram and Firefox are both affected, but Kate isn't. Firefox uses GTK and its own widget rendering, and Telegram uses a modified version of Qt, so it's not a widget toolkit issue (as they use wildly different widget toolkits). Kate uses Qt but is unaffected, so I'm not so quick to claim it's a Qt issue.. Or at least, not a QWidgets issue. Maybe a bug with however QML/QtQuick render things, that's also shared with how Firefox renders things? There are definitely times I get notifications and it Doesn't happen, and it also sometimes happens Without getting a notification, but there have been numerous times now where I get a notification and it starts happening in all affected applications simultaneously. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456511] VLC and Firefox freeze / stop updating their window contents after being used for a while
https://bugs.kde.org/show_bug.cgi?id=456511 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #4 from Colin Griffith --- (In reply to Nate Graham from comment #3) > I've been able to reproduce what I *think* is the same issue when I maximize > VLC or Firefox on X11. Only those two apps, and only on X11. A window resize > refreshes the content, as others have mentioned. Can others reproduce this? As I mentioned in bug 431446, this also freezes Plasma for me, and all apps. Strange that for you it only happens in those two programs, and only when they are fullscreen. Maybe it's two similar but distinct bugs? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 --- Comment #22 from Colin Griffith --- Oh, important other note I can give about this. There was one scenario where I could have it trigger 100% of the time almost no matter what, but it's unlikely I can reproduce it quite so readily anymore. One time I had updated a LOT of KDE packages all at once, but didn't reboot or log out and back in because I had a bunch of programs open and wanted to finish what I was doing first. I found that in that precarious state, I could ALWAYS cause all other programs to freeze and flicker by using certain specific programs. One of them was FontForge, specifically opening a glyph vector editing window in it. I know that FontForge is infamous for implementing its own 'pure X11' widgets instead of using a widget toolkit, and that makes me wonder if KWin is interfering with some X11 draw call that other applications are attempting to use? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 431446] Blinking panels and window contents not refreshing
https://bugs.kde.org/show_bug.cgi?id=431446 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #21 from Colin Griffith --- I have this exact same issue (on an AMD card though; see bottom for details), and have to press Alt+Shift+F12 twice (toggle compositing; once to turn off, once to turn on) every few hours. It seems to sometimes happen around the time I get a notification, and I know for a fact that this correlates because I'll be playing a game with the game's window in the top left corner of my monitor and everything will be fine, but then a notification appears and instantly causes the game to freeze as the Plasma notification popup slides into view. As it slides into view it leaves a 'trail' of itself across the window behind it, usually some other program like Firefox that I have running behind the game's window. The window the trail appears on is otherwise frozen, I believe, but I have not explicitly tested for that. I just know that the game does appear frozen, and the freezing occurs exactly at the same instant that the plasma popup for the notification starts sliding into view. Audio in the game still runs, and I can pause and hear the game pause, and see the game's current state once I've toggled compositing. I could leave compositing off and that probably fixes it, but then Firefox has a weird black box around the autoscroll marker when I middle-click auto scroll in it, and other weird little graphical bugs that annoy me. Sometimes the first indication that something like this has happened is that I'll go to switch windows, but I'll notice that hovering over taskbar entries doesn't change the color or lightness of the taskbar entry in question, and then things start to flicker when the preview popup tries to materialize. The big difference, however, is that I am NOT on an Intel GPU. I have an AMD R9 290X, and use the AMDGPU driver (rather than the radeonsi driver). It's still a Mesa driver, but it'd be more similar to Intel's Iris driver as both it and AMDGPU use the Gallium framework. If it matters, I have two monitors and have both calibrated using a colorimeter, with KDE loading the calibration at start. I also use X11 (since display calibration doesn't work under Wayland yet). I'm using KDE Neon and have all packages fully up-to-date. Issues like this have been happening for a long time, though; at first it only happened around semitransparent windows (usually plasma widgets that pop over other windows, like the various application launcher menus and notifications), but then started happening more often and with more and more window types. There are various key differences though, and I'm actually thinking it's more likely that these earlier occurrences around semi-transparent windows is a separate bug that was fixed, and coincidentally a more severe but similar-appearing bug appeared after the fix for the other one. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 426230] Joystick KCM updates values and crosshair slowly
https://bugs.kde.org/show_bug.cgi?id=426230 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #4 from Colin Griffith --- Additionally, I've noticed that if you press and release several buttons at the same time, a few of them sometimes appear 'stuck' in System Settings unless you press them again. I agree that it looks like it's trying to process all events in a queue and getting bogged down, instead of displaying the current status every few milliseconds. This is further backed up by how it lags behind while moving a control stick, but sometimes the 'snap' back to a neutral position is almost instant. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450629] Window geometry is no longer displayed when moving or resizing, and cannot be enabled anymore.
https://bugs.kde.org/show_bug.cgi?id=450629 --- Comment #5 from Colin Griffith --- (In reply to Patrick Silva from comment #3) > read bug 443723 comment 2 Yeah, I noticed that after I responded. Either way, I do not believe the fact it was mentioned constitutes it as reason enough for it to be considered the same bug. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450629] Window geometry is no longer displayed when moving or resizing, and cannot be enabled anymore.
https://bugs.kde.org/show_bug.cgi?id=450629 --- Comment #4 from Colin Griffith --- Ah, I see that the removal of the feature entirely was mentioned in the comments of that bug. I'm not sure that really constitutes it as the same bug, though, so I still don't believe this should be considered a duplicate. Furthermore, I have much less niche and much more ordinary use cases for this feature - and in a way it could be considered an accessibility feature (which of COURSE are going to be considered niche; that doesn't mean they aren't useful for a large number of people.. You'll be getting more complaints about this once distros other than Neon start packaging 5.24.x, I can guarantee it). Here's the comment I wrote on the merge request (https://invent.kde.org/plasma/kwin/-/merge_requests/1826): > @vladz, I just found this merge request while doing more research for the bug > report I just filed (https://bugs.kde.org/show_bug.cgi?id=450629). > > I'm a developer, but that's not why I used geometry information. My hands are > kinda unsteady (not because of any physical issue, but because I'm just not > good at visualizing how my hand is moving relative to the cursor on my > screen) and I often find myself overshooting where I want to place a window, > or what size I want the window to be. Interactively seeing the difference in > size now compared to before helps me know how much to compensate for my hand > missing the mark. > > For example, lets say I want a window centered on the screen. Obviously I'll > have 'Center snap zone' turned on, lets say equal to the other snap zones (so > 10px). So to center the window, I first drag it along the top of the screen > until it snaps to the middle of that... But then I have to carefully lower > the window from that snapping position to the middle of the screen. > > Before, I could simply drag the window to the top-center of the screen, > release after it snaps, then start dragging it again downward... And watch > the numbers, making sure they don't overshoot +10 or -10 pixels. > > Nowadays, I have to very caarreefully drag the window as slowly as possible > (there's a button on my mouse that's thankfully dedicated to making it move > slower, but then sometimes the act of lifting the mouse and putting it back > down to drag further still makes it go too far in one direction or another), > and even then I find myself very frequently missing the mark. > > I also use it for resizing windows; sometimes someone shares a picture or > video with me and I just have an extreme preference for watching them in > their original resolution. However, I also have a passtime of converting gifs > to mp4 files for Telegram users and I tend to use a max resolution of > 448x448, but keeping aspect ratio.. So after I watch some other video, > returning my video player to display an exact 448x448 requires me to load up > one of my previously converted gifs that's taller than it is wide, have the > video player show it at 1:1 scale, and then manually scale the width of the > window to 448px across. > > This is no longer possible, and I instead have to hunt down a gif I converted > that happened to already be a perfect square. This usually takes several more > minutes than if I could just see the size of the window while I was resizing > it. > > This has been an extremely frustrating downgrade, but I do see that your goal > in this removal was to simplify the code, make it more performant, and work > toward fixing buggy aspect-locked window handling (such as mpv) in Wayland. > As much as I hate the removal of this feature I frequently use every day, I > have to admit it's warranted. I hope it can be re-implemented in some way in > the very very near future, though.. I don't currently know of any other way > to cover my use cases. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450629] Window geometry is no longer displayed when moving or resizing, and cannot be enabled anymore.
https://bugs.kde.org/show_bug.cgi?id=450629 --- Comment #2 from Colin Griffith --- (In reply to Patrick Silva from comment #1) > > *** This bug has been marked as a duplicate of bug 443723 *** That is not the same bug at all. I'm under X11. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450629] New: Window geometry is no longer displayed when moving or resizing, and cannot be enabled anymore.
https://bugs.kde.org/show_bug.cgi?id=450629 Bug ID: 450629 Summary: Window geometry is no longer displayed when moving or resizing, and cannot be enabled anymore. Product: kwin Version: 5.24.1 Platform: Neon Packages OS: Linux Status: REPORTED Keywords: regression Severity: normal Priority: NOR Component: effects-window-management Assignee: kwin-bugs-n...@kde.org Reporter: tyna...@gmail.com Target Milestone: --- SUMMARY In KWin version 5.23.5 and older, you could enable 'Display when moving or resizing', in regards to the window geometry. After upgrading to 5.24, this option disappeared, and along with it the functionality. The only package that seems to have been removed is `libkwin4-effect-builtins1`, which is still at version 5.23.5. I don't know if this is an intentional feature removal (I *really* hope not) - like if the effect is no longer compatible with some changes to KWin under the hood - or if the package was simply forgotten about and not upgraded within KDE Neon's package repository. I also don't know for sure if the package in question is even responsible, just that it's the only package that the upgrade removed, and it seems to be KWin related. STEPS TO REPRODUCE 1. Enable the option before upgrading, located in the 'Movement' tab of the 'Window Behavior' page of System Settings. Optionally, test and make sure it works by dragging a window around or resizing it. 2. Upgrade KDE Neon's KWin package from 5.23.5 to the latest version (5.24.1 at this time). 3. Open up System Settings again and look for the option, finding it missing. 4. Might need to log out and back in first, but after upgrading KWin try resizing or moving a window around again. The window geometry information will no longer show. OBSERVED RESULT The option to enable this feature is now gone. Additionally, windows move around and resize as expected, but without showing the width/height/position of the window, and without showing how much the window has grown/shrunk/moved on each axis. EXPECTED RESULT The option to enable it should still be present, and moving/resizing windows should still show the size/position/etc. of the window that's being moved or resized. SOFTWARE/OS VERSIONS KDE Neon User Edition. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 427855] There's no option to enable/disable startup elements
https://bugs.kde.org/show_bug.cgi?id=427855 --- Comment #23 from Colin Griffith --- (In reply to Nicolas Fella from comment #21) > The MR is unrelated to this bug report. This report is about disabling > entries as opposed to removing them, the MR is about controlling the > system-wide autostart I think you've misunderstood something fundamental about both bugs. The way that system-level autostarts are controlled, is by copying them into the user-specific autostart folder and then setting them to disabled. In other words, for one to be implemented, you have to implement both. Or rather, if you fix *this* bug, both bugs become fixed automatically. That's why so many people were upset about this change, because it used to be possible to control system-level autostart entries with the GUI (once they're copied over to the user's home directory), but that is no longer possible because of your change. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 420141] Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel when display color space conversion is enabled
https://bugs.kde.org/show_bug.cgi?id=420141 --- Comment #7 from Colin Griffith --- I'm still having this problem. It's likely not seen by many people because most people don't profile/calibrate their displays with a colorimeter, so don't have display profiles installed (other than standard sRGB and the like). My guess is that however Gwenview interacts with LCMS2 is probably to blame. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 420141] Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel when display color space conversion is enabled
https://bugs.kde.org/show_bug.cgi?id=420141 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com Version|20.12.2 |21.12.0 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 427855] There's no option to enable/disable startup elements
https://bugs.kde.org/show_bug.cgi?id=427855 --- Comment #19 from Colin Griffith --- (In reply to Nick Stefanov from comment #18) > Plasma 5.21.3 - still no option to enable/disable startup entries. Why you > broke it when it used to work fine? Now it's ugly and inconvenient. Is this > the purpose? To make Plasma inconvenient? After this stupid change there's no > other DE with such awkward start up settings at all. Kudos to the dead head > dev who made it for the Golden Raspberry award. I don't think it's a good idea to be hostile toward the developer responsible, especially since they're also the one assigned to fix this bug. Don't give them more reasons to want to avoid working on it or having anything to do with it. That said, I know that the dev made this choice deliberately, and I'm not sure why they're also assigned to change it. That's a conflict of interest (albeit a relatively minor one) - they might just want the change to persist, even though everyone else doesn't want it to persist, so all they have to do to get their way is to literally do nothing. Perhaps someone else should be assigned to fix this bug? (In reply to Nate Graham from comment #6) > User feedback has spoken lol. IIRC even macOS has the ability to both disable > and delete autostart entries. :) Since [Xuetian Weng's merge request][mr] would indirectly fix this, maybe have him assigned to this bug report. [mr]: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/253 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 443787] Multimonitor Telegram click on video/picture opens on other screen flickers wildly
https://bugs.kde.org/show_bug.cgi?id=443787 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #9 from Colin Griffith --- I have half of this. Telegram opens the image view window on the wrong display (opens on the primary display instead of the same display as I have the window up in; obviously it opens on the correct display if I have Telegram running on the primary display, but I usually don't), but I don't experience any flickering. I have an AMD graphics card; slightly factory-overclocked R9 290X. I use the open source AMDGPU drivers with Mesa for OpenGL and RADV for Vulkan, but I use the proprietary driver for OpenCL (for use in Blender). OpenCL is almost certainly irrelevant, but figured I should mention I do have parts of the proprietary driver installed. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 420141] Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel when display color space conversion is enabled
https://bugs.kde.org/show_bug.cgi?id=420141 Colin Griffith changed: What|Removed |Added Summary|Gwenview acts slow and |Gwenview acts slow and |leaks memory when |leaks memory when |zooming/panning images |zooming/panning images |without an alpha channel|without an alpha channel ||when display color space ||conversion is enabled Version|19.12.3 |20.12.2 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 420141] Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel
https://bugs.kde.org/show_bug.cgi?id=420141 --- Comment #6 from Colin Griffith --- Hokay, I should have tried this before, but I think I know the culprit now. This only happens when I UNcheck 'Apply only the profile embedded in the image file'. If I keep that option enabled, the slow-down never happens on any images. If I disable it, images without an alpha channel slow down Gwenview and cause memory to climb out of control. Images With an alpha channel are still fast and do not cause memory usage increases. I have both of my monitors profiled and calibrated, so having that option unchecked allows me to see what images should look like on my monitor. At least now I suppose I can choose between accuracy and speed, but I still don't believe that memory should spiral out of control just by panning around an image or changing which image is being looked at. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 420141] Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel
https://bugs.kde.org/show_bug.cgi?id=420141 Colin Griffith changed: What|Removed |Added Ever confirmed|0 |1 Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #5 from Colin Griffith --- Unfortunately, I've noticed this behavior has returned. I don't know exactly when, but currently I'm on Gwenview version 20.12.2. At first I thought maybe it was because I used the Oibaf PPA to get bleeding edge GPU drivers, so I just finished purging that repository to return to the version of the Mesa drivers that come with Ubuntu's base packages. After rebooting, the problem has still persisted. Updated system info: Operating System: KDE neon 5.21 (User Edition) KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.8.0-43-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz Memory: 15.6 GiB of RAM Graphics Processing Unit: ASUSTeK R9 290X DirectCU II OC OpenGL Renderer: AMD Radeon R9 200 Series (HAWAII, DRM 3.38.0, 5.8.0-43-generic, LLVM 11.0.0) OpenGL Core Profile Version: 4.6 (Core Profile) Mesa 20.2.6 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kiconthemes] [Bug 432293] telegram notification counter not working
https://bugs.kde.org/show_bug.cgi?id=432293 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #8 from Colin Griffith --- Okay, I'm on KDE Neon and just got the update that supposedly fixed this. It broke it. I cannot see how many conversations have new messages for me in Telegram, instead only seeing a blue dot. I have KDE Frameworks 5.79. -- You are receiving this mail because: You are watching all bug changes.
[libkgapi] [Bug 429406] Gmail auth token is not remembered across restarts
https://bugs.kde.org/show_bug.cgi?id=429406 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #14 from Colin Griffith --- (In reply to Antonio Rojas from comment #10) > I narrowed this down to > https://invent.kde.org/pim/libkgapi/-/commit/ > 6fa8198750e7624bd7be643c8a8c428dc58a1d6d > > Reverted that commit and didn't get any authentication prompts for over 24 > hours. Went back to 20.12.0 and I'm getting prompts every few hours again. Thank you so much for fixing this! However, the page with your fix says it can't be merged without a rebase, or something like that. This bug has been irritating me a lot, and I don't have the hard drive space to compile things myself. Would really appreciate this getting merged and a new release coming out with the fix. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 430450] Profiles and realtime preview not working
https://bugs.kde.org/show_bug.cgi?id=430450 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #1 from Colin Griffith --- Yeah, I noticed this too. Glad a bug report already exists for it. This worked last month. I'm assuming Konsole - or something related - was updated recently and that's when it broke. Changes to profiles in general seem to not be applied until a new terminal is opened with that profile, either in a new window or a new tab. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 427855] There's no option to enable/disable startup elements
https://bugs.kde.org/show_bug.cgi?id=427855 --- Comment #11 from Colin Griffith --- This might be considered another bug, but another issue with this redesign is that the 'remove' button only appears when you hover the mouse over it. So when you're removing a bunch of them at once, you can't keep your mouse still and keep clicking, as the 'hover' event doesn't seem to fire until you've clicked once or jitter the mouse a bit. I don't see any reason for the buttons to hide themselves. It's not friendly for touch screens, as you don't know where to touch. It's not friendly for mice, as you don't know where to hover your mouse until you try to. When you do hover over an entry, it looks weird for only one of them to have a button and the rest not to. The fact that they highlight when you hover, and then change color when you click, makes it seem like SOMEthing should happen when you click... But nothing does. Clicking an entry does not result in any action being performed. You can't even select them, as they're not selectable items. It might be my headache talking (not related to this; I've had this headache for a while), or I might just be resistant to change. I'm sorry if I sound overly harsh, I really don't mean to. I just don't understand the purpose behind the redesign, and every time I look at any of it to see if there's a tiny bit of, "Oh, well at least that's nicer than before," I just find more things I disagree with (or perhaps am just not used to? Like I say, I maybe the headache is talking). -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 427855] There's no option to enable/disable startup elements
https://bugs.kde.org/show_bug.cgi?id=427855 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #10 from Colin Griffith --- There's another feature that is missing as a result of this feature missing: disabling a startup service on a per-user basis instead of on a system-wide basis. In the past, I have always copied all the entries in /etc/xdg/autostart/ to ~/.config/autostart/, so that I could override whether they were enabled or disabled - as setting whether they were enabled/disabled in the file stored in the home directory overrode the file in /etc/. This let me enable/disable autostart entries without affecting global system files. IF ANYTHING, I would have opted for this configuration page to detect system autostart entries, and disabling them would make a copy in the user's ~/.config/autostart directory with it disabled. This would be more ideal than having to copy the files myself.. And bringing back the previous functionality would AT LEAST make it easier than Editing The Files Myself. I know that Nicolas Fella worked hard on this, and made the change intentionally. But when even GNOME and MacOS (supposedly, according to others in here) has a feature and you're removing it from KDE of all places, you need to rethink your objectives for a user interface. I would never expect this type of feature removal to happen in KDE. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 382604] User needs to restart Plasma session to apply a new cursor theme to the whole system
https://bugs.kde.org/show_bug.cgi?id=382604 --- Comment #18 from Colin Griffith --- It looks like the code was ported to C++ from a bash script. The relevant code is here: https://invent.kde.org/plasma/plasma-workspace/-/blob/master/startkde/startplasma.cpp This was done in this commit: https://invent.kde.org/plasma/plasma-workspace/-/commit/5df9f0bcc9259e595d97d0e55399753325f7a010#31c42a873c0b74c54dc71f1f4a2ca9a6f7643718 And the code was just copied mostly without changing what it actually did, which is why the behavior didn't only start happening in 2019. For that, I had to dig REALLY far back... And eventually found this in the old SVN repository: https://websvn.kde.org/?view=revision=396433 And in particular, here: https://websvn.kde.org/trunk/KDE/kdebase/startkde?r1=396411=396433=528175 Way back on March 10th, 2005. It looks like the reason the environment variable was set back then was for kded and ksmserver. Is this still the case today? It seems like code that old working around problems in other packages (albeit other KDE packages) might not even be relevant anymore, and so safe to pull out. Additionally, I don't have KDE's source code installed on my drive, so I can't actually try changing this, compiling, and testing... Hence just talking on this bug report instead. It could be that this isn't at all related to the bug we're experiencing, and I just went on a wild goose chase for nothing. Still, it would explain the current behavior for the most part. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 382604] User needs to restart Plasma session to apply a new cursor theme to the whole system
https://bugs.kde.org/show_bug.cgi?id=382604 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #17 from Colin Griffith --- I think I figured out what causes this! According to wbauer on this page: https://phabricator.kde.org/D17187 The 'startkde' (which is now 'startplasma-x11' or 'startplasma-wayland') program sets the XCURSOR_THEME environment variable, and applications will always use the value of that environment variable until they're told otherwise. When you switch themes while logged in, you're telling existing applications to use another theme on the fly, and most will do so! But launch a new application, and it'll use the old original theme! The XCURSOR_THEME environment variable is meant to be used to override all other settings temporarily, when starting an application. The fix should simply be to remove the line(s) of code from 'startplasma-x11' that sets that environment variable. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 425749] libpyside2-py3-5.14 installation fails
https://bugs.kde.org/show_bug.cgi?id=425749 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #4 from Colin Griffith --- I'd love to see a set of packages for Pyside2 in the Neon repositories, built against the version of Qt installed through said Neon repositories. It would not only help solve dependencies like this, but also provide more up-to-date Python QT libraries for development. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 420141] Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel
https://bugs.kde.org/show_bug.cgi?id=420141 --- Comment #3 from Colin Griffith --- Since upgrading to 20.04, this no longer occurs. Not 100% sure it's gone and I've not extensively tested it, but I at least no longer have really horribly sluggish behavior when looking at .jpg files. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 425251] After cancelled upgrade I don't know how to restart the upgrade
https://bugs.kde.org/show_bug.cgi?id=425251 --- Comment #3 from Colin Griffith --- No idea who to talk to, unfortunately. I only know what the command is by using ksysguard, and thankfully not being affected by the bug you're affected by (the notification not popping up each login). -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 425251] After cancelled upgrade I don't know how to restart the upgrade
https://bugs.kde.org/show_bug.cgi?id=425251 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #1 from Colin Griffith --- For me, logging out and back in gives the notification again. I've been trying to figure out what packages are causing a bunch of KDE packages to just be marked for removal instead of upgrading, and for a while I had to constantly log in and out to test different package removals/installs. Eventually I got fed up with it and filtered ksysguard by the word 'upgr' when running the upgrader, and found out this is the full command: do-release-upgrade -m desktop -f DistUpgradeViewKDE If you just want to do it over the command line, you can leave out the '-f DistUpgradeViewKDE' part; but if you want the GUI to pop up, leave it in. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 424584] MOZ_USE_XINPUT2=1, exported by neon-settings, breaks Firefox scroll behaviour
https://bugs.kde.org/show_bug.cgi?id=424584 --- Comment #17 from Colin Griffith --- Ok, a bug that is present in Chrome but used to be absent from Firefox is now showing up in Firefox (and slightly worse) ever since this was implemented. It might be related, but I don't know as I can't test in any other desktop environments. In Chrome, if you are in another window and then click back onto the Chrome window, so Chrome is now definitely the active window... The first scroll event sent to Chrome is ignored. Now in Firefox, the first scroll event after clicking is ignored. I don't have to make a different window active to observe this effect. For now, I've commented out that line again. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 424584] MOZ_USE_XINPUT2=1, exported by neon-settings, breaks Firefox scroll behaviour
https://bugs.kde.org/show_bug.cgi?id=424584 --- Comment #15 from Colin Griffith --- Just saw KWin update, and I uncommented that line in /etc/xdg/plasma-workspace/env/neon_moz_use_xinput.sh. Scrolling in unfocused Firefox works again :D -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 424584] MOZ_USE_XINPUT2=1, exported by neon-settings, breaks Firefox scroll behaviour
https://bugs.kde.org/show_bug.cgi?id=424584 --- Comment #13 from Colin Griffith --- Looks like the following packages are still 5.19.2, at least on my end: kwin-common kwin-data kwin-dev kwin-wayland kwin-wayland-backend-drm kwin-x11 libkwin4-effect-builtins1 libkwineffects12 libkwinglutils12 libkwinxrenderutils12 plasma-sdk plasma-thunderbolt There are also several I don't have installed, namely all the Wayland backends and various '-dbgsym' packages. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 424584] MOZ_USE_XINPUT2=1, exported by neon-settings, breaks Firefox scroll behaviour
https://bugs.kde.org/show_bug.cgi?id=424584 --- Comment #5 from Colin Griffith --- (In reply to Nate Graham from comment #4) > What you're describing perfectly matches the symptoms of Bug 394772. It's > like the fix is not present on your machine. I also had those exact symptoms > before it was fixed, but now it's fixed for me. :/ > > Did that get reverted in the stable branch or in Neon or something? It's > definitely fixed for me with git master. To be clear, you can have Firefox and Kate open, and be typing letters in Kate while the mouse hovers over Firefox, and scroll Firefox while Kate still accepts all keyboard inputs from you typing? I don't know if you might be using 'focus follows mouse' or something like that, which might mess with the behavior being described. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 424584] neon-settings 0.0+p18.04+git20200713.0733 breaks Firefox scroll behaviour
https://bugs.kde.org/show_bug.cgi?id=424584 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #1 from Colin Griffith --- I was about to file a bug report, and figured I'd better check to see if someone else has already. I'm affected by this too. It looks like it was discussed here: https://phabricator.kde.org/T13335 And it was thought to be okay to make the change because one KDE-specific bug from the past had been fixed. The problem is that there are reasons that other desktop environments don't force this environment variable to be set by default, and for why Firefox does not use this behavior by default. This was not the best or brightest idea. For what it's worth, I imagine this is probably more of an issue for those of us with more than one monitor, as it makes it more likely to have more than one app maximized at a time. That's the most likely scenario in which you'd want to be able to scroll a web page while the browser is not in focus. Since this affects more than one user, I suppose it might be proper to change the status to 'confirmed', but I'm basically a nobody here - and I'm surprised the drop-down for changing the status isn't grayed out or something. I'll leave that alone until a maintainer or someone with more knowledge comes around. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software
https://bugs.kde.org/show_bug.cgi?id=386379 --- Comment #57 from Colin Griffith --- It seems that the new issue is different; it doesn't depend on icon size, it's just a huge distance scrolled each tick no matter what view I use, and no matter how the items are sized. I can't find where to change the number of lines scrolled either, it seems that option was removed. Even using evdev instead of libinput for mouse handling doesn't let me use the other options page in System Settings. I tried accessing it by commenting out the top of /etc/X11/xorg.conf.d/40-libinput.conf (which I have as a symlink to /usr/share/X11/xorg.conf.d/40-libinput.conf), which indeed loads the evdev driver for mice, but maybe KDE requires libinput to be completely uninstalled? I'll file a new bug report, I suppose.. Not entirely sure what to include in it though, as this sounds like a few things that might be bugs but might not be. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software
https://bugs.kde.org/show_bug.cgi?id=386379 --- Comment #56 from Colin Griffith --- I don't know if I should file another report, but I'm having this bug again in 20.04.3 (and possibly earlier versions). I'm using KDE Neon. Hopefully some weird configuration issue? -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 420141] Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel
https://bugs.kde.org/show_bug.cgi?id=420141 --- Comment #2 from Colin Griffith --- (In reply to Christoph Feck from comment #1) > Couldn't reproduce a memory leak, neither in windowed mode, nor in > fullscreen mode; tested with JPEG images (these for sure don't have an alpha > channel) with Gwenview master version and Qt 5.14.1. > > I suggest to use a memory profiling tool, such as valgrind or heaptrack; > leaks might be caused by the video driver. What GPU driver do you have? Do you see sluggish behavior, or is it smooth? I've gone ahead and tested it in Xephyr, and it seems smooth and without memory leaks. However, this remained true when I added the '+igpu' and '-glamaor' parameters to Xephyr. So it doesn't seem to be a GLAMOR bug, unlike the slowness within TKGate (which persists within Xephyr with either of those parameters). -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 305072] Animated GIF is some milliseconds too slow
https://bugs.kde.org/show_bug.cgi?id=305072 --- Comment #8 from Colin Griffith --- I'm now relatively convinced that this is, in part, caused by bug 420141 (which I just filed today). However, I'm noticing that even on gifs with alpha transparency, there's STILL a small amount of slowdown - just not nearly as much. So while I think that bug helps get to the root of the problem, there's still something else going on here. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 420141] New: Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel
https://bugs.kde.org/show_bug.cgi?id=420141 Bug ID: 420141 Summary: Gwenview acts slow and leaks memory when zooming/panning images without an alpha channel Product: gwenview Version: 19.12.3 Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: tyna...@gmail.com Target Milestone: --- SUMMARY Gwenview is sluggish and leaks memory constantly when viewing images which lack an alpha channel. Memory increases every time any operation is performed, such as panning/zooming the view, or the next frame of a gif being rendered. STEPS TO REPRODUCE 1. Open the system monitor (I use KSysGuard) and filter process names to only show Gwenview. 2. Open an image that lacks an alpha channel. 3. Zoom in on the image so that you can pan, and observe that RAM usage increases. 4. Pan around the image, and observe that RAM usage increases. 5. Switch to an image with an alpha channel. Note that RAM usage does not decrease. 6. Zoom in on the image so that you can pan, and observe that RAM usage stays constant. 7. Pan around the image, and observe that RAM usage stays constant. OBSERVED RESULT Every time you zoom or pan the image, the operation is sluggish and at a low framerate... And Gwenview's memory consumption gets higher. The slowdown is particularly noticeable when panning. Note that this does not happen when you switch to viewing an image with an alpha channel - RAM usage stays constant (but does not go down), and panning around the image is incredibly fast and smooth. EXPECTED RESULT The same behavior that is observed when viewing images with an alpha channel - constant RAM usage, and smooth panning/zooming. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.18 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.69.0 Qt Version: 5.14.1 Kernel Version: 5.3.0-46-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz Memory: 15.6 GiB of RAM Graphics Processing Unit: ASUSTeK R9 290X DirectCU II OC OpenGL Renderer: AMD Radeon R9 200 Series (HAWAII, DRM 3.33.0, 5.3.0-46-generic, LLVM 10.0.0) OpenGL Core Profile Version: 4.6 (Core Profile) Mesa 20.0.0-devel - padoka PPA ADDITIONAL INFORMATION This happens whether I have 'Animations' (in the 'Image View' settings) set to 'OpenGL', 'Software', or 'None'. Images with an alpha channel are smooth regardless of whether or not the image actually has any transparent (or semi-transparent) pixels. Given the reliance on an alpha channel, I'm going to guess that the image data is getting converted from an array of RGB bytes (each structure being 24 bits wide, and thus not 32-bit aligned) to a 32-bit aligned RGBA array, each pixel being 4 bytes instead of 3 bytes... And this operation is being done every time zooming and panning occurs. I'm guessing that one of either the converted, or the temporary non-converted, version of the pixmap is not being destructed/freed properly. It's also worth mentioning that animated .gif files that have a color reserved for transparent pixels play smoothly and do not cause increased RAM usage over time, while viewing an animated .gif file which does not reserve a color for transparency play back sluggishly and increase RAM usage with each frame that gets displayed. This bug has bothered me for YEARS now. I would have thought it would be reported by now, but I've only seen tangentially related reports (like 'leaks memory in fullscreen mode', 'when viewing lots of files', etc.) when searching for what to follow. Many bugs have reportedly been fixed years ago, but I still see their effects now with current versions, but only with some images - images without alpha channels. I have a feeling that many of the memory leak or slowdown bugs are actually just this one bug dealing with non-alpha-channel images. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 236059] Gwenview: use same sort order as current Dolphin view
https://bugs.kde.org/show_bug.cgi?id=236059 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #12 from Colin Griffith --- I'm affected by this bug as well. I have a lot of image files that are named by their md5 hashes in hexadecimal, and this effectively means that I get names in a seemingly random order in Gwenview only. It's EXTREMELY annoying. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 223937] Scrolling with mouse wheel is too fast in large-icon-sized dialog boxes
https://bugs.kde.org/show_bug.cgi?id=223937 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #4 from Colin Griffith --- (In reply to Nate Graham from comment #3) > Created attachment 118226 [details] > Skeleton patch > > Something like the attached patch should do it. It doesn't work, and I'm not > sure why yet, but it shows the general idea of a fix for this issue. Second to last line of the patch: > const int height = itemView->iconSize().height() + metrics.height() * 2.5; So, you're still including the iconSize().height() in the calculation. Removing that should work, I think. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 406788] Outdated 'cantor-dev' Package
https://bugs.kde.org/show_bug.cgi?id=406788 --- Comment #4 from Colin Griffith --- It's been quite a while since I tried building it. I can't get far enough in the compilation process to determine other dev packages I might be missing. Either way, that's how I noticed that this particular one was outdated. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 406788] Outdated 'cantor-dev' Package
https://bugs.kde.org/show_bug.cgi?id=406788 --- Comment #2 from Colin Griffith --- (In reply to Jonathan Riddell from comment #1) > Why do you need this package? I was attempting to compile the latest version of Labplot2, and it currently seems to want some of the Cantor header files. The specific message it gives is: > src/backend/cantorWorksheet/CantorWorksheet.h:33:10: fatal error: > cantor/session.h: No such file or directory The fact that the CMakeLists.txt file doesn't attempt to locate the Cantor development files first is an entirely separate bug, and since I'm attempting to build from the 'master' branch it's one I don't think requires actually reporting. I'm sure the devs know and just haven't gotten around to it. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 406788] New: Outdated 'cantor-dev' Package
https://bugs.kde.org/show_bug.cgi?id=406788 Bug ID: 406788 Summary: Outdated 'cantor-dev' Package Product: neon Version: unspecified Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Packages User Edition Assignee: neon-b...@kde.org Reporter: tyna...@gmail.com CC: j...@jriddell.org, neon-b...@kde.org, sit...@kde.org Target Milestone: --- The 'cantor' package is at version: 4:19.04.0-0xneon+18.04+bionic+build26 These other versions are available in the repository as well, for downgrading: 4:19.04.0-0xneon+18.04+bionic+build25 4:19.04.0-0xneon+18.04+bionic+build24 4:18.12.3-0xneon+18.04+bionic+build23 However, the repository has ONLY the following version of 'cantor-dev' available: 4:18.12.3-0xneon+18.04+bionic+build23 This means that it cannot be installed without also downgrading all of the Cantor packages. Downgrading all of the Cantor packages is the only workaround I can find, though I haven't really tried much to find other workarounds. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 305072] Animated GIF is some milliseconds too slow
https://bugs.kde.org/show_bug.cgi?id=305072 --- Comment #6 from Colin Griffith --- By the way, by large I mean resolution-wise. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 305072] Animated GIF is some milliseconds too slow
https://bugs.kde.org/show_bug.cgi?id=305072 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #5 from Colin Griffith --- Open a large gif, and Gwenview also skyrockets in RAM usage. It's as if it's keeping every frame in memory, including each loop as new frames it generates instead of reusing them. This is a serious issue. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software
https://bugs.kde.org/show_bug.cgi?id=386379 --- Comment #45 from Colin Griffith --- (In reply to Dāvis from comment #41) > (In reply to Nate Graham from comment #36) > > I think the height of a single line of text might make sense. If that's not > > fast enough by default, we could do two or three. I'll experiment. > > I don't think that's good approach. I've now been thinking about this and I > think scroll speed shouldn't be related to item size at all. For example > even in details view where each item is a line of text I want smooth > scrolling and don't want to scroll by whole row because I might have 72 font > which would make that as a huge jump too. Scrolling should be in device > independent pixels (so taking into account DPI) and it should be user > controllable setting (https://bugreports.qt.io/browse/QTBUG-73467) I'm not completely sure, but it seems like re-examining how KDE applications as a whole calculate scrolling speeds is outside the scope of this specific bug. (In reply to Dāvis from comment #41) > Also by the way, Dolphin isn't only application which does it wrong, this > issue is also present in File dialog. I'm fairly sure that the File dialog, as well as most icon views in other applications (such as Gwenview), just use the code that's within Dolphin. Gwenview's icon browsing mode is also affected, though it seems to scroll in equal increments so that after scrolling the 'new' icons' positions' are the same as the 'old' icons'.. So I'm not entirely sure it's using Dolphin's code. (In reply to Dāvis from comment #41) > Relevant API: > * https://doc.qt.io/qt-5/qabstractitemview.html#verticalScrollMode-prop > * https://doc.qt.io/qt-5/qabstractslider.html#singleStep-prop > > It looks like if we don't set singleStep then Qt default will be used based > on verticalScrollMode. > So I think it always should be ScrollPerPixel with a good default scroll > speed. I'm wondering if it's worth using Qt's defaults or not. I don't know how fast/slow those would be, and I don't have Dolphin's nor KDE's source code downloaded to tinker with.. Though now that I think about it, I probably should go do that real quick to play around with it. (In reply to Dāvis from comment #41) > Also might consider that it could be based on window's size. For example if > I have huge window I can scroll faster because there's so much space so that > I'll still see all items but if window's is very small then I might want to > scroll a lot slower so items don't move out of window too quickly. I would personally hate for it to be based on window size. The whole reason why this bug causes issues for me is because it makes the scroll speed be different for different folders, thus causing the scroll speed to become inconsistent and unpredictable. In my opinion, the more predictable the scrolling is the better - which means use as few variables as possible. I think that optimally it would only use user-configurable variables (such as font size, DPI, and 'number of lines to scroll'), particularly ones that you set numerically and don't expect to change without you explicitly changing them to another specific number. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software
https://bugs.kde.org/show_bug.cgi?id=386379 --- Comment #40 from Colin Griffith --- Ah, durp... I see what you mean now. Yeah, though I think Nate was talking about the size of the 'base' step that's considered 1 'line'. If I knew what the preferred way of querying the line height of the text is, I'd try writing the patch myself. As it is, however, I'm not quite that confident I'd write it in a satisfactory way; I feel like I'd I'd start jumping through hoops and unnecessarily complicating the code simply due to unfamiliarity with what's available in which parts of the API. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software
https://bugs.kde.org/show_bug.cgi?id=386379 --- Comment #38 from Colin Griffith --- Cqoicebordel, the problem is that in Dolphin it doesn't go by lines of text, it counts the number of icons. So in most applications, having that option set to '3' will cause scrolling by 3 lines of text... But in Dolphin it scrolls by the height of 3 icons - and that includes the text under the icon, so folders with long names cause one tick of the scroll wheel to fly the view more than a screen's worth of icons downward/upward at a time. The patch mentioned earlier in this thread makes it so that it uses the height of the shortest icon to determine scroll height, but that doesn't help if you have a folder full of things that are similarly long. And even if all icons have short, one-line names you still end up scrolling by waay more than 3 lines of text worth. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 386379] Dolphin scrolls faster in icon mode than other Qt/KDE software
https://bugs.kde.org/show_bug.cgi?id=386379 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #35 from Colin Griffith --- Ok, I've been reading the code pointed to in comment 18, and started to go off on some weird tangents... And overall I'm not convinced that the actual bug is in any of that code. Instead, I started tracking what code calls THAT code, and I found this: https://lxr.kde.org/source/kde/applications/dolphin/src/kitemviews/kitemlistcontainer.cpp#0264 I'm fairly sure that this is where the decision is made to scroll by the height of an item, and as a result this is the code we need to look toward changing to fix this bug. I've honestly got no clue what to use instead of the item height (I don't know whether it's appropriate to query the currently used Qt style, some KDE setting, or try to access some other member of view), but it appears this is where we need to actually be looking. Really happy I found that. This has been the most annoying bug in KDE for me for quite some time. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 395546] Changes in 5.13 break Firefox CSD with Firefox's built in alternate dark theme (Firefox developer default)
https://bugs.kde.org/show_bug.cgi?id=395546 Colin Griffith changed: What|Removed |Added CC||tyna...@gmail.com --- Comment #5 from Colin Griffith --- Finally found a bug report for this, but I'm surprised nobody has noticed that it's like this for *all* GTK3 applications that use client-side decorations. Try installing something like gnome-characters and you'll see it have the same bug. It also won't change from a dark color to a light color when the window is no longer in focus, instead staying the dark color. -- You are receiving this mail because: You are watching all bug changes.
[LabPlot2] [Bug 390865] Sometimes Crash When Performing Curve Fitting
https://bugs.kde.org/show_bug.cgi?id=390865 --- Comment #12 from Colin Griffith <tyna...@gmail.com> --- The crash still occurs, and is not picked up by DrKonqi despite being a debug build that was installed to the /usr directory (after purging both the copy installed from the repositories, and the version I had built and installed into my home directory). Is there another way to obtain a backtrace? -- You are receiving this mail because: You are watching all bug changes.
[LabPlot2] [Bug 390865] Sometimes Crash When Performing Curve Fitting
https://bugs.kde.org/show_bug.cgi?id=390865 --- Comment #11 from Colin Griffith <tyna...@gmail.com> --- Created attachment 110982 --> https://bugs.kde.org/attachment.cgi?id=110982=edit Fitted Curves in Labplot2 Dashed lines are the fitted curves. -- You are receiving this mail because: You are watching all bug changes.
[LabPlot2] [Bug 390865] Sometimes Crash When Performing Curve Fitting
https://bugs.kde.org/show_bug.cgi?id=390865 --- Comment #10 from Colin Griffith <tyna...@gmail.com> --- (In reply to Alexander Semke from comment #7) > (In reply to Colin Griffith from comment #5) > > In case it's relevant, I suppose I should mention that the data I'm messing > > with is 4401 data points, with X values ranging from 390 to 830, and Y > > values ranging from 0 to 2. Most plots have 3 data sets plotted, and one > > fitting curve for each (so 3 total fitting curves, and 6 curves total). > > Usually I have 2 such data sets, and so 2 plots, making 12 curves total. > > > > The exact data can be downloaded from these pages: > > http://www.cvrl.org/ciepr8dp.htm > > http://www.cvrl.org/ciexyzpr.htm > > > > > > To get the exact data files I'm using, choose these options on the form: > > > > 1st page: 2-degree cone fundamentals in Energy (linear) units with a > > stepsize of 0.1nm, in CSV format. > > > > 2nd page: 2-degree XYZ color matching functions with a stepsize of 0.1nm, in > > CSV format. > > I just tried out the data from the first page. I have no problems to plot > and to fit to those three Gauss curves. I attached the screenshot of the > results. The curves with the filled areas are the fitted results. > > To get this data quickly fitted in LabPlot: > 1. import the csv file into a spreadsheet, use preview tab to check the > results of the import settings > 2. do a right click in the spreadsheet and select "Plot data" from the > context menu and plot three curves in one single plot > 3. do a right click on the curve (either in the plot or in the project > explorer) and select Analysis/Fit/Gauss from the context menu > 4. we fail to guess good starting values at the moment, so just provide a > reasonable mean value for \mu and recalcute again. This is consistent with my testing. However, I've been using curves with 3 - 8 peaks, attempting to visually match the fitted curve precisely to the actual data so that without zooming in they appear to be 100% identical. It is while repeatedly calculating the curves and tweaking the resulting values that the crash occurs, and continues to occur. I'll attach a screenshot of what I managed to get as far as results go yesterday, but have not been able to get the 'L' curve to fit any better (theoretically I should be able to get it to fit as well as the 'M' curve, but the algorithms refuse to behave rationally in some cases). All three curves are fit with 5 peaks. Either way, my troubles with fitting the curves are not the topic of this bug, but rather the fact that the program crashes after simply changing some values over and over. I don't believe that should happen. Also, I had already built Labplot with debugging symbols, but I'm now in the process of rebuilding it for installation in '/usr'. -- You are receiving this mail because: You are watching all bug changes.
[LabPlot2] [Bug 390865] Sometimes Crash When Performing Curve Fitting
https://bugs.kde.org/show_bug.cgi?id=390865 --- Comment #5 from Colin Griffith <tyna...@gmail.com> --- In case it's relevant, I suppose I should mention that the data I'm messing with is 4401 data points, with X values ranging from 390 to 830, and Y values ranging from 0 to 2. Most plots have 3 data sets plotted, and one fitting curve for each (so 3 total fitting curves, and 6 curves total). Usually I have 2 such data sets, and so 2 plots, making 12 curves total. The exact data can be downloaded from these pages: http://www.cvrl.org/ciepr8dp.htm http://www.cvrl.org/ciexyzpr.htm To get the exact data files I'm using, choose these options on the form: 1st page: 2-degree cone fundamentals in Energy (linear) units with a stepsize of 0.1nm, in CSV format. 2nd page: 2-degree XYZ color matching functions with a stepsize of 0.1nm, in CSV format. -- You are receiving this mail because: You are watching all bug changes.
[LabPlot2] [Bug 390865] Sometimes Crash When Performing Curve Fitting
https://bugs.kde.org/show_bug.cgi?id=390865 --- Comment #4 from Colin Griffith <tyna...@gmail.com> --- (In reply to Alexander Semke from comment #3) > (In reply to Colin Griffith from comment #2) > > I don't think I have all the packages necessary to compile Labplot, but I > > can probably try installing them and doing so. The 'INSTALL' file seems to > > include all the info I'll need for that :) > Yes, once the dependencies are installed it should be pretty > straight-forward to compile LabPlot. Don't forget to do 'make install' in > the build folder. If you have any problems or questions, please reach out to > us. I have it compiled, but it isn't being picked up by DrKonqi when it crashes. Repeating a crash is rather difficult, so I just have to mess around with it until it happens again. I have it installed into a directory in my home folder, with $PATH and $XDG_DATA_DIRS modified to reflect the location. Specifically, I have this in my .profile: PATH="/home/tynach/Software/compiled/bin:$PATH" XDG_DATA_DIRS="/home/tynach/Software/compiled/share:$XDG_DATA_DIRS" Without modifying $XDG_DATA_DIRS, the program would mostly run but crash more frequently (and complain about files missing on startup; honestly, the warning that popped up is what led me to knowing that I needed to to begin with, and I was very appreciative of that). I suppose now I should compile it using /usr as the installation prefix, and uninstall the version of Labplot from the repositories... Or do you have a different recommendation? -- You are receiving this mail because: You are watching all bug changes.
[LabPlot2] [Bug 390865] Sometimes Crash When Performing Curve Fitting
https://bugs.kde.org/show_bug.cgi?id=390865 --- Comment #2 from Colin Griffith <tyna...@gmail.com> --- (In reply to Alexander Semke from comment #1) > (In reply to Colin Griffith from comment #0) > > Application: labplot2 (2.4.0) > > > > Qt Version: 5.9.3 > > Frameworks Version: 5.43.0 > > Operating System: Linux 4.13.0-32-generic x86_64 > > Distribution: KDE neon User Edition 5.12 > > > > -- Information about the crash: > > I was repeatedly performing curve fitting with multi-peak Gaussian curves. > > The algorithm for determining best fit doesn't work very well, so I have to > > manually adjust values to be sorta close and then it seems to work. > > > > Sometimes, however, it just crashes when I finish editing the curve > > parameters and apply them. I sadly cannot remember now if it crashed when I > > hit 'Apply', or if it crashed when I clicked the button to recalculate the > > curves. > The call stack you attached indicates that you changed the "auto precision" > options in the properties widget for an axis. This part was reworked a bit > recently and should be safe already. > > > > > There are a number of oddities to the version of Labplot2 in the Neon > > repositories, though. It reports itself as version 2.4, but has a feature > > that the website claims will be new in 2.5 (setting lower/upper limits on > > curve fitting parameters). > We changed the version a bit late during the development of 2.5. Looks like > Neon picked out the code of 2.5 in development but with the version still > set to 2.4. The current code in the repository has the version set to 2.5 - > we're preparing the next release right now. Does Neon provides a more recent > version of LabPlot or do you have any chance to compile it from sources? The > fitting functionality was greatly extended for 2.5 and any kind of feedback > and additional testing would be great here. Thanks! As far as I'm aware, I'm on the latest version of Labplot that KDE Neon has packages for. I paused while typing this just to double check, and indeed there are no new updates. I don't think I have all the packages necessary to compile Labplot, but I can probably try installing them and doing so. The 'INSTALL' file seems to include all the info I'll need for that :) It's getting rather late, so I'll probably do this tomorrow morning. Glad to know the odd package version isn't MY fault :) Hopefully this is why CAS worksheets are broken too... But that'd be a completely different bug report. -- You are receiving this mail because: You are watching all bug changes.
[LabPlot2] [Bug 390865] New: Sometimes Crash When Performing Curve Fitting
https://bugs.kde.org/show_bug.cgi?id=390865 Bug ID: 390865 Summary: Sometimes Crash When Performing Curve Fitting Product: LabPlot2 Version: 2.4.0 Platform: Neon Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: normal Priority: NOR Component: general Assignee: alexander.se...@web.de Reporter: tyna...@gmail.com Target Milestone: --- Application: labplot2 (2.4.0) Qt Version: 5.9.3 Frameworks Version: 5.43.0 Operating System: Linux 4.13.0-32-generic x86_64 Distribution: KDE neon User Edition 5.12 -- Information about the crash: I was repeatedly performing curve fitting with multi-peak Gaussian curves. The algorithm for determining best fit doesn't work very well, so I have to manually adjust values to be sorta close and then it seems to work. Sometimes, however, it just crashes when I finish editing the curve parameters and apply them. I sadly cannot remember now if it crashed when I hit 'Apply', or if it crashed when I clicked the button to recalculate the curves. There are a number of oddities to the version of Labplot2 in the Neon repositories, though. It reports itself as version 2.4, but has a feature that the website claims will be new in 2.5 (setting lower/upper limits on curve fitting parameters). I am using the 'User Edition' of KDE Neon, installed somewhat shortly before Plasma 5.12 was released. I remember people saying that the LTS User Edition got the 5.12 update sooner than the 'regular' User Edition, but now there is only a single User Edition on the website - so I do not know how relevant this information might be. The crash can be reproduced sometimes. -- Backtrace: Application: labplot2 (labplot2), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f0dcb13e940 (LWP 3464))] Thread 9 (Thread 0x7f0d9506f700 (LWP 3474)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #2 0x7f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #3 0x7f0dbf1bf6ba in start_thread (arg=0x7f0d9506f700) at pthread_create.c:333 #4 0x7f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 8 (Thread 0x7f0d95870700 (LWP 3473)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #2 0x7f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #3 0x7f0dbf1bf6ba in start_thread (arg=0x7f0d95870700) at pthread_create.c:333 #4 0x7f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 7 (Thread 0x7f0d96071700 (LWP 3472)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #2 0x7f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #3 0x7f0dbf1bf6ba in start_thread (arg=0x7f0d96071700) at pthread_create.c:333 #4 0x7f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 6 (Thread 0x7f0d96872700 (LWP 3471)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #2 0x7f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #3 0x7f0dbf1bf6ba in start_thread (arg=0x7f0d96872700) at pthread_create.c:333 #4 0x7f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 5 (Thread 0x7f0d97073700 (LWP 3470)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #2 0x7f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #3 0x7f0dbf1bf6ba in start_thread (arg=0x7f0d97073700) at pthread_create.c:333 #4 0x7f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7f0d97874700 (LWP 3469)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f0d9d1ae3cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #2 0x7f0d9d1ae2e8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #3 0x7f0dbf1bf6ba in start_thread (arg=0x7f0d97874700) at pthread_create.c:333 #4 0x7f0dc240841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 3 (Thread 0x7f0d987dd700 (LWP 3468)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1
