[lattedock] [Bug 409904] New: Tooltips dont disappear as they should
https://bugs.kde.org/show_bug.cgi?id=409904 Bug ID: 409904 Summary: Tooltips dont disappear as they should Product: lattedock Version: 0.8.9 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: fredcom...@gmail.com Target Milestone: --- SUMMARY When I hover over my dock with my touchpen, let go and point it to a different area on the screen, latte-dock wont take notice of it. Tooltips dont disappear, the highlighted icon sometimes stays zoomed in and the dock wont hide STEPS TO REPRODUCE 1. Hover over latte-dock 2. Move Mouse to a different location instantaneously (as i am using my touch pen, it happens when i let it go and point it to another portion of the display, moving it using software might work, im not sure though. The important part is, that its out of lattes "range" immediately). It takes a few times to recreate, but it happens more often than it should. 3. Well, thats all. But heres a video I made to show it properly, if you cant recreate it https://youtu.be/MOIYuy1oh_g OBSERVED RESULT Well, many times neither the dock will disappear, how it should , nor will the tooltip. The icon-zooming sometimes wont do anything EXPECTED RESULT Latte should poll once a second to make sure the mouse isnt above it anymore, instead of looking for the mouse to "actually leave the area". That way, jumps wouldnt be a problem anymore SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 409904] Tooltips dont disappear as they should
https://bugs.kde.org/show_bug.cgi?id=409904 Fredrik changed: What|Removed |Added Resolution|WAITINGFORINFO |FIXED Status|NEEDSINFO |RESOLVED --- Comment #4 from Fredrik --- The bug appears to be fixed, no hickups anymore. Thanks! Thing about youtube: I kept it unlisted. Only ppl who know about the bug would see the vid, because they clicked on the link here -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 415845] configurable "open with" menu
https://bugs.kde.org/show_bug.cgi?id=415845 Fredrik Viklund changed: What|Removed |Added CC||fred...@viklund.se --- Comment #7 from Fredrik Viklund --- Agree this would be a very valuable setting! In many cases, the default application for opening a photo (e.g. photo viewer) is not the same I use to edit the photo (e.g. Gimp or RawTherapee). Also, it would be extremely useful to be able to choose between two or more applications to edit or process a file. It would be a great addition on all platforms. It can be implemented in many ways. A flexible solution would be: * In settings dialogue, add a tab for "External tools" where the user can define external tools by setting: - Name (in context menu) - path to executable - command line options (including suitable variables for current file name and path) - file types for which the tool should be displayed in the context menu Simpler, but less flexible, is to define some common tools where the user can give the path to the executable. An example can be found in RawTherapee. https://rawpedia.rawtherapee.com/Preferences#External_Editor -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #5 from Fredrik Höglund --- There is a way to check that at runtime by calling glGetFramebufferAttachmentParameteriv() with pname set to GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #12 from Fredrik Höglund --- (In reply to Michail Vourlakos from comment #9) > (In reply to Fredrik Höglund from comment #5) > > There is a way to check that at runtime by calling > > glGetFramebufferAttachmentParameteriv() with pname set to > > GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING. > > I can test this if you want: > > 1. Is there any command that can rev reveal this? > 2. If no [1] do you have a small testing program that I can build to return > to you the output? Vlad already tested it per comment #8. Possible fix: https://phabricator.kde.org/D21908 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #21 from Fredrik Höglund --- Git commit 3d384f3c90205f35fea445446903661c7c046514 by Fredrik Höglund. Committed on 29/06/2019 at 11:09. Pushed by fredrik into branch 'Plasma/5.16'. glx: Prefer an sRGB capable fbconfig Prefer an sRGB capable fbconfig for the default framebuffer. Signed-off-by: Fredrik Höglund M +26 -5plugins/platforms/x11/standalone/glxbackend.cpp https://commits.kde.org/kwin/3d384f3c90205f35fea445446903661c7c046514 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #26 from Fredrik Höglund --- (In reply to Roman Gilg from comment #22) > The patch lead to a regression in cirrus (default video device of openQA) > and possibly needs to be reverted. Reverting this patch means having to disable gamma correction on Intel. Punishing every user with an Intel GPU in order to keep kwin working with a software renderer on a Cirrus chip that claims to support depth 24/32 even though it doesn't, is simply not acceptable IMO. So I'm going to solve this by blacklisting sRGB configs on LLVMPipe instead. But I would be just as happy to say that we simply do not support the kind of system you are describing. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 Fredrik Höglund changed: What|Removed |Added Latest Commit||https://commits.kde.org/kwi ||n/5191311d36fbbbe51a3c137f3 ||6148a662a099963 Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Version Fixed In||5.16.3 --- Comment #29 from Fredrik Höglund --- Git commit 5191311d36fbbbe51a3c137f36148a662a099963 by Fredrik Höglund. Committed on 08/07/2019 at 22:43. Pushed by fredrik into branch 'Plasma/5.16'. [effects/blur] Disable sRGB when the framebuffer is linear Disable sRGB rendering when the color encoding of the default framebuffer is linear. FIXED-IN: 5.16.3 Differential Revision: https://phabricator.kde.org/D22153 Signed-off-by: Fredrik Höglund M +28 -5effects/blur/blur.cpp https://commits.kde.org/kwin/5191311d36fbbbe51a3c137f36148a662a099963 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #30 from Fredrik Höglund --- (In reply to Fabian Vogt from comment #27) > > So I'm going to solve this by blacklisting sRGB configs on LLVMPipe instead. > > That sounds like a bit too much, everything except cirrus with 16bpp seems to > work. Unfortunately we can't easily detect that the video device is a Cirrus device. The OpenGL driver can only tell us that it is llvmpipe; it doesn't know where the results of the rendering is going to be presented. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408594] color saturation in blurred regions is higher than expected
https://bugs.kde.org/show_bug.cgi?id=408594 --- Comment #32 from Fredrik Höglund --- (In reply to Fabian Vogt from comment #31) > (In reply to Fredrik Höglund from comment #30) > > (In reply to Fabian Vogt from comment #27) > > > > So I'm going to solve this by blacklisting sRGB configs on LLVMPipe > > > > instead. > > > > > > That sounds like a bit too much, everything except cirrus with 16bpp > > > seems to > > > work. > > > > Unfortunately we can't easily detect that the video device is a Cirrus > > device. The OpenGL driver can only tell us that it is llvmpipe; it doesn't > > know where the results of the rendering is going to be presented. > > Luckily that shouldn't be necessary, as we only know that llvmpipe + 16bpp > is broken. Is detecting a 16bpp default framebuffer possible? That's something that we can do. I'll update https://phabricator.kde.org/D22203 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 353192] Debug info/data section not detected on AMD64
https://bugs.kde.org/show_bug.cgi?id=353192
--- Comment #8 from Fredrik Tolf ---
This is my reproducible testcase:
#include
asm(".pushsection .foo,\"awx\",@progbits;"
".type writeablefunction, @function;"
"writeablefunction:"
"ret;"
".popsection;");
int main(int argc, char **argv)
{
malloc(128);
return(0);
}
I compiled with "gcc -g -Wall -o vgtest vgtest.c", but I reckon it should be
fairly tolerant with compiler flags. Valgrind output is:
$ valgrind --tool=memcheck --leak-check=full ./vgtest
==27841== Memcheck, a memory error detector
==27841== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==27841== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
info
==27841== Command: ./vgtest
==27841==
==27841==
==27841== HEAP SUMMARY:
==27841== in use at exit: 128 bytes in 1 blocks
==27841== total heap usage: 1 allocs, 0 frees, 128 bytes allocated
==27841==
==27841== 128 bytes in 1 blocks are definitely lost in loss record 1 of 1
==27841==at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==27841==by 0x1086C8: ??? (in /tmp/vgtest)
==27841==by 0x4E582B0: (below main) (libc-start.c:291)
==27841==
==27841== LEAK SUMMARY:
==27841==definitely lost: 128 bytes in 1 blocks
==27841==indirectly lost: 0 bytes in 0 blocks
==27841== possibly lost: 0 bytes in 0 blocks
==27841==still reachable: 0 bytes in 0 blocks
==27841== suppressed: 0 bytes in 0 blocks
==27841==
==27841== For counts of detected and suppressed errors, rerun with: -v
==27841== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
To point in this case being the missing symbol for "main" in the loss record.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 353192] Debug info/data section not detected on AMD64
https://bugs.kde.org/show_bug.cgi?id=353192
--- Comment #9 from Fredrik Tolf ---
Also, this is a patch that fixes the issue for me. It does also include the fix
I mentioned above.
--- valgrind-3.12.0~svn20160714.orig/coregrind/m_debuginfo/debuginfo.c
+++ valgrind-3.12.0~svn20160714/coregrind/m_debuginfo/debuginfo.c
@@ -359,14 +359,14 @@ static Bool discard_syms_in_range ( Addr
while (True) {
if (curr == NULL)
break;
- if (curr->text_present
- && curr->text_size > 0
- && (start+length - 1 < curr->text_avma
- || curr->text_avma + curr->text_size - 1 < start)) {
-/* no overlap */
-} else {
- found = True;
- break;
+ if (curr->text_present && curr->text_size > 0) {
+ if (start+length - 1 < curr->text_avma
+ || curr->text_avma + curr->text_size - 1 < start) {
+ /* no overlap */
+ } else {
+ found = True;
+ break;
+ }
}
curr = curr->next;
}
@@ -944,10 +944,10 @@ ULong VG_(di_notify_mmap)( Addr a, Bool
is_ro_map = False;
# if defined(VGA_x86) || defined(VGA_ppc32) || defined(VGA_mips32) \
- || defined(VGA_mips64)
+ || defined(VGA_mips64) || defined(VGA_amd64)
is_rx_map = seg->hasR && seg->hasX;
is_rw_map = seg->hasR && seg->hasW;
-# elif defined(VGA_amd64) || defined(VGA_ppc64be) || defined(VGA_ppc64le) \
+# elif defined(VGA_ppc64be) || defined(VGA_ppc64le) \
|| defined(VGA_arm) || defined(VGA_arm64)
is_rx_map = seg->hasR && seg->hasX && !seg->hasW;
is_rw_map = seg->hasR && seg->hasW && !seg->hasX;
This is against Debian's source tree, however. I hope that doesn't cause too
much problem.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 390698] Edges of transformed windows are jaggy
https://bugs.kde.org/show_bug.cgi?id=390698 Fredrik Höglund changed: What|Removed |Added CC||fred...@kde.org --- Comment #12 from Fredrik Höglund --- I have also been thinking about this problem, and here is how I would solve it: Multisample rendering is enabled by effects in prePaintScreen() by setting a new PAINT_SCREEN_MULTISAMPLE flag. When this flag is set, the scene creates a multisample render target and a pushes it to the render target stack in finalPaintScreen(). At the end of painting, the scene resolves the render target by blitting it to the backbuffer. When a window has a complex transformation, it is first rendered untransformed on the base level of an offscreen mipmap texture. Miplevels > 0 are then generated - preferably using a higher quality filter than the default. The texture is then drawn on the framebuffer using an anisotropic texture filter. To draw the texture, a new quad type is needed - WindowQuadCombined. This quad type is effectively the union of the shadow, decoration and content quads. This is the only quad type that should be transformed by effects such as wobbly windows. This new quad type and method of rendering is coincidentally also what is needed to make wayland subsurfaces conformant. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 390698] Edges of transformed windows are jaggy
https://bugs.kde.org/show_bug.cgi?id=390698 --- Comment #14 from Fredrik Höglund --- MSAA doesn't blur anything. It works by computing a pixel coverage value in the range [0..1] for each rasterized fragment, and multiplying that value with the alpha value prior to blending. You may be confusing it with post-processing anti-aliasing techniques, such as FXAA. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 391508] New: Kritarunner -s expects known module, not filepath
https://bugs.kde.org/show_bug.cgi?id=391508 Bug ID: 391508 Summary: Kritarunner -s expects known module, not filepath Product: krita Version: 4.0 pre-alpha Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Scripting Assignee: krita-bugs-n...@kde.org Reporter: fred...@averpil.com Target Milestone: --- kritarunner.exe --help says: -s, --script
[krita] [Bug 391508] Kritarunner -s expects known module, not filepath
https://bugs.kde.org/show_bug.cgi?id=391508 --- Comment #1 from Fredrik Averpil --- I just had a quick look at the code in plugins/pykrita/kritarunner/plugin/utilities.cpp. In Python::setPath I can see that PYTHONPATH is not being merged into Krita's search paths on Windows and in some scenarios, it is being skipped on macOS/Linux too... I'd say either _always_ merge PYTHONPATH into the search paths or _never_ do it. The latter probably being a wise choice avoid future problems (which usually turns up when users start putting stuff in their PYTHONPATH). Regardless, I want to re-iterate on that I would prefer to specify a script filepath to kritarunner. This would not only add simplicity to kritarunner, but also offer the possibility to tailor to the user's need in terms of the script's location. After having given all of this some thought, it would also be good to be able to define arguments or the function name to execute (with arguments to the function). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 393241] Previews gone after 5.45 fw update
https://bugs.kde.org/show_bug.cgi?id=393241 --- Comment #2 from Fredrik Höglund --- Please provide the output from glxinfo as well. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 390457] Task manager pixelated previews
https://bugs.kde.org/show_bug.cgi?id=390457 Fredrik Höglund changed: What|Removed |Added Latest Commit||https://commits.kde.org/pla ||sma-framework/612494e2b2e92 ||65d33ce148332d5f490b024a3bd Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Fredrik Höglund --- Git commit 612494e2b2e9265d33ce148332d5f490b024a3bd by Fredrik Höglund. Committed on 27/03/2018 at 14:42. Pushed by fredrik into branch 'master'. windowthumbnail: Use mipmap texture filtering Blit the contents of the TFP texture to a separate mipmap texture, and (re)generate the mipmaps on each damage event. This commit also fixes ARGB thumbnails being rendered as opaque. Note that this commit only modifies the GLX path. M +125 -5src/declarativeimports/core/windowthumbnail.cpp M +3-0src/declarativeimports/core/windowthumbnail.h https://commits.kde.org/plasma-framework/612494e2b2e9265d33ce148332d5f490b024a3bd -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 390698] Edges of transformed windows are jaggy
https://bugs.kde.org/show_bug.cgi?id=390698 --- Comment #22 from Fredrik Höglund --- (In reply to Vlad Zagorodniy from comment #16) > Fredrik, what do you mean by "a complex transformation"? Any transformation that does not just translate and/or scale the window. Although scaling can also benefit from this, so I guess any transformation that does not just translate the window. Some comments on the branch: There is no need to call unbind() before deleting an object - deleting an object also unbinds it from any bind points it is bound to in the current context. [libkwineffects] simplify GLRenderTarget: Please split this commit so each change is done as a separate commit. It makes the changes easier to review. I think finalPrePaintScreen() should create the render buffer and render target on-demand, and also destroy them when PAINT_SCREEN_MULTISAMPLE is not set. They consume a lot of memory, so we don't want to keep them around when they are not being used. I would rename m_multisamplingCtx to m_multisampling. Ctx suggests that it's a GL context. The changes look pretty good otherwise! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 344326] Buffer objects (VBO, FBO) need remapping after suspend/vt switch with NVIDIA
https://bugs.kde.org/show_bug.cgi?id=344326 Fredrik Höglund changed: What|Removed |Added CC|fred...@kde.org | -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 399204] New: When Return/Enter-key is pressed in session-picker, it tries to delete the selected project.
https://bugs.kde.org/show_bug.cgi?id=399204 Bug ID: 399204 Summary: When Return/Enter-key is pressed in session-picker, it tries to delete the selected project. Product: kdevelop Version: 5.2.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Session support Assignee: kdevelop-bugs-n...@kde.org Reporter: fredrik.haikarai...@gmail.com Target Milestone: --- SUMMARY When Return/Enter-key is pressed in session-picker, it tries to delete the selected session. STEPS TO REPRODUCE 1. Run KDevelop with the session picker 2. When the list comes up, and a session is selected, hit "Enter" OBSERVED RESULT A messagebox pops up asking if you really want to delete the selected session/project EXPECTED RESULT The selected session is opened SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.13 (according to pacman -Q plasma-meta) KDE Frameworks Version: 5.50.0 Qt Version: 5.11.2 (built on 5.11.1) ADDITIONAL INFORMATION Arch Linux x64 -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 399205] New: Request to use Github as primary repository and bugtracker
https://bugs.kde.org/show_bug.cgi?id=399205 Bug ID: 399205 Summary: Request to use Github as primary repository and bugtracker Product: kde Version: unspecified Platform: unspecified OS: unspecified Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: fredrik.haikarai...@gmail.com Target Milestone: --- As the title states. I'm sure this has probably been requested in the past, although I could not find a single issue for it. I think it deserves a place for discussion at least, which is why I open this as an issue. I request that development of the KDE projects are moved to Github. MY ARGUMENT The current system for contributing to KDE can be a real hassle, both in terms of submitting issues as well as contributing patches. Moving development and bugtracking to Github would open up opensource-contributions to a much wider audience, which also includes a lot of skilled and experienced developers. Github has provided a platform that has become the de-facto standard for open-source development. Moving development to Github would greatly benefit both the KDE projects themselves as well as the community in terms of feedback and response on contributions. I believe that a lot of great developers are currently held back by the hassle and steps required to contribute to these projects. ARGUMENTS AGAINST (AA) and COUNTER-ARGUMENTS (CA) AA: A lot of tools are tightly integrated into the bugtracking-system and likewise. This makes it unfeasible to work on the Github platform CA: While a move to the Github Platform would deprecate some tools, I think that many tools could be reworked to fit a new workflow. For example automatic bugtracking could be added to an internal list, that is then manually reviewed before public Github-issues are created. AA: As an opensource project, it is important for KDE that development can happen only on open-source platforms. Github would break this requirement. CA: I believe that this stance hurts KDE very much in terms of reaching its full potential. While there is nothing wrong with believing in GNU-like philosophies, I believe that putting much weight in a relatively radical standpoint while making big decisions in a huge project like this, only ends up limiting the project. Opensource doesn't always mean GPL. Sometimes opensource can mean zlib or MIT too, and that can also be beautiful and worth fighting for. Github is a platform that has literally revolutionized how opensource works, for the better, and I think its deserving of a project like KDE. I also believe the the community and the projects deserves better ways for users to contribute. Feel free to add to the discussion. I would very much appreciate it if this issue would be allowed to exist for some time. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 399205] Request to use Github as primary repository and bugtracker
https://bugs.kde.org/show_bug.cgi?id=399205 Fredrik Haikarainen changed: What|Removed |Added CC||fredrik.haikarainen@gmail.c ||om -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 399204] When Return/Enter-key is pressed in session-picker, it tries to delete the selected project.
https://bugs.kde.org/show_bug.cgi?id=399204 Fredrik Haikarainen changed: What|Removed |Added CC||fredrik.haikarainen@gmail.c ||om -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 397045] Kdevelop crashes when parsing starts [clang::Decl::setInvalidDecl]
https://bugs.kde.org/show_bug.cgi?id=397045 Fredrik Haikarainen changed: What|Removed |Added CC||fredrik.haikarainen@gmail.c ||om -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 397045] Kdevelop crashes when parsing starts [clang::Decl::setInvalidDecl]
https://bugs.kde.org/show_bug.cgi?id=397045 --- Comment #5 from Fredrik Haikarainen --- Created attachment 115046 --> https://bugs.kde.org/attachment.cgi?id=115046&action=edit New crash information added by DrKonqi kdevelop (5.2.4) using Qt 5.11.1 - What I was doing when the application crashed: After having issues with the parser not working correctly, I attempted to clear the cache and restart KDevelop. Reparsing of the project then commenced, and after a while it crashes. Sometimes instantly, sometimes after some parsing progress. Happens 7/7 times. - Unusual behavior I noticed: Before this happened, KDevelop crashed once or twice. Clearing the cache did the trick then, but it no longer works. Also, the parser has been working very badly. It doesn't recognize most header files, even though include paths are set for the project. It also misidentifies some classes as being part of the "std::"-namespace for the headers that are recognized. So if I for example declare `class Foo` in Foo.hpp, then I will get parser errors on usages of this class that suggest that I change them to std::Foo instead, (message says: did you mean std::Foo? Solutions: include Foo.hpp) - Custom settings of the application: Session has 3 projects. All are configured with regular makefiles, and uses gcc with the C++17 standard for compilation. The parser uses clang with the -std=c++17 flag. One of the projects also uses libclang as a dependency for static code generation. All KDE applications are installed via official Arch Linux repository. -- Backtrace (Reduced): #6 0x7fea5f993450 in clang::Decl::setInvalidDecl(bool) () at /usr/lib/../lib/libclangAST.so.6 #7 0x7fea5f99349c in clang::Decl::setInvalidDecl(bool) () at /usr/lib/../lib/libclangAST.so.6 #8 0x7fea58dddbc8 in clang::ASTDeclReader::VisitDecl(clang::Decl*) () at /usr/lib/../lib/../lib/libclangSerialization.so.6 #9 0x7fea58dde482 in clang::ASTDeclReader::VisitNamedDecl(clang::NamedDecl*) () at /usr/lib/../lib/../lib/libclangSerialization.so.6 #10 0x7fea58dde982 in clang::ASTDeclReader::VisitValueDecl(clang::ValueDecl*) () at /usr/lib/../lib/../lib/libclangSerialization.so.6 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 373192] Calling posix_spawn in glibc 2.24 completely broken
https://bugs.kde.org/show_bug.cgi?id=373192 Fredrik Hallenberg changed: What|Removed |Added Summary|Calling posix_spawn |Calling posix_spawn in |completely broken |glibc 2.24 completely ||broken -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 373192] Calling posix_spawn in glibc 2.24 completely broken
https://bugs.kde.org/show_bug.cgi?id=373192 --- Comment #11 from Fredrik Hallenberg --- (In reply to Philippe Waroquiers from comment #10) > Fixed in revision 16186. > Retesting welcome. I have tested with the svn version and it is still fine, thanks for the fix. -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 498516] New: Date input start at the unix epoch when manually adding a flight to a trip
https://bugs.kde.org/show_bug.cgi?id=498516 Bug ID: 498516 Summary: Date input start at the unix epoch when manually adding a flight to a trip Classification: Applications Product: KDE Itinerary Version: unspecified Platform: Android OS: Unspecified Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: vkra...@kde.org Reporter: platt...@posteo.net Target Milestone: --- *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Please remove this comment after reading and before submitting - thanks! *** SUMMARY I don't use kmail, or any other recommended tools for automatically parse an email for flight information. So I thought I would add a flight manually. I created a new trip. Added a flight to my destination — no issue inputting the data. Then today, I tried to add my flight back home. But when setting the time for departure the calendar that pops up is set to 1969-12-31 i.e. the unix epoch. Only way to scroll is by month. Sadly my flight is this year so it took a long time to scroll through each month. Also discovered that if you click the suggested date it will go back to the selected date. Discovered that after I had scrolled 10 years and tried to see if there was a way to manually input the date... And to add insult to injury, when I was done the save button was greyed out — I'm guessing I had missed to input something. But when clicking around I hit plan trip and it threw away my flight and I needed to start over. At that point I gave up. Just a note that my locale is in Swedish so I might not use the correct English terminology in the app. STEPS TO REPRODUCE 1. Add new trip 2. Manually add a flight 3. Save 4. Select trip 5. Manually add another flight 6. Press the date icon to input a date for departure, or arrival. OBSERVED RESULT Starting at the unix epoch, 1969-12-31 with only option of scrolling monthly EXPECTED RESULT Start at today's date. And also have options to input the desired date by keyboard similar to what you can do when specifying the time. SOFTWARE/OS VERSIONS GrapheneOS using Android 15 KDE Itinerary version 24.12.1 ADDITIONAL INFORMATION I tried searching for any similar bug but couldn't find any so created a new one. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 353192] Debug info/data section not detected on AMD64
https://bugs.kde.org/show_bug.cgi?id=353192 --- Comment #12 from Fredrik Tolf --- Seems either clang or lld does something different, then. The problem for me on Debian is that ld apparently merges the .data section with my .foo section into one RWX segment, and Valgrind (without patching) apparently doesn't consider a mapping without at least one pure RX and one pure RW section to be a program mapping. If you ask me, I think Valgrind should recognize mappings to load debug symbols from by their having an ELF signature, rather than by some segment property heuristic, but maybe that has other weird consequences that I haven't foreseen. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 353192] Debug info/data section not detected on AMD64
https://bugs.kde.org/show_bug.cgi?id=353192 --- Comment #10 from Fredrik Tolf --- This is still an issue, by the way. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 344326] Buffer objects (VBO, FBO) need remapping after suspend/vt switch with NVIDIA
https://bugs.kde.org/show_bug.cgi?id=344326 Fredrik Höglund changed: What|Removed |Added URL|https://git.reviewboard.kde |https://phabricator.kde.org |.org/r/123936/ |/D2079 CC||fred...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 368555] New: KDevelop crashes when you attempt to "Kill All Jobs" when no jobs are running
https://bugs.kde.org/show_bug.cgi?id=368555 Bug ID: 368555 Summary: KDevelop crashes when you attempt to "Kill All Jobs" when no jobs are running Product: kdevelop Version: 5.0.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: fredrik.haikarai...@gmail.com Application: kdevelop (5.0.0) Qt Version: 5.7.0 Frameworks Version: 5.25.0 Operating System: Linux 4.7.2-1-ARCH x86_64 Distribution (Platform): Archlinux Packages -- Information about the crash: - What I was doing when the application crashed: 1. Attempt to install a target 2. It fails with *** Killed process *** 3. No jobs are running, but both "Stop" and "Stop All" buttons are active, and in the job list the install job is still there. 4. Press Stop All. Arch Linux x64, using kdesudo for install, works when manually typing in commandline (kdesudo -- make -j4 install) The crash can be reproduced every time. -- Backtrace: Application: KDevelop (kdevelop), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f8ef7b1e800 (LWP 5459))] Thread 12 (Thread 0x7f8ea89c5700 (LWP 5559)): #0 0x7f8eee41f10f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f8ef5016c2b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQt5Core.so.5 #2 0x7f8ee9b401c0 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () from /usr/lib/libKF5ThreadWeaver.so.5 #3 0x7f8ee9b44978 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5 #4 0x7f8ee9b3f263 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from /usr/lib/libKF5ThreadWeaver.so.5 #5 0x7f8ee9b449d2 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5 #6 0x7f8ee9b3f263 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from /usr/lib/libKF5ThreadWeaver.so.5 #7 0x7f8ee9b421f9 in ThreadWeaver::Thread::run() () from /usr/lib/libKF5ThreadWeaver.so.5 #8 0x7f8ef5015d78 in ?? () from /usr/lib/libQt5Core.so.5 #9 0x7f8eee419454 in start_thread () from /usr/lib/libpthread.so.0 #10 0x7f8ef492b7df in clone () from /usr/lib/libc.so.6 Thread 11 (Thread 0x7f8ea91c6700 (LWP 5558)): #0 0x7f8eee41f10f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f8ef5016c2b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQt5Core.so.5 #2 0x7f8ee9b401c0 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () from /usr/lib/libKF5ThreadWeaver.so.5 #3 0x7f8ee9b44978 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5 #4 0x7f8ee9b3f263 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from /usr/lib/libKF5ThreadWeaver.so.5 #5 0x7f8ee9b449d2 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5 #6 0x7f8ee9b3f263 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from /usr/lib/libKF5ThreadWeaver.so.5 #7 0x7f8ee9b421f9 in ThreadWeaver::Thread::run() () from /usr/lib/libKF5ThreadWeaver.so.5 #8 0x7f8ef5015d78 in ?? () from /usr/lib/libQt5Core.so.5 #9 0x7f8eee419454 in start_thread () from /usr/lib/libpthread.so.0 #10 0x7f8ef492b7df in clone () from /usr/lib/libc.so.6 Thread 10 (Thread 0x7f8ea99c7700 (LWP 5557)): #0 0x7f8eee41f10f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f8ef5016c2b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQt5Core.so.5 #2 0x7f8ee9b401c0 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () from /usr/lib/libKF5ThreadWeaver.so.5 #3 0x7f8ee9b44978 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5 #4 0x7f8ee9b3f263 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from /usr/lib/libKF5ThreadWeaver.so.5 #5 0x7f8ee9b421f9 in ThreadWeaver::Thread::run() () from /usr/lib/libKF5ThreadWeaver.so.5 #6 0x7f8ef5015d78 in ?? () from /usr/lib/libQt5Core.so.5 #7 0x7f8eee419454 in start_thread () from /usr/lib/libpthread.so.0 #8 0x7f8ef492b7df in clone () from /usr/lib/libc.so.6 Thread 9 (Thread 0x7f8eaa1c8700 (LWP 5556)): #0 0x7f8eee41f10f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f8ef5016c2b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQt5Core.so.5 #2 0x7f8ee9b401c0 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () from /usr/lib/libKF5ThreadWeaver.so.5 #3 0x7f8ee9b44978 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5 #4 0x7f8ee9b3f263 in ThreadWeaver::Weaver::applyForWork(Thread
[kwin] [Bug 328122] off-screen kwin loops at 100% when using two users & x servers
https://bugs.kde.org/show_bug.cgi?id=328122 --- Comment #20 from Fredrik Höglund --- (In reply to Thomas Lübking from comment #18) > KWin has never fixed and actually cannot fix this (we'd need to track the VT > and that requires root permissions), the behavior is completely in the > driver (we just could at some point omit the code that sometimes reads the > frontbuffer - iff that turns out to be the ultimate cause) $ xprop -root | grep VT XFree86_has_VT(INTEGER) = 1 XFree86_VT(INTEGER) = 7 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 359062] New: Renaming class changes filename but not #include directives
https://bugs.kde.org/show_bug.cgi?id=359062 Bug ID: 359062 Summary: Renaming class changes filename but not #include directives Product: kdevelop Version: 4.7.1 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Language Support: CPP Assignee: kdevelop-bugs-n...@kde.org Reporter: fredrik.haikarai...@gmail.com I think the summary is pretty self-descriptive; when you rename a class (using right-click > rename "Foo"), it renames the filename of the file as well to reflect the changes (as expected and a nice feature), however it does not change any #include directives pointing to the file, leading to lots of manual labour. Reproducible: Always Steps to Reproduce: 1. Declare a class named Foo in a file called Foo.hpp 2. Create a file that #include's Foo.hpp (Foo.cpp for example) 3. Rename the class Foo to "Bar" using the renaming tool Actual Results: Any declarations, definitions and usages of class Foo are changed. The file Foo.hpp is also changed. However any #include directives pointing to Foo.hpp are not changed, making them obsolete and breaks compilation. Expected Results: Any declarations, definitions and usages of class Foo are changed. The file Foo.hpp is also changed, along with any #include directive pointing to said file. Using official Ubuntu 15.10 packages, which provides version 4.7.1 using KDE Development Platform 4.14.13 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 353192] Debug info/data section not detected on AMD64
https://bugs.kde.org/show_bug.cgi?id=353192
Fredrik Tolf changed:
What|Removed |Added
CC||fred...@dolda2000.com
--- Comment #6 from Fredrik Tolf ---
I also have this issue. The reason I have an executable data segment is because
I create a new section that is writable/executable for patchable code:
> .pushsection .genfuns,\"awx\",@progbits;
> [...]
> .popsection
This causes the linker to make the entire data segment RWX. Regardless of the
security implications, it seems Valgrind should be able to debug the file with
symbol info.
Also, while debugging Valgrind to see why it didn't load my symbols, I also
encountered what seemed to be unintentional behavior in
discard_syms_in_range(). On a completely unrelated munmap() call, it discarded
the DebugInfo for my executable because of how the in-range test is formulated.
It currently looks like this:
> if (curr->text_present
> && curr->text_size > 0
> && (start+length - 1 < curr->text_avma
> || curr->text_avma + curr->text_size - 1 < start)) {
>/* no overlap */
> } else {
>found = True;
>break;
> }
This way, `found' is set not only when the range overlaps, but also when there
is no range. I don't know if there is any information elsewhere that makes this
meaningful, but it seems to me that the test should look like this instead:
> if (curr->text_present && curr->text_size > 0) {
> if (start+length - 1 < curr->text_avma
> || curr->text_avma + curr->text_size - 1 < start) {
> /* no overlap */
> } else {
> found = True;
> break;
> }
> }
Technically, I guess this should perhaps be another report, but since it
doesn't cause any problems in and of itself, I wasn't sure how to report it. :)
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 359067] New: Auto-completion of method definitions does not follow declaration format or symbols, and breaks convention, and may also break compilation on some systems.
https://bugs.kde.org/show_bug.cgi?id=359067
Bug ID: 359067
Summary: Auto-completion of method definitions does not follow
declaration format or symbols, and breaks convention,
and may also break compilation on some systems.
Product: kdevelop
Version: 4.7.1
Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: NOR
Component: Language Support: CPP
Assignee: kdevelop-bugs-n...@kde.org
Reporter: fredrik.haikarai...@gmail.com
When you auto-complete method definitions in a source-file, the resulting code
does not follow the format or symbol-naming of the declaration.
Example:
class someClass
{
std::string const & getFoo();
}
using GCC 5.2.1 with -std=c++11 auto-completes to
const std::__cxx11::string& someClass::getFoo()
{
}
Problem 1: Different format. The const keyword is now leftsided, and the &
operator is "merged" to the return-type instead of being separated by a space.
This breaks convention of the existing codebase.
Problem 2: Different symbols. std::string auto-completes to
std::__cxx11::string, which I believe is compiler/libc++-specific (someone
please confirm), and will not compile on all systems supporting the C++11
standard.
Reproducible: Always
Steps to Reproduce:
1. Declare a function/method in a headerfile
2. Include said headerfile in a sourcefile and press ctrl+space to autocomplete
the declaration to a definition
Actual Results:
The autocompleted definition is different that the declaration
Expected Results:
The autocompleted definition follows the exact signature of the declaration,
both in terms of conventions/formatting as well as which symbols are used.
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 359067] Auto-completion of method definitions does not follow declaration format or symbols, and breaks convention, and may also break compilation on some systems.
https://bugs.kde.org/show_bug.cgi?id=359067 --- Comment #2 from Fredrik Haikarainen --- I suspect the __cxx11 thing is highly related to GCC, since its specific to their stdlib, it would make sense that anything that uses clang instead isnt affected. A proper solution would probably be to somehow detect the __cxx11 namespace in the renaming utility, and remove any instance of it that werent there before. Regarding the const placement, I dont have time to open another report atm, but please do so for me if you have time over. -- You are receiving this mail because: You are watching all bug changes.
