[plasma-pa] [Bug 442379] When using Natural Scrolling, scrolling direction to change volume is inverted
https://bugs.kde.org/show_bug.cgi?id=442379 --- Comment #13 from Hector Martin --- > I find the new behaviour quite unnatural after using it the way it was for so > long. That sounds like "I got used to the old way even though it didn't make sense", which isn't a terribly good reason not to fix it. :) > Also since the sliders are perpendicular to the direction of motion, I don't > believe there really is a "correct" way for them to respond. Other systems > have likely preferred to keep their audio sliders vertical for this same > reason. If you're implying that for a vertical volume slider then "scroll up" on a trackpad should in fact be volume up (i.e. the current behavior after this bug was fixed) *then* it stands to reason that the same should be true for a horizontal slider as, despite there being no "correct" spatial mapping due to the axis being different, the "volume up" metaphor still holds. Indeed, this same rationale applies to non-spatial cases like the Plasma system tray volume icon itself, which simply displays a varying number of "waves". In general, non-scrollbar linear widgets on desktop environments (and, indeed, largely so in the physical world) have always used the "positive right / up" convention, so it stands to reason that they would be mapped this way. That said, I just noticed that horizontal sliders and indeed the tray icon itself *also* respond to horizontal trackpad movement, which is also excellent as it matches the direction of the slider. As I said in my earlier comment, the only reason we ended up in this mess to begin with is because scroll wheels were *specifically* intended for the use case of viewport scrolling first (which is inverted vs. the content), then widgets have always tried to use "natural scrolling" by inverting the scroll direction at the widget level, and then finally "natural scrolling" for trackpads was originally implemented as a hack that inverted all scrolling regardless of scroll target, making the widgets move backwards unintentionally. People might have gotten used to that, but I really doubt there is a strong argument to be made that this behavior is, in any way, intuitive. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 434486] Powerdevil bug killing my bluetooth?
https://bugs.kde.org/show_bug.cgi?id=434486 hector acosta changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|WORKSFORME |--- CC||hector.aco...@gmail.com --- Comment #2 from hector acosta --- (In reply to Nate Graham from comment #1) > Is this still happening in Plasma 5.27 with a newer kernel? I can confirm this is still happening in plasma 5.27.9 and kernel 6.5.13 -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 476187] OpenH264 codec support
https://bugs.kde.org/show_bug.cgi?id=476187 --- Comment #4 from Hector Martin --- Considering it also only lists CBP for *decoding* and yet it can obviously decode higher profiles (otherwise it would be useless for the web), I think that feature list is clearly not exhaustive. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 477283] System settings marks all "*.utf8" locales as invalid/unsupported, and glibc does not expose "*.UTF-8" variants
https://bugs.kde.org/show_bug.cgi?id=477283 Hector Martin changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- CC||mar...@marcan.st --- Comment #2 from Hector Martin --- Yes, UTF-8 works (not utf8, not utf-8, not UTF8). -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 476186] Screen recording quality is terrible
https://bugs.kde.org/show_bug.cgi?id=476186 --- Comment #3 from Hector Martin --- I am in fact (150%), but the bad quality looks like compression artifacts, so it shouldn't be related to scaling/resolution, but rather a codec issue. It also happens when recording the full screen. @Noah yes, with fine detail like lots of text (especially colored) it falls apart. Looking at the printed config, `rc_end_usage` is 0 which means VBR, which is the same problem as libx264: you are telling the decoder to target a specific bitrate regardless of picture complexity, so if things get too complex, the whole thing becomes a blockfest since it's physically impossible to encode in that few bits. Screen recording *really* needs constant quality mode to be useful for offline recording (not streaming where you have constraints). -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 475472] Spectacle fails to record a window with h264 in specific dimensions
https://bugs.kde.org/show_bug.cgi?id=475472 --- Comment #5 from Hector Martin --- Yes, 4:2:0 should be the default since a lot of decoders choke on 4:4:4 too. If offered, 4:4:4 should be an explicit opt-in for users that know their use case will handle it. -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 475472] Spectacle fails to record a window with h264 in specific dimensions
https://bugs.kde.org/show_bug.cgi?id=475472 Hector Martin changed: What|Removed |Added Version|23.08.1 |unspecified CC||aleix...@kde.org Component|General |general Product|Spectacle |KPipeWire Assignee|noaha...@gmail.com |plasma-b...@kde.org --- Comment #3 from Hector Martin --- Reassigning to KPipeWire since I'm pretty sure that's where this should be handled. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 475472] Spectacle fails to record a window with h264 in specific dimensions
https://bugs.kde.org/show_bug.cgi?id=475472 --- Comment #2 from Hector Martin --- * I meant also width there, not height (which is what the OP reported). -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 476187] New: OpenH264 codec support
https://bugs.kde.org/show_bug.cgi?id=476187 Bug ID: 476187 Summary: OpenH264 codec support Classification: Frameworks and Libraries Product: KPipeWire Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: mar...@marcan.st CC: aleix...@kde.org Target Milestone: --- KPipeWire currently only supports software h.264 encoding via libx264. libx264 cannot be safely distributed by default in countries with restrictive software patent legislation. OpenH264 is an open source h.264 encoder distributed by Cisco, making use of their H.264 license (https://www.openh264.org/). It allows distributions like Fedora to support h.264 without much fuss, and in particular for the Fedora Asahi Remix we have hooked it up to be installed automatically, so H.264 works out of the box in most apps. Since KPipeWire uses libavcodec, and libavcodec has openh264 integration, it should be pretty easy to generalize the code to not explicitly hardcode libx264 but rather allow openh264 as well. The codec name in this case is `libopenh264`. Quality controls have to be validated to make sure they work well on both codecs (see bug 476186 for the story on libx264, I don't know off the top of my head what the appropriate quality controls are for openh264 but I can investigate). Where libx264 is available, it should be preferred, since x264 is widely considered to be the best h.264 encoder in the world and particularly well optimized. In the future there will be more h.264 encoder options, e.g. for Fedora Asahi we plan to expose the internal hardware encoder as a h264_v4l2m2m implementation. This is also supported by ffmpeg. So it might be worth setting things up so that, at the very least as a fallback, "any codec that can encode h.264" is selected. I believe this should be possible with ffmpeg by requesting the `h264` codec and letting it pick an appropriate encoder. That will make h.264 encoding at least work (if perhaps without ideal quality control) on any machine that has a usable codec, without explicitly handling them all in KPipeWire. -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 476186] New: Screen recording quality is terrible
https://bugs.kde.org/show_bug.cgi?id=476186 Bug ID: 476186 Summary: Screen recording quality is terrible Classification: Frameworks and Libraries Product: KPipeWire Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: mar...@marcan.st CC: aleix...@kde.org Target Milestone: --- Screen recording quality in Spectacle is bad to the point of being unusable for anything more than casual use. Selecting quality is a codec, specific issue, but for x264 in particular, the current code is very questionable: https://invent.kde.org/plasma/kpipewire/-/blob/master/src/libx264encoder.cpp This sets `m_avCodecContext->global_quality` from some weird formula, but it's unclear how that maps to encoder settings in the end within ffmpeg. What I see in the resulting files is that Average Bitrate mode is being used (rc=abr), with bitrate somehow varying based on dimensions. This is a very bad choice for x264. The correct "just give me a given quality please" mode in x264 is CRF (constant rate factor) mode, which does not force any given bitrate but rather targets a specific visual quality. If the quality settings are not configurable (or not configurable beyond a simple quality slider), then that mode should be the default to give decent output without more fuss. CRF mode is resolution-independent, and will automatically scale bitrate depending on the requirements (video size, motion complexity, etc.). It's the best option to default to for most users. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 475472] Spectacle fails to record a window with h264 in specific dimensions
https://bugs.kde.org/show_bug.cgi?id=475472 Hector Martin changed: What|Removed |Added Ever confirmed|0 |1 CC||mar...@marcan.st Status|REPORTED|CONFIRMED --- Comment #1 from Hector Martin --- It also fails if the height is not divisible by 2. This is a KPipeWire bug. It needs to pad dimensions to an even value. This is required by most codecs due to color subsampling (unless you use 4:4:4 mode, which should probably be offered for screen recording anyway). -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 475435] New: default system keyboard model is not correctly set on Wayland
https://bugs.kde.org/show_bug.cgi?id=475435 Bug ID: 475435 Summary: default system keyboard model is not correctly set on Wayland Classification: Applications Product: systemsettings Version: 5.27.8 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_keyboard Assignee: plasma-b...@kde.org Reporter: mar...@marcan.st CC: butir...@gmail.com Target Milestone: --- On a fresh user account, the keyboard layout is set by default to the value configured in `localectl`. However, the keyboard model is not, and ends up at "Generic 101-key PC". This matters particularly for Apple machines (on Asahi Linux), where we strive to set the default keyboard model systemwide properly since the Apple models have subtle but important changes vs the standard layouts. STEPS TO REPRODUCE 1. localectl set-x11-keymap jp applealu_jis 2. Create a fresh user account and log in 3. Go into kcm_keyboard OBSERVED RESULT Keyboard model is listed as "Generic 101-key PC" and behaves as such. EXPECTED RESULT Keyboard model should be "Apple Aluminum (JIS)". SOFTWARE/OS VERSIONS Operating System: Fedora Linux Asahi Remix 39 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.6-400.asahi.fc39.aarch64+16k (64-bit) Graphics Platform: Wayland Processors: 8 × Apple Firestorm (M1 Pro), 2 × Apple Icestorm (M1 Pro) Memory: 30.6 GiB of RAM Graphics Processor: Apple M1 Pro Product Name: Apple MacBook Pro (14-inch, M1 Pro, 2021) U-Boot Version: 2023.07 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 465891] Square artifacts following cursor on some UI elements
https://bugs.kde.org/show_bug.cgi?id=465891 Hector Martin changed: What|Removed |Added CC||vlad.zahorod...@kde.org --- Comment #5 from Hector Martin --- Adding Vlad to Cc since he might know more about what's going on, given his involvement with Bug 465158 and Bug 455526 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 465891] Square artifacts following cursor on some UI elements
https://bugs.kde.org/show_bug.cgi?id=465891 Hector Martin changed: What|Removed |Added CC||mar...@marcan.st --- Comment #4 from Hector Martin --- Interestingly, it looks like this one isn't specifically about blur (which got fixed recently). This happens with blur disabled too, if you kill plasmashell. Steps to reproduce: - Set scale to 150% (or anything non integer) - Open some apps (e.g. konsole, systemsettings) - killall plasmashell - (optional) `swaybg -o '*' -i /usr/share/backgrounds/default.png` (or whatever image) to put up a background (makes the problem more obvious) - Move the mouse and windows around (force software cursors to make it more obvious if your driver supports hardware cursors) You'll see black single pixel trails around the cursor and window edges on the swaybg wallpaper and some window contents, but not all. E.g. the glitches seem to appear on most of the Konsole window, but on System Settings only the window decorations are affected. This happens with the blur effect completely disabled. AIUI the blur glitch was about the blurring itself being computed wrong. This one looks like a different problem, related to dirty rectangle/redraw tracking. KDE Plasma Version: 5.27.7 (wayland) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455526] Blur glitches started to appear in wayland again
https://bugs.kde.org/show_bug.cgi?id=455526 --- Comment #37 from Hector Martin --- Hmm, it looks like whatever was done to 5.27.7 to fix the non-integer scale redraw artifacts (which was another major issue) also fixed or significantly improved blur? I can't reproduce the kind of horrible glitching 5.27.6 had any more. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455526] Blur glitches started to appear in wayland again
https://bugs.kde.org/show_bug.cgi?id=455526 Hector Martin changed: What|Removed |Added CC||mar...@marcan.st --- Comment #32 from Hector Martin --- Can we disable blur in KWin by default until this is fixed? Having no blur by default is a lot better than having out-of-the-box Plasma installs glitch like crazy on the task bar and other contexts on some systems. We already disable blur by default in Asahi Linux for this reason, and we're likely going to get that default pushed into the Fedora KDE configs too. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 428424] Open Laptop Lid doesn't turn on Display (Wayland)
https://bugs.kde.org/show_bug.cgi?id=428424 Hector Martin changed: What|Removed |Added CC||mar...@marcan.st --- Comment #18 from Hector Martin --- Are we conflating two issues here? What I see on Apple Silicon machines is that KDE is configured to *suspend* on lid close (or you manually suspend it prior to closing the lid) then indeed it wakes up and turns the screen on when you open the lid. However, if it is configured to *turn off the screen* on lid close, the screen doesn't turn on when you open it until you press a key. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 442379] When using Natural Scrolling, scrolling direction to change volume is inverted
https://bugs.kde.org/show_bug.cgi?id=442379
--- Comment #8 from Hector Martin ---
(In reply to paul from comment #6)
> As a user of natural/inverted scrolling for years, I would argue that this
> is not actually a bug, but working as expected. "Invert scrolling" means
> invert it _everywhere_, including the volume applet.
> It also makes more sense if you picture a vertical volume slider (with 100%
> volume at the top) with a handle that works the same as any other scroll
> bar: you do scrollwheel-UP to push that handle down (i.e. lower volume) and
> vice versa.
It makes no sense on a touchpad. "Natural scrolling" on a touchpad means you
drag window content in the direction you want it to go. That happens to be the
opposite of the old default for scrolling windows, but not for sliders and
volume controls. Right now, enabling natural scrolling means you scroll down to
turn the volume up, which makes no sense. There is no "wheel" metaphor to make
an inverted direction ever make sense like there is on a mouse.
Ultimately, the root cause of all this confusion is that when people first
defined wheel scrolling for window content, they did so based on
*viewport/scrollbar movement* ("scroll down" means "look down" which means
"move the content up"). But that is not the case for any other context in which
the scroll wheel is used, where down and up are directly mapped. "Invert
scrolling" and "Natural scrolling" are therefore not, really, the same concept.
"Invert" might be expected to "invert everything" under some interpretations,
but there is nothing natural about that. What people naturally expect from
"Natural scrolling" is that window content scrolling flips from
viewport-centric to content-centric, and nothing else.
--
You are receiving this mail because:
You are watching all bug changes.
[plasma-pa] [Bug 442379] When using Natural Scrolling, scrolling direction to change volume is inverted
https://bugs.kde.org/show_bug.cgi?id=442379 Hector Martin changed: What|Removed |Added CC||mar...@marcan.st --- Comment #7 from Hector Martin --- See also #442789, since this issue affects basically all non-scroll window actions as far as I can tell (sliders, etc). -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 450551] Battery charge limit is not preserved after reboot on ASUS (and ThinkPad) laptops supporting charge limits; need to write it on every boot
https://bugs.kde.org/show_bug.cgi?id=450551 Hector Martin changed: What|Removed |Added CC||mar...@marcan.st --- Comment #30 from Hector Martin --- FYI, this is the case on Apple laptops too. They actually don't support charge thresholds at all, just a charge behavior toggle (inhibit charge/not), and the OS is supposed to do the rest. We'll be emulating the thresholds in the kernel (for the convenience of userspace and because that means we can make them work in s2idle sleep). There is no flash memory to store any of these settings, so the OS has to re-set them on every boot. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 444029] Disable keyboard backlight on laptop lid close
https://bugs.kde.org/show_bug.cgi?id=444029 Hector Martin changed: What|Removed |Added CC||mar...@marcan.st --- Comment #3 from Hector Martin --- This is a major power management bug, as leaving the keyboard backlight on while the laptop is closed wastes significant battery power. On An Apple M1 MacBook Air, having the backlight on at full brightness with the lid closed causes a 40% (!) drop in idle battery life (from 28 hours to 17 hours, measured with an idle KDE Plasma session with the lid closed and the latest linux-asahi-edge kernel). It's "just an LED backlight", but the impact is *massive* on machines with good power management like Apple Silicon Macs. I recommend increasing the priority, as this really isn't "wishlist" for some machines, it's critical functionality. I'm sure it matters less for machines that chew through batteries even while doing nothing, but not all do :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461660] Bug at startup
https://bugs.kde.org/show_bug.cgi?id=461660 Hector changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #1 from Hector --- A week has passed. I remembered about my report. Now I can't repeat this bug in any builds. Maybe it's related to something else. So you can close it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461660] New: Bug at startup
https://bugs.kde.org/show_bug.cgi?id=461660 Bug ID: 461660 Summary: Bug at startup Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- I'm not good at describing bugs by all the rules, sorry. In the night builds, I noticed that sometimes Krita does not start the first time. It turned out that the process starts, but freezes in some kind of cycle. Consumes CPU power, but takes up less than 30 MB of RAM. At the same time, I can start more processes with Krita, which will load as expected. But the first process will consume CPU power. I have it about 15-20%. And I also noticed that nightly version takes longer to process "loading resource type" during startup. I tried to delete resourcecache, but I didn't notice any difference. Windows 10 (21h2, 22h2). Only in Krita Nightly. An oldest one I have is from October 3, so i dont know since... Build from October 10 works the same way. Krita is not installed. Only portable from binary-factory. -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 363333] Processes started in yakuake terminals block indefinitely some time after switching to a different VT
https://bugs.kde.org/show_bug.cgi?id=36 Hector Martin changed: What|Removed |Added CC||hec...@marcansoft.com --- Comment #8 from Hector Martin --- This also affects Konsole. Switching to another VT hangs processes that are producing output, even if Konsole is minimized or the active tab is not the one producing output. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 458557] New: Composition overlays do not extend to the length of the video when dragged and dropped.
https://bugs.kde.org/show_bug.cgi?id=458557 Bug ID: 458557 Summary: Composition overlays do not extend to the length of the video when dragged and dropped. Product: kdenlive Version: 22.08.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: Effects & Transitions Assignee: vpi...@kde.org Reporter: bkast1...@gmail.com Target Milestone: --- Created attachment 151738 --> https://bugs.kde.org/attachment.cgi?id=151738=edit default size image Not a crash, just a "feature" that used to be present in older versions. The behavior in new versions i.e. 22.08.0 is erratic with some composition overlays expanding such as with -> right click -> add composition, but others from the composition menu not expanding upon placement. When dragged and dropped from the composition menu, the default "band" overlay is defaults to a tiny (horizontal) size that is almost useless, and you can't even change it's size without zooming in by miles. I hold that the best behavior is to expand the band upon drag and drop and if a smaller band is required it could be controlled by clipping or resizing. Maybe a config setting can adjust this default behavior if other people have other experiences during editing. STEPS TO REPRODUCE Have two videos, drag a composition between them from the composition menu. Upon placement, it will be nano-scale in size. OBSERVED RESULT During high-speed workflow editing. It's a game-changer no to have to zoom in by five hundred miles to resize the overlay band manually each and every time when using compositions. EXPECTED RESULT Older versions did not have this discrepancy. SOFTWARE/OS VERSIONS Windows: 10 Qt Version: 5.15.5 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 453545] Konsole resets font size after disconnecting from SSH session
https://bugs.kde.org/show_bug.cgi?id=453545 --- Comment #9 from Hector Martin --- Another workaround is to make the actual command running not be ssh, so konsole can't see it. For example, you could alias ssh to be `/usr/bin/time ssh`, that should stop konsole from picking it up. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 453545] Konsole resets font size after disconnecting from SSH session
https://bugs.kde.org/show_bug.cgi?id=453545 Hector Martin changed: What|Removed |Added CC||hec...@marcansoft.com --- Comment #8 from Hector Martin --- Easy quick fix: `sudo rm /usr/lib64/qt5/plugins/konsoleplugins/konsole_sshmanagerplugin.so`. This is all caused by the new fancypants SSH manager plugin, but inexplicably there is no UI for enabling/disabling plugins. So if you don't use it, just nuke the file (of course, it will come back on package upgrades, but it beats living with text size resets all day). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 454599] New: Feature request: perspective concentric ellipse
https://bugs.kde.org/show_bug.cgi?id=454599 Bug ID: 454599 Summary: Feature request: perspective concentric ellipse Product: krita Version: unspecified Platform: unspecified OS: Unspecified Status: REPORTED Severity: wishlist Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- Greetings. I am the author of the last topic on the request of a perspective ellipse. I did not correctly describe how it should work in theory. In the context of algorithms and formulas. But in the end, you did everything right. And I'm very happy about it. There is one detail left. I apparently completely forgot to mention it in previews request. Here we need a second tool, where the ellipse will be the concentric. As already existing without perspective. Called Concentric Ellipse I don't know if you are aware of this, if you planned it. I just wrote a request. And yes. It's my own fault for not posting this in the previous thread. Actually... In drawing only the Perspective Concentric Ellipse is important. Previews: https://bugs.kde.org/show_bug.cgi?id=405643 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 454034] "Allow Color Filters" feature is poorly named, surprising and unintuitive
https://bugs.kde.org/show_bug.cgi?id=454034 --- Comment #3 from Hector Martin --- Keep in mind that the confusing setting name was only the last 15 minutes spent on the issue. I spent months wondering what the colored squares were about in the first place. It would be helpful to also add a caption to the previews, as I mentioned. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 454034] New: "Allow Color Filters" feature is poorly named, surprising and unintuitive
https://bugs.kde.org/show_bug.cgi?id=454034 Bug ID: 454034 Summary: "Allow Color Filters" feature is poorly named, surprising and unintuitive Product: konsole Version: 21.12.3 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: hec...@marcansoft.com Target Milestone: --- SUMMARY I've been wondering for months why I sometimes got random colored squares, usually near my Plasma taskbar, that would disappear as soon as I moved the mouse. I just found out it's a Konsole feature today. STEPS TO REPRODUCE 1. Use Konsole with defaults 2. Notice random colored squares appear with no rhyme nor reason 3. Be confused for months 4. Eventually put two and two together and realize it's previewing color names on hover. 5. Spend 15 minutes looking for the option to turn it off OBSERVED RESULT Frustration EXPECTED RESULT It should take 2 seconds to understand the feature (and that it is one) and less than a minute to figure out how to turn it off. ADDITIONAL INFORMATION May I suggest: - Adding a caption/title to the tooltip, something like "Color preview", to make it clear it's intentional and not, say, a broken window thumbnail, which is what it looked like to me at first - Renaming the setting to something like "Show color preview tooltips" "Preview color names on hover". I had to literally hover over every setting and read the explanations to find it. I have no idea what a "color filter" is or why I would or wouldn't "allow" it. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 364321] Ability to switch from JEDEC to SI units
https://bugs.kde.org/show_bug.cgi?id=364321 --- Comment #22 from Hector Martin --- The UI was there in KDE4. It was lost in KDE5. Do you have a reference as to why it was removed? When 57240 was closed, there was no UI and no intent to add an UI. A UI was later added anyway. Clearly someone thought it was important. If it was deliberately removed, that action is not documented in 57240, since it predates the addition of the UI entirely. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 364321] Ability to switch from JEDEC to SI units
https://bugs.kde.org/show_bug.cgi?id=364321 Hector Martin changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED --- Comment #20 from Hector Martin --- The good news is that manually fiddling with the config, as in bug 57240, does indeed still work and lets you get real SI units. Great! The bad news is that bug predates the existence of the UI in KDE 4.x, and this bug is a *regression* since the UI did exist at a later point and subsequently disappeared. So this isn't a duplicate, since it's a regression. If you can find documentation that the subsequent removal of the UI was intentional and it will not be restored, that would make this bug a WONTFIX, not a DUPLICATE. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405643] Feature request: circle in a square assistant tool
https://bugs.kde.org/show_bug.cgi?id=405643 --- Comment #7 from Hector --- (In reply to Srirupa Datta from comment #6) > anyone available to mentor this project? I am not a mentor, but i can be your tester for this. If you need -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 364321] Ability to switch from JEDEC to SI units
https://bugs.kde.org/show_bug.cgi?id=364321 --- Comment #14 from Hector Martin --- Of course JEDEC would use the binary definition; their entire business is basically RAM and Flash specifications. They are basically the only organization with a reason to prefer binary powers of 2, as they define specs for the only hardware where that still is useful in any way :-) But yes, this should be configurable; I don't think we're ever going to convince everyone of our way being the Right Way and we shouldn't need to. One of the reasons to use KDE is its configurability. That said, ever since people started talking calling 1440 KiB floppies "1.44 MB" (which is incorrect regardless of what definition of MB you use) the problem with binary units has been evident. Nobody can do power of two math in their head properly. The only significant argument for binary units is tradition/historical reasons (or being compatible with Windows). The thing is, they made sense when storage capacities were small enough that they were small multiples of the unit size (i.e. sector size, usually a small power of 2) since then you end up with "nice" numbers in binary units. But once your capacity is more than 4 or 5 orders of magnitude larger than the base unit (>1 prefix), this stops making any sense because capacities are not themselves powers of two and you're not going to get nice round numbers no matter what. I'm not going to make a big deal about binary units being the default if it ends up like that, but I do think the average user is better served by power of 10 prefixes (and those who prefer power of two prefixes can definitely go and change the setting). Either way it should be a setting. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 364321] Ability to switch from JEDEC to SI units
https://bugs.kde.org/show_bug.cgi?id=364321 Hector Martin changed: What|Removed |Added CC||hec...@marcansoft.com --- Comment #12 from Hector Martin --- Yeah, it seems very silly that this regressed in KF5; SI units are a lot more natural, are what storage media is marketed as, and also match data transfer rates (a 1MB file takes 1 second to transfer at 8Mbps or 1MB/s). This should absolutely be configurable, and I would go as far as saying SI units should be the default. Power of two storage sizes have no useful meaning; beyond sector/block sizes there is no power of two pattern. The only common quantities that are still measured in powers of two are RAM sizes, and the only use case for cross-referencing RAM sizes to file sizes is for things like VM suspend RAM images. That's it. (And I say this as someone who tinkers with hardware and kernels and deals with things like 8 MiB Flash images all the time - I couldn't care less that those are shown as 8.4 MB in directory listings. I know how to round down.) -- You are receiving this mail because: You are watching all bug changes.
[kopete] [Bug 320327] Cannot create more than one Jabber account with the same JID/AccountId
https://bugs.kde.org/show_bug.cgi?id=320327 --- Comment #3 from Hector Martin --- I haven't used Kopete in many years, so feel free to close this bug (I don't know what close reason is appropriate in these cases). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427376] Gradient map filter layer very slow. Maybe only for windows.
https://bugs.kde.org/show_bug.cgi?id=427376 --- Comment #2 from Hector --- Testing Build #1138 (Nov 2, 2020 8:18:00 AM) https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/1138/ The same setting. 2000 x 2000, 8 bit. I choose a gradient in the filter layer. Now it takes ~3 seconds for a complete calculation. No lags, no freezes. The filter mask in the group is faster than the filter layer. There is still no real time. but turns on and off very quickly. The Gradient Map Brush(filter brush engine) is now freezing the app. The performance has improved. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427376] Gradient map filter layer very slow. Maybe only for windows.
https://bugs.kde.org/show_bug.cgi?id=427376 --- Comment #1 from Hector --- I have a 2000 x 2000, 8-bit layer. I click on add a layer filter with a gradient map already set. It starts to calculate the default gradient (forground to transparency). In beta2 on Windows, it takes 13.5 seconds to fully update the preview. On a Linux virtual machine 4 sec. After I can draw on a Linux virtual machine and the colors are immediately updated. In 16-bit, on Windows 1 min 15 sec. On Linux virtual machine 30 sec -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427376] New: Gradient map filter layer very slow. Maybe only for windows.
https://bugs.kde.org/show_bug.cgi?id=427376 Bug ID: 427376 Summary: Gradient map filter layer very slow. Maybe only for windows. Product: krita Version: 4.4.0-beta2 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Filter Layers Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- I have fx 8350 and rx 560. Windows 10 pro 64-bit. Usually I use Krita plus, but now I checked it on different versions. I have a very bad gradient map. In 8-bit it is tolerable, but in 16-bit it takes too long. What it looks like. I am creating a filter layer. Nothing happens. i choose a gradient. Nothing. I can't press anything in Krita either. After a couple of minutes, the result of the first gradient begins to be shown, which opens by default (foreground color to transparency). And only after its complete processing, the calculation of the second selected gradient begins. Color space is not affected. 8-bit or 16-bit, yes very much. Direct3d and opengl seem to work the same way. The filter layer in the group gets even slower. The filter brush with gradient map doesn't work well either. But I do remember that when I experimented with the brush filter before, it worked quickly. Perhaps this is something with Windows. I checked on a linux VM. (mint mate) And there it works. In 16-bit it is still slow, but in 8-bit I can draw in real time. In the virtual machine! So what else do I need to check? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 409613] "Reset Canvas Rotation" set to "Space + R" breaks color picking after pan action
https://bugs.kde.org/show_bug.cgi?id=409613 --- Comment #12 from Hector --- (In reply to Dmitry Kazakov from comment #11) > I've added a merge request to Krita with the fix to the bug. Could you > please test it and check if the bug is fixed? The bug that I had no longer appears in this package. It seems to have checked all the options that I had then. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405648] Feature request: Tool for dividing into equal parts
https://bugs.kde.org/show_bug.cgi?id=405648 --- Comment #7 from Hector --- (In reply to Tymond from comment #6) > Some of the ideas here could even be implemented just in vector libraries Yes. So it can be done. You can come up with a lot of ideas to replace the missing features. But this should not go on forever. I'm not a fan of downloading a bunch of plugins and blanks. However, I have to make them. I want this to work out of the box. I want new users to immediately be able to use various chips, and not search the forums. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405648] Feature request: Tool for dividing into equal parts
https://bugs.kde.org/show_bug.cgi?id=405648 --- Comment #4 from Hector --- (In reply to Tymond from comment #3) This is not for lead lines. This is for measurements. For example, in architecture. You can add divisions and proportions to the measure tool, but it does not remain when you switch to the brush. Then his work will have to change... Better in the assistant, there are more settings. Just divisions on the ruler assistant. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405648] Feature request: Tool for dividing into equal parts
https://bugs.kde.org/show_bug.cgi?id=405648 --- Comment #2 from Hector --- (In reply to Tymond from comment #1) When I saw the subject of the letter, I thought it would be better to do this in a ruler. Why didn’t I think of this last year ... Again. Anyway, yes it does. The solution with the division on a ruler assistant is completely right. About the perspective, I meant its construction. I could use the division ruler in the composition. Could you also add the “golden section” checkbox, where there would be only one point by ratio? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405638] Feature request: around the point assistant tool
https://bugs.kde.org/show_bug.cgi?id=405638 --- Comment #4 from Hector --- (In reply to Tymond from comment #3) > Does it fix your issue? Yes, it does. For some reason I didn’t think of it last year. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405638] Feature request: around the point assistant tool
https://bugs.kde.org/show_bug.cgi?id=405638 --- Comment #2 from Hector --- (In reply to Tymond from comment #1) Simple 2D plans, concepts with a side view (like a car). A concentric ellipse constantly changes its center when you move the axis. But I just realized that it can be configured through the shift button and simply move to the desired point. So around the point it’s just a simplified version where you don’t have to adjust the axes. Then it is not necessary. Can be made an additional function to concentric. Checkbox "without axes". Pay more attention to the ellipse squared. I suggested this at the same time and even put a GIF(from another program) on what to do. bugs.kde.org/show_bug.cgi?id=405643 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwayland] [Bug 373907] Implement Wayland Primary Selection Protocol (middle-click paste)
https://bugs.kde.org/show_bug.cgi?id=373907 --- Comment #26 from Hector Martin --- Is anyone planning on looking at this now that Qt has support? It's basically the only thing stopping me from using Wayland... -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405643] Feature request: circle in a square assistant tool
https://bugs.kde.org/show_bug.cgi?id=405643 --- Comment #4 from Hector --- Created attachment 122943 --> https://bugs.kde.org/attachment.cgi?id=122943=edit from getleonardo.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 409613] Color picker shortcut doesn't work after moving canvas with spacebar(pan tool shortcut)
https://bugs.kde.org/show_bug.cgi?id=409613 Hector changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #4 from Hector --- (In reply to Boudewijn Rempt from comment #3) > Okay, please keep us posted :-) In the end, I found the reason. Shortcuts can be assigned to the spacebar + key. This breaks down the possibilities with ctrl and others after moving the canvas using the spacebar. So the bug is confirmed and resolved. I propose for now to disable the appointment of shortcuts with a space. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 409613] Color picker shortcut doesn't work after moving canvas with spacebar(pan tool shortcut)
https://bugs.kde.org/show_bug.cgi?id=409613 --- Comment #2 from Hector --- (In reply to Boudewijn Rempt from comment #1) > Hm, this works for me. Which version of Krita are you using? Im using 4.2.2. Observed since 4.2+ maybe. Or 4.1.7... I just tried it with a different keyboard layout. Sometimes it works, but sometimes the spacebar pan also stops working. Tried in virtual mint, everything works fine there. Maybe its a specific problem with my pc. About a week later I will have to install the system on a new drive. Maybe the problem will disappear. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 409613] New: Color picker shortcut doesn't work after moving canvas with spacebar(pan tool shortcut)
https://bugs.kde.org/show_bug.cgi?id=409613 Bug ID: 409613 Summary: Color picker shortcut doesn't work after moving canvas with spacebar(pan tool shortcut) Product: krita Version: unspecified Platform: unspecified OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Color Selectors Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- SUMMARY With brush. after moving the canvas using the spacebar, the CTRL shortcut stops working. So i cant pick a color. This works again if you click on "b" to activate the brush again or undo something. Works after moving with middle button. STEPS TO REPRODUCE 1. With brush enabled move the canvas with Spacebar 2. Try to pick a color with Ctrl -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 338150] [EGL] [DRI2] [intel] missing/incomplete repaints
https://bugs.kde.org/show_bug.cgi?id=338150 hector acosta changed: What|Removed |Added CC||hector.aco...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 342326] window contents freeze
https://bugs.kde.org/show_bug.cgi?id=342326 hector acosta changed: What|Removed |Added CC||hector.aco...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 395520] Konsole KPart blur does not work/incorrect warning message
https://bugs.kde.org/show_bug.cgi?id=395520 hector acosta changed: What|Removed |Added CC||hector.aco...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 396473] Can't enable blur or configure translucency
https://bugs.kde.org/show_bug.cgi?id=396473 hector acosta changed: What|Removed |Added CC||hector.aco...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405986] JJ: add "plus button" in minimized showing presets panel in brush edit
https://bugs.kde.org/show_bug.cgi?id=405986 --- Comment #2 from Hector --- (In reply to Scott Petrovic from comment #1) Thanks for the detailed answer. Then this report can be closed, see if it fixes it with a new design. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405988] New: ignore ps engine when import .abr
https://bugs.kde.org/show_bug.cgi?id=405988 Bug ID: 405988 Summary: ignore ps engine when import .abr Product: krita Version: unspecified Platform: Other OS: All Status: REPORTED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- Created attachment 119115 --> https://bugs.kde.org/attachment.cgi?id=119115=edit 2 test packs Krita can't import brushes from abr if it have ps engines config inside. Summary: Need to add ignoring for ps engines in abr import. Packs in attachments: 1.krita_testpack_with_engines (3 simple brushes) 2. krita_testpack_without_engines (3 same brushes + 1 smudge + 1 with bristle) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405986] New: JJ: add "plus button" in minimized showing presets panel in brush edit
https://bugs.kde.org/show_bug.cgi?id=405986 Bug ID: 405986 Summary: JJ: add "plus button" in minimized showing presets panel in brush edit Product: krita Version: unspecified Platform: Other OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- Created attachment 119114 --> https://bugs.kde.org/attachment.cgi?id=119114=edit Example Need to add a button with a selection of brush engine in the left panel when it is minimized. Now to turn on the default preset, you need to click on the "toogle showing presets" and only then on the button. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405648] New: Feature request: Tool for dividing into equal parts
https://bugs.kde.org/show_bug.cgi?id=405648 Bug ID: 405648 Summary: Feature request: Tool for dividing into equal parts Product: krita Version: unspecified Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- A simple tool that is a line divided into equal parts. The number of segments probably should be selected in the panel. This tool is needed for dividing... Dividing in perspective in my case. To divide something we need to draw a divided line. And it’s not very much to do by sight. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405644] New: Feature request: 2 VP on one line and station point
https://bugs.kde.org/show_bug.cgi?id=405644 Bug ID: 405644 Summary: Feature request: 2 VP on one line and station point Product: krita Version: unspecified Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- Created attachment 118914 --> https://bugs.kde.org/attachment.cgi?id=118914=edit Pics from comment I see it as a big tool with several possibilities. Two vanishing points(VP) are put on one line (horizon lines). After put the third point - the station point(SP). SP should be blocked and not moving. Ideally, the angle between two vanishing points and the station point should also be measured. What is it for. To draw boxes at different angles on the same plane in perspective, you need to have a SP from which the viewer is watching. The angle between two VP and SP should be 90 degrees. But this is for one box. To draw another you need other vanishing points at an angle of 90 degrees. (pic. 2) Now we have to move both VP manually. And something else to mark the station point And the way I imagine it. I use reference image with alpha png file (pic. 4) 1) Put one point, then another on the same line with the first. Then SP. 3 step (pic. 1) 2) The SP must be able to block the movement. 3) The angle can be shown near the station point or be in the panel. (pic. 3) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405643] Feature request: circle in a square assistant tool
https://bugs.kde.org/show_bug.cgi?id=405643 --- Comment #2 from Hector --- (In reply to wolthera from comment #1) > a readjustable 4 corner mesh that always has a circle inside Yes it is. This is the simplest method of drawing an ellipse in perspective. We draw a square, and in it we draw a circle. The circle touches the midpoints of the sides of the square. It is easy to draw a square in perspective, but it takes too much time to set a concentric ellipse tool. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405643] New: Feature request: circle in a square assistant tool
https://bugs.kde.org/show_bug.cgi?id=405643 Bug ID: 405643 Summary: Feature request: circle in a square assistant tool Product: krita Version: unspecified Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- Created attachment 118912 --> https://bugs.kde.org/attachment.cgi?id=118912=edit simple drawing example The tool looks like an ellipse tool, but is in a square. This is needed for more simply drawing ellipses in perspective. To draw it with the current ellipse tool, you need to draw the diagonals of the square and correctly align the axis of the ellipse to the square. With the circle in a square tool you just need to set the 4 corners of the square. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405638] New: Feature request: around the point assistant tool
https://bugs.kde.org/show_bug.cgi?id=405638 Bug ID: 405638 Summary: Feature request: around the point assistant tool Product: krita Version: unspecified Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- Tool similar to concentric ellipse, but without axes. Just the point around which the brush will draw a circle. It is necessary to draw circles with one center not in perspective. Such a tool is simply more convenient and faster to use. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 364258] 4.x application configuration rc files are ignored [patch]
https://bugs.kde.org/show_bug.cgi?id=364258 --- Comment #30 from Hector --- (In reply to caulier.gilles from comment #29) > Héctor, > > Esta entrada no contiene una solución para usted. Se trata de importar > configuraciones antiguas de DK usando la misma cuenta. > > Para usar una base de datos anterior con una cuenta nueva y el tiempo de > configuración de la base de datos (consulte el panel de configuración de la > base de datos), tiene una configuración donde desea almacenar los archivos > de la base de datos sqlite. Simplemente señale la ruta donde se encuentran > sus archivos y DK le pedirá que use este archivo o que sobrescriba. Hacer > copias de seguridad de archivos de base de datos antes. > > Tenga en cuenta que los archivos DB deben estar en R / W para la nueva > cuenta, de lo contrario no funcionará. > > Gilles Caulier Gracias Gilles. He seguido algunos tips encontrados en otro foro (no recuerdo donde) y he logrado recuperar todas las etiquetas e información de la base de datos anterior. Ahora debo volver a ordenar mi fototeca -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 364258] 4.x application configuration rc files are ignored [patch]
https://bugs.kde.org/show_bug.cgi?id=364258 Hector changed: What|Removed |Added CC||reboll...@gmail.com Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #28 from Hector --- Hello friends!! My name is Hector and I'm from Argentina. First of all, excuse me to reopen the subject .. Years ago I stopped using Digikam because of this problem. Before this, it was my only photo software, I adored it. I had thousands of photos with labels, and various classifications. 2 weeks ago I have updated the system and now I use OpenSuse Tumbleweed. As always I was updating on update, in this opportunity I decided to create a new user since I never open digikam. On this occasion, the user "HAR" (previously called Hector) was created. Now with the HAR user, I was able to open digikam and have created and configured everything from scratch, but I still can not import the Digikam 4 database that has 13.4MB I have read all the comments, but I could not understand how they have been able to solve and if they have managed to import all the previous database to the new version of Digikam. Currently I have installed Digikam v5.9, but I would like to import the previous database to not lose as many years of work as it was mentioned by @Alexey Stukalov How do I use the patch that commented @Simon? Thank you very much for all your opinions and comments. I hope that with your help, I can manage to import my beloved digikam4.db -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396528] New: [Wish] Bigger sensor window in brush editor
https://bugs.kde.org/show_bug.cgi?id=396528 Bug ID: 396528 Summary: [Wish] Bigger sensor window in brush editor Product: krita Version: 4.1.0 Platform: unspecified OS: MS Windows Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: misha.bossm...@yandex.ru Target Milestone: --- Created attachment 113937 --> https://bugs.kde.org/attachment.cgi?id=113937=edit Example of what I want I want to see the brush editor curve window large in size. And also more divisions. Now I can't exactly put the angle turn from -30 to +30, but I need it. English is not my native language, so I made a picture. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 383179] KDE desktop compositing occasionally causes flickering and frozen window contents
https://bugs.kde.org/show_bug.cgi?id=383179 --- Comment #10 from Hector Martin --- Yeah, this hasn't gone away for me. These days I just toggle compositing on and off to fix it, but it still happens every now and then. -- You are receiving this mail because: You are watching all bug changes.
[kmldonkey] [Bug 386331] New: Kmldonkey crash
https://bugs.kde.org/show_bug.cgi?id=386331 Bug ID: 386331 Summary: Kmldonkey crash Product: kmldonkey Version: unspecified Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: gmazzurc...@gmail.com Reporter: ranmaru.hibik...@gmail.com Target Milestone: --- Application: kmldonkey (2.1.3) KDE Platform Version: 4.14.35 Qt Version: 4.8.7 Operating System: Linux 4.13.6-1-default x86_64 Distribution: "openSUSE Tumbleweed" -- Information about the crash: - What I was doing when the application crashed: Installed from 3rd repo. Just started and crash The crash can be reproduced every time. -- Backtrace: Application: KMLDonkey (kmldonkey), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f9f1dcba940 (LWP 2694))] Thread 2 (Thread 0x7f9f08bb6700 (LWP 2695)): #0 0x7f9f19f56cab in poll () at /lib64/libc.so.6 #1 0x7f9f15744149 in () at /usr/lib64/libglib-2.0.so.0 #2 0x7f9f1574425c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #3 0x7f9f1a768dde in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib64/libQtCore.so.4 #4 0x7f9f1a7372e4 in QEventLoop::processEvents(QFlags) () at /usr/lib64/libQtCore.so.4 #5 0x7f9f1a73764e in QEventLoop::exec(QFlags) () at /usr/lib64/libQtCore.so.4 #6 0x7f9f1a629bf6 in QThread::exec() () at /usr/lib64/libQtCore.so.4 #7 0x7f9f1a717833 in () at /usr/lib64/libQtCore.so.4 #8 0x7f9f1a62c4b4 in () at /usr/lib64/libQtCore.so.4 #9 0x7f9f16d95558 in start_thread () at /lib64/libpthread.so.0 #10 0x7f9f19f6145f in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7f9f1dcba940 (LWP 2694)): [KCrash Handler] #6 0x7f9f1d8e3fd0 in ServerInfo::isConnected() const () at /usr/lib64/liblibkmldonkey.so.5 #7 0x7f9f1d8cab37 in DonkeyProtocol::processMessage() () at /usr/lib64/liblibkmldonkey.so.5 #8 0x7f9f1d8bc8e5 in () at /usr/lib64/liblibkmldonkey.so.5 #9 0x7f9f1a74cf9d in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () at /usr/lib64/libQtCore.so.4 #10 0x7f9f1d8d2ce0 in () at /usr/lib64/liblibkmldonkey.so.5 #11 0x7f9f1a74cf9d in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () at /usr/lib64/libQtCore.so.4 #12 0x7f9f19bec2b3 in () at /usr/lib64/libQtNetwork.so.4 #13 0x7f9f19bf689d in () at /usr/lib64/libQtNetwork.so.4 #14 0x7f9f1ac7cf2c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQtGui.so.4 #15 0x7f9f1ac84087 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQtGui.so.4 #16 0x7f9f1bebca7a in KApplication::notify(QObject*, QEvent*) () at /usr/lib64/libkdeui.so.5 #17 0x7f9f1a738d3e in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQtCore.so.4 #18 0x7f9f1a7693d6 in () at /usr/lib64/libQtCore.so.4 #19 0x7f9f15743f97 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #20 0x7f9f157441d0 in () at /usr/lib64/libglib-2.0.so.0 #21 0x7f9f1574425c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #22 0x7f9f1a768db6 in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib64/libQtCore.so.4 #23 0x7f9f1ad25867 in () at /usr/lib64/libQtGui.so.4 #24 0x7f9f1a7372e4 in QEventLoop::processEvents(QFlags) () at /usr/lib64/libQtCore.so.4 #25 0x7f9f1a73764e in QEventLoop::exec(QFlags) () at /usr/lib64/libQtCore.so.4 #26 0x7f9f1a73d19c in QCoreApplication::exec() () at /usr/lib64/libQtCore.so.4 #27 0x562b1a648d0c in () #28 0x7f9f19e89f4a in __libc_start_main () at /lib64/libc.so.6 #29 0x562b1a648eaa in _start () Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwayland] [Bug 373907] Implement Wayland Primary Selection Protocol (middle-click paste)
https://bugs.kde.org/show_bug.cgi?id=373907 --- Comment #4 from Hector Martin <hec...@marcansoft.com> --- I get the feeling that if KDE won't push forward on upstreaming this then nobody will. GNOME seems quite happy using it as a nonstandard protocol. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 383179] KDE desktop compositing occasionally causes flickering and frozen window contents
https://bugs.kde.org/show_bug.cgi?id=383179 Hector Martin <hec...@marcansoft.com> changed: What|Removed |Added CC||hec...@marcansoft.com --- Comment #7 from Hector Martin <hec...@marcansoft.com> --- I've been experiencing a seemingly identical issue for months too. I'm on an Intel GPU, which suggests the problem is in kwin or a shared part of Mesa. When window contents freeze, sometimes they are partially updated, triggering an effect where only some segments/rectangles of the screen see into the updated window. Also, I have the scroll wheel on the window title bar mapped to change window opacity, and doing so always causes the full window to refresh properly. Restarting kwin fixes the problem, temporarily. It would be interesting if the original reporter sees this behavior too to further confirm we're talking about the same problem. I'm on Gentoo Linux amd64, kernel 4.11.8-gentoo (but this has been going on for multiple kernel releases now), Core i7-3820QM. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382482] Digikam can not connect to the database
https://bugs.kde.org/show_bug.cgi?id=382482 --- Comment #3 from Hector <reboll...@gmail.com> --- (In reply to caulier.gilles from comment #1) > ¿Qué tipo de base de datos utiliza exactamente? MySQL -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379959] Could not start database initializer
https://bugs.kde.org/show_bug.cgi?id=379959 Hector <reboll...@gmail.com> changed: What|Removed |Added CC||reboll...@gmail.com --- Comment #2 from Hector <reboll...@gmail.com> --- A similar problem occurs in version 5.6. Digikam can not connect to the existing database. In order to use the program I had to create a new user and configure from scratch digikam. So far I've lost 4 years of work. (Labels, albumens, people, etc. I've lost everything !!) *** En la versión 5.6 sucede un problema similar. Digikam no puede conectarse con la base de datos existente. Para poder utilizar el programa tuve que crear un nuevo usuario y configurar desde cero digikam. Hasta ahora he perdido 4 años de trabajo. (etiquetas, albumens, personas, etc. lo he perdido todo!!) ** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382482] New: Digikam can not connect to the database
https://bugs.kde.org/show_bug.cgi?id=382482 Bug ID: 382482 Summary: Digikam can not connect to the database Product: digikam Version: 5.6.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: digikam-de...@kde.org Reporter: reboll...@gmail.com Target Milestone: --- Application: digikam (5.6.0) Qt Version: 5.6.1 Frameworks Version: 5.26.0 Operating System: Linux 4.4.74-18.20-default x86_64 Distribution: "openSUSE Leap 42.2" -- Information about the crash: - What I was doing when the application crashed: When installing OpenSuse 42.2 and updating Digikam to its latest version 5.6 the program can not connect to the existing database in my the user that already came using the application and CAN NOT OPEN THE PROGRAM. He stays for hours "tried to connect to the database" and nothing. The strange thing is that when creating a new user and log in with this new user, when opening Digikam for the first time the program works perfect. How can I do not to lose my database and the thousands of tags and saved things I had in digikam? (4 years of information) The crash can be reproduced every time. -- Backtrace: Application: digiKam (digikam), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7fea46230a00 (LWP 15345))] Thread 4 (Thread 0x7fe9f700 (LWP 15351)): #0 0x7fea3e3910bf in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x7fea41e4265b in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib64/libQt5Core.so.5 #2 0x7fea4577edd0 in Digikam::ScanController::run() () at /usr/lib64/libdigikamgui.so.5.6.0 #3 0x7fea41e419e9 in () at /usr/lib64/libQt5Core.so.5 #4 0x7fea3e38c744 in start_thread () at /lib64/libpthread.so.0 #5 0x7fea41538aad in clone () at /lib64/libc.so.6 Thread 3 (Thread 0x7fea054bb700 (LWP 15350)): #0 0x7fea4152c28d in read () at /lib64/libc.so.6 #1 0x7fea38212670 in () at /usr/lib64/libglib-2.0.so.0 #2 0x7fea381d1e49 in g_main_context_check () at /usr/lib64/libglib-2.0.so.0 #3 0x7fea381d22a8 in () at /usr/lib64/libglib-2.0.so.0 #4 0x7fea381d242c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #5 0x7fea4205433b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib64/libQt5Core.so.5 #6 0x7fea42001feb in QEventLoop::exec(QFlags) () at /usr/lib64/libQt5Core.so.5 #7 0x7fea41e3cf1a in QThread::exec() () at /usr/lib64/libQt5Core.so.5 #8 0x7fea3e5b8295 in () at /usr/lib64/libQt5DBus.so.5 #9 0x7fea41e419e9 in () at /usr/lib64/libQt5Core.so.5 #10 0x7fea3e38c744 in start_thread () at /lib64/libpthread.so.0 #11 0x7fea41538aad in clone () at /lib64/libc.so.6 Thread 2 (Thread 0x7fea0d214700 (LWP 15349)): #0 0x7fea4153020d in poll () at /lib64/libc.so.6 #1 0x7fea329783e2 in () at /usr/lib64/libxcb.so.1 #2 0x7fea32979fcf in xcb_wait_for_event () at /usr/lib64/libxcb.so.1 #3 0x7fea0e6e8839 in () at /usr/lib64/libQt5XcbQpa.so.5 #4 0x7fea41e419e9 in () at /usr/lib64/libQt5Core.so.5 #5 0x7fea3e38c744 in start_thread () at /lib64/libpthread.so.0 #6 0x7fea41538aad in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7fea46230a00 (LWP 15345)): [KCrash Handler] #6 0x7fea44871c90 in Digikam::BdEngineBackend::status() const () at /usr/lib64/libdigikamcore.so.5.6.0 #7 0x7fea434d5e14 in Digikam::CoreDbAccess::CoreDbAccess() () at /usr/lib64/libdigikamdatabase.so.5.6.0 #8 0x7fea43474037 in Digikam::CollectionScanner::databaseInitialScanDone() () at /usr/lib64/libdigikamdatabase.so.5.6.0 #9 0x7fea457cae18 in Digikam::DigikamApp::DigikamApp() () at /usr/lib64/libdigikamgui.so.5.6.0 #10 0x00408938 in main(int, char**) (argc=1, argv=) at /usr/src/debug/digikam-5.6.0/core/app/main/main.cpp:236 Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 380887] Meta key launcher shortcut interfering with compose key settings
https://bugs.kde.org/show_bug.cgi?id=380887 --- Comment #5 from Hector Martin <hec...@marcansoft.com> --- That workaround doesn't work for me; not sure if this is because my problem is different from the reporter's or not. My issue isn't KWin stealing the Meta key, it's something stealing the Compose key (regardless of where it is mapped). I map it to Caps Lock, not Meta. The action triggered is not the launcher, it's something else (looks like a random hotkey action to me, but I'm not sure; right now it's triggering some kind of window show/hide that only happens after I've opened enough windows). The workaround correctly disables the Meta/Win key triggering the launcher, but does nothing to fix the Compose key being stolen by something else. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381213] New: Plasma crash on ctrl tab
https://bugs.kde.org/show_bug.cgi?id=381213 Bug ID: 381213 Summary: Plasma crash on ctrl tab Product: plasmashell Version: 5.5.5 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: hhg...@gmail.com CC: bhus...@gmail.com, plasma-b...@kde.org Target Milestone: 1.0 Application: plasmashell (5.5.5) Qt Version: 5.5.1 Operating System: Linux 4.4.0-79-generic x86_64 Distribution: Ubuntu 16.04.2 LTS -- Information about the crash: - What I was doing when the application crashes: i was moving from Chrome to nautilus to see a download, and then plasma crash with out explanation The crash can be reproduced sometimes. -- Backtrace: Application: Plasma (plasmashell), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". write () at ../sysdeps/unix/syscall-template.S:84 [Current thread is 1 (Thread 0x7fc98d4b68c0 (LWP 2139))] Thread 16 (Thread 0x7fc8a9ffb700 (LWP 11148)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7fc9882c4a5b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x7fc8d4bb02bf in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #3 0x7fc8d4bb44e8 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #4 0x7fc8d4baf46d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #5 0x7fc8d4bb4542 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #6 0x7fc8d4baf46d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #7 0x7fc8d4bb2353 in ThreadWeaver::Thread::run() () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #8 0x7fc9882c37be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7fc9873b06ba in start_thread (arg=0x7fc8a9ffb700) at pthread_create.c:333 #10 0x7fc987bd982d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 15 (Thread 0x7fc8aa7fc700 (LWP 11147)): [KCrash Handler] #6 0x7fc987b08428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #7 0x7fc987b0a02a in __GI_abort () at abort.c:89 #8 0x7fc987b4a7ea in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7fc987c632e0 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #9 0x7fc987b52e0a in malloc_printerr (ar_ptr=, ptr=, str=0x7fc987c633f0 "double free or corruption (out)", action=3) at malloc.c:5004 #10 _int_free (av=, p=, have_lock=0) at malloc.c:3865 #11 0x7fc987b5698c in __GI___libc_free (mem=) at malloc.c:2966 #12 0x7fc8b2564e6f in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 #13 0x7fc8b25655fd in mdb_env_open () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 #14 0x7fc8b27752ca in Baloo::Database::open(Baloo::Database::OpenMode) () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #15 0x7fc8b2bd11e8 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5 #16 0x7fc8b2bc2b99 in Baloo::Query::exec() () from /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5 #17 0x7fc8b2de3f2f in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/krunner_baloosearchrunner.so #18 0x7fc8b2de4879 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/krunner_baloosearchrunner.so #19 0x7fc8d569a540 in Plasma::AbstractRunner::performMatch(Plasma::RunnerContext&) () from /usr/lib/x86_64-linux-gnu/libKF5Runner.so.5 #20 0x7fc8d4bb3c90 in ThreadWeaver::Executor::run(QSharedPointer const&, ThreadWeaver::Thread*) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #21 0x7fc8d4bb27e0 in ThreadWeaver::Job::execute(QSharedPointer const&, ThreadWeaver::Thread*) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #22 0x7fc8d4bb228a in ThreadWeaver::Thread::run() () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #23 0x7fc9882c37be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #24 0x7fc9873b06ba in start_thread (arg=0x7fc8aa7fc700) at pthread_create.c:333 #25 0x7fc987bd982d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 14 (Thread 0x7fc8aaffd700 (LWP 11146)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7fc9882c4a5b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x7fc8d4bb02bf in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () from
[plasmashell] [Bug 380887] Meta key launcher shortcut interfering with compose key settings
https://bugs.kde.org/show_bug.cgi?id=380887 Hector Martin <hec...@marcansoft.com> changed: What|Removed |Added CC||hec...@marcansoft.com --- Comment #3 from Hector Martin <hec...@marcansoft.com> --- Same issue here (5.10.1 under Wayland). I had an issue with a random shortcut stealing the Compose key. I managed to find it in shortcut management and remove it (even though it did not have the Compose key listed) and, at the time, Compose worked again. Now, after a reboot, some other shortcut has stolen Compose. I'm not entirely sure what it is - it seems to maximize/minimize a particular window (window shortcut?). This is independent of which key I choose for the Compose key. I use Caps Lock. If I move it to Menu then the Menu key triggers the shortcut instead. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 380311] No way to launch ssh-agent with interactivity under Wayland
https://bugs.kde.org/show_bug.cgi?id=380311 --- Comment #2 from Hector Martin <hec...@marcansoft.com> --- To be clear, the problem isn't that this is an interactive process *when those scripts are executed*, it's that the appropriate display environment variables need to be available so they are inherited by an intearctive child process at a later time, in response to a user request. For now I resorted to the aforementioned hack of wrapping ksshaskpass in a script that sources the display environment variables from somewhere else filled in by an autostart script. ssh-agent still starts from env/, but now the script it calls injects the right variables before execing ksshaskpass. I did have to set DISPLAY to a dummy value in the parent script, though, because ssh-agent checks that it is set before even trying to call askpass... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 380311] New: No way to launch ssh-agent with interactivity under Wayland
https://bugs.kde.org/show_bug.cgi?id=380311 Bug ID: 380311 Summary: No way to launch ssh-agent with interactivity under Wayland Product: plasmashell Version: 5.9.5 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: generic-wayland Assignee: plasma-b...@kde.org Reporter: hec...@marcansoft.com Target Milestone: 1.0 AIUI, the supported method for launching background daemons that also set environment variables under Plasma is ~/.config/plasma-workspace/env/*.sh. Under X11, the $DISPLAY environment variable exists when these scripts are sourced. However, under Wayland, these scripts are sourced before the compositor is started and $WAYLAND_DISPLAY does not exist. This makes it impossible to launch ssh-agent and use it interactively, e.g. with SSH_ASKPASS=ksshaskpass because ksshaskpass has no idea what display to start in. I suspect the env scripts ought to be sourced from /usr/lib/startplasma (after kwin_wayland starts), not /usr/bin/startplasmacompositor. Or perhaps there should be two config directories, one for pre-compositor scripts and one for post-compositor scripts. Ugly workarounds are possible, of course (e.g. an autostart script that dumps the required variables somewhere, and an sshaskpass wrapper that pulls them in), but there should clearly be a better way. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwayland] [Bug 373907] Implement Wayland Primary Selection Protocol (middle-click paste)
https://bugs.kde.org/show_bug.cgi?id=373907 Hector Martin <hec...@marcansoft.com> changed: What|Removed |Added CC||hec...@marcansoft.com -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 375057] New: No agents were available for this request.
https://bugs.kde.org/show_bug.cgi?id=375057 Bug ID: 375057 Summary: No agents were available for this request. Product: plasma-nm Version: 5.8.95 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: lu...@kde.org Reporter: hector.aco...@gmail.com CC: jgrul...@redhat.com Target Milestone: --- I'm unsure if this is strictly related to plasma-nm or if it's related to other component. Trying to connect to an openconnect-based vpn fails with the following error (in the journal). Failed to request VPN secrets #3: No agents were available for this request. Jan 14 14:19:06 tamal NetworkManager[527]: [1484425146.1838] vpn-connection[0x102e2f0,c1cfaabd-177c-4b79-b205-22159cc3bf67,"VPN NAME",0]: Failed to request VPN secrets #3: No agents were available for this request. Jan 14 14:19:06 tamal NetworkManager[527]: [1484425146.1914] vpn-connection[0x102e2f0,c1cfaabd-177c-4b79-b205-22159cc3bf67,"VPN NAME",0]: VPN service disappeared Connecting to other (non-openconnect) based VPN works as expected. Additionally, connecting to the vpn using NetworkManager's command line utilities works fine. -- You are receiving this mail because: You are watching all bug changes.
[keditbookmarks] [Bug 308443] Crash when update a favicon twice
https://bugs.kde.org/show_bug.cgi?id=308443 Hector Wilvert Ivan Valdez Reza <ranmaru.hibik...@gmail.com> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 370724] New: Window manager restarts
https://bugs.kde.org/show_bug.cgi?id=370724 Bug ID: 370724 Summary: Window manager restarts Product: kwin Version: 5.7.4 Platform: Debian testing OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: hgonzalezm...@gmail.com Application: kwin_x11 (5.7.4) Qt Version: 5.6.1 Frameworks Version: 5.26.0 Operating System: Linux 4.7.5-2 x86_64 Distribution: Debian GNU/Linux testing (stretch) -- Information about the crash: - What I was doing when the application crashed: I was openining a preference window from a plasma widget when the window manager restarted - Unusual behavior I noticed: the window manager stopped - Custom settings of the application: None The crash can be reproduced every time. -- Backtrace: Application: KWin (kwin_x11), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f85bc203940 (LWP 2670))] Thread 7 (Thread 0x7f85a7fff700 (LWP 2900)): #0 0x00386f4e1253 in select () at ../sysdeps/unix/syscall-template.S:84 #1 0x00312a0d6d3f in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x00312a0d87e4 in QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x00312a0d8cfa in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00312a08319a in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x003129ea8e53 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x003d064c8a55 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #7 0x003129eadd78 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x00386fc07464 in start_thread (arg=0x7f85a7fff700) at pthread_create.c:333 #9 0x00386f4e897f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 6 (Thread 0x7f85a77fe700 (LWP 2720)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00313bf7c574 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #2 0x00313bf7c5b9 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #3 0x00386fc07464 in start_thread (arg=0x7f85a77fe700) at pthread_create.c:333 #4 0x00386f4e897f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 5 (Thread 0x7f85b0fcc700 (LWP 2716)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f85b2134493 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so #2 0x7f85b2133bd7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so #3 0x00386fc07464 in start_thread (arg=0x7f85b0fcc700) at pthread_create.c:333 #4 0x00386f4e897f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 4 (Thread 0x7f85b37fe700 (LWP 2713)): #0 0x00386f4e1253 in select () at ../sysdeps/unix/syscall-template.S:84 #1 0x00312a0d6d3f in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x00312a0d87e4 in QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x00312a0d8cfa in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00312a08319a in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x003129ea8e53 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x003d064c8a55 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #7 0x003129eadd78 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x00386fc07464 in start_thread (arg=0x7f85b37fe700) at pthread_create.c:333 #9 0x00386f4e897f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 3 (Thread 0x7f85ba045700 (LWP 2701)): #0 0x00386f4e1253 in select () at ../sysdeps/unix/syscall-template.S:84 #1 0x00312a0d6d3f in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x00312a0d87e4 in QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x00312a0d8cfa in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x00312a08319a in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x003129ea8e53 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x00312ba15525 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #7 0x003129eadd78 in ?? () from
[krunner] [Bug 344328] krunner is not visible when using multiple monitors
https://bugs.kde.org/show_bug.cgi?id=344328 hector acosta <hector.aco...@gmail.com> changed: What|Removed |Added CC||hector.aco...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 359558] System tray creating ghost entries
https://bugs.kde.org/show_bug.cgi?id=359558 --- Comment #2 from hector acosta <hector.aco...@gmail.com> --- I believe I've found a way to reproduce this. Using plasmashell 5.5.4 Connect an external monitor. Run kquitapp plasmashell Run plasmashell Connect a montior Run kequitapp plasmashell Run plasmashell -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 359558] System tray creating ghost entries
https://bugs.kde.org/show_bug.cgi?id=359558 --- Comment #1 from hector acosta <hector.aco...@gmail.com> --- url is screenshot of the problem -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 359558] New: System tray creating ghost entries
https://bugs.kde.org/show_bug.cgi?id=359558 Bug ID: 359558 Summary: System tray creating ghost entries Product: plasmashell Version: master Platform: Other URL: http://i.imgur.com/nQLJWfE.png OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: System Tray Assignee: plasma-b...@kde.org Reporter: hector.aco...@gmail.com My system tray will create spurious entries. Setting those entries to hidden will remove the whitespace. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
