[valgrind] [Bug 392855] valgrind reports 1 additional allocation and 1024 additional bytes allocated (again...)
https://bugs.kde.org/show_bug.cgi?id=392855
--- Comment #9 from David Rankin ---
Phillip, after further discussion on StackOverflow about this bug and the
problems with valgrind improperly reporting more memory allocated than the user
allocated in his code, this is the best rundown I can give you:
For all time, on Linux/gcc, valgrind accurately reported the number of bytes
allocated by the user and provided proper exclusion files to mask any
additional system memory allocated by the system not explicitly allocated in a
call to `malloc, calloc or realloc` by the user.
It properly showed this behavior on Archlinux, openSuSE, Ubuntu, Debian, Slack
and any other distribution I ever ran valgrind on up through the 3.12 release.
Beginning with the 3.13 release, the system allocated memory (not required by
the user) was no longer properly excluded in the memory reported in-use by
valgrind. This dramatically decreased the usefulness of valgrind as a tool for
new users as the questions always surfaced, "What is this additional memory I
didn't allocate", e.g.
https://stackoverflow.com/questions/53026992/extra-allocs-valgrind?noredirect=1#comment92967899_53026992
All versions up through 3.12, for example reported the following for a simple
example:
#include
#include
int main (void) {
int *a = malloc (sizeof *a);
*a = 5;
printf ("a: %d\n", *a);
free (a);
}
Compile:
gcc -Wall -Wextra -pedantic -Wshadow -std=gnu11 -Ofast -o /tmp/bin/vgtest2
vgtest2.c
Version Info (openSuSE Leap 42.3)
gcc --version
gcc (SUSE Linux) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Valgrind Output:
valgrind ./bin/vgtest2
==6686== Memcheck, a memory error detector
==6686== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==6686== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==6686== Command: ./bin/vgtest2
==6686==
a: 5
==6686==
==6686== HEAP SUMMARY:
==6686== in use at exit: 0 bytes in 0 blocks
==6686== total heap usage: 1 allocs, 1 frees, 4 bytes allocated
==6686==
==6686== All heap blocks were freed -- no leaks are possible
==6686==
==6686== For counts of detected and suppressed errors, rerun with: -v
==6686== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Perfect, 4-bytes request, 4-bytes allocated, 4-bytes reported by valgrind.
Now let's look at openSuSE Leap 15 which updated to valgrind 3.13, with
gcc --version
gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(using the same source file compiled with the same options)
valgrind ./bin/vgtest2
==9642== Memcheck, a memory error detector
==9642== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9642== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9642== Command: ./bin/vgtest2
==9642==
a: 5
==9642==
==9642== HEAP SUMMARY:
==9642== in use at exit: 0 bytes in 0 blocks
==9642== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==9642==
==9642== All heap blocks were freed -- no leaks are possible
==9642==
==9642== For counts of detected and suppressed errors, rerun with: -v
==9642== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
That's not right. The user only allocated 4-bytes of memory, not 1024-bytes.
Whatever exclusion files used to correctly mask the 1020-bytes not requested by
the user are no longer doing their job. And Note: this is a very rudimentary
example, when checking allocations on a normal sized example program, it's not
uncommon to have 10,000 additional bytes reported as allocated when the user
may have only required 300-bytes.
Not let's turn to ArchLinux with valgrind version 3.14, the exact same problem
of excess memory reporting by valgrind continues, e.g.
gcc --version
gcc (GCC) 8.2.1 20180831
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(same code same compiler options)
valgrind ./bin/vgtest2
==23174== Memcheck, a memory error detector
==23174== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==23174== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==23174== Command: ./bin/vgtest2
==23174==
a: 5
==23174==
==23174== HEAP SUMMARY:
==23174== in use at exit: 0 bytes in 0 blocks
==23174== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==23174==
==23174== All heap blocks were freed -- no leaks are possible
==23174==
==23174== For counts of detected and suppressed errors, rerun with: -v
==23174== ERROR SUMMARY: 0 er
[valgrind] [Bug 392855] valgrind reports 1 additional allocation and 1024 additional bytes allocated (again...)
https://bugs.kde.org/show_bug.cgi?id=392855 --- Comment #7 from David Rankin --- Created attachment 114754 --> https://bugs.kde.org/attachment.cgi?id=114754=edit xtmemory.kcg.16050 Attached is the xtmemory.kcg.16050. The same problems continue in gcc (GCC) 8.2.0 with Valgrind-3.14.0.GIT and LibVEX. The problem appears to be the allocations for the printf family. This is running on Linux 4.18.5 (Archlinux) on AMD x86_64. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392855] valgrind reports 1 additional allocation and 1024 additional bytes allocated (again...)
https://bugs.kde.org/show_bug.cgi?id=392855 David Rankin <drankina...@suddenlinkmail.com> changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #5 from David Rankin <drankina...@suddenlinkmail.com> --- But that is what I'm saying, with gcc 7.3 it is still broken with -O0, e.g. $ gcc -S -O0 -o vgtest_noopt.asm vgtest2.c $ cat vgtest_noopt.asm .file "vgtest2.c" .text .section.rodata .LC0: .string "a: %d\n" .text .globl main .type main, @function main: .LFB5: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 subq$16, %rsp movl$4, %edi callmalloc@PLT movq%rax, -8(%rbp) movq-8(%rbp), %rax movl$5, (%rax) movq-8(%rbp), %rax movl(%rax), %eax movl%eax, %esi leaq.LC0(%rip), %rdi movl$0, %eax callprintf@PLT movq-8(%rbp), %rax movq%rax, %rdi callfree@PLT movl$0, %eax leave .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE5: .size main, .-main .ident "GCC: (GNU) 7.3.1 20180406" .section.note.GNU-stack,"",@progbits valgrind still reports the wrong memory allocation. This time 1028-bytes (showing the 4-bytes allocated for the int, but a magic 1024 more) $ valgrind ./bin/vgtest_noopt ==17950== Memcheck, a memory error detector ==17950== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==17950== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==17950== Command: ./bin/vgtest_noopt ==17950== a: 5 ==17950== ==17950== HEAP SUMMARY: ==17950== in use at exit: 0 bytes in 0 blocks ==17950== total heap usage: 2 allocs, 2 frees, 1,028 bytes allocated ==17950== ==17950== All heap blocks were freed -- no leaks are possible ==17950== ==17950== For counts of detected and suppressed errors, rerun with: -v ==17950== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Thank you for looking at this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392855] valgrind reports 1 additional allocation and 1024 additional bytes allocated (again...)
https://bugs.kde.org/show_bug.cgi?id=392855 --- Comment #3 from David Rankin <drankina...@suddenlinkmail.com> --- Tom, I do think you were on to the cause, but this appears to be an issue that will need to be fixed between valgrind and libc. The assembly generated on openSuSE Leap 42.3 with gcc 4.8.5 shows a malloc, so I suspect this is where valgrind tabulates the amount of memory allocated. However on the new gcc 7.3, there is no 'call malloc' in the generated assembly which leaves valgrind to report some default allocation block size. Wherever this bug belongs, it need to be fixed. It makes no sense from a teaching standpoint to have to say: "Look at the valgrind output, but only look at the number of allocations and frees to validate you have freed the memory you allocated. You can't really look at the amount allocated because valgrind doesn't correctly report the amount of memory allocated anymore..." This tool needs to work correctly from that standpoint as well. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392855] valgrind reports 1 additional allocation and 1024 additional bytes allocated (again...)
https://bugs.kde.org/show_bug.cgi?id=392855 David Rankin <drankina...@suddenlinkmail.com> changed: What|Removed |Added Resolution|INVALID |--- Ever confirmed|0 |1 Status|RESOLVED|REOPENED --- Comment #2 from David Rankin <drankina...@suddenlinkmail.com> --- There is definitely a problem with either valgrind or libc. For Example, OpenSuSE Leap 42.3 correctly reports the number of allocations and the amount of memory allocated. $ valgrind ./bin/vgtest2 ==4142== Memcheck, a memory error detector ==4142== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==4142== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==4142== Command: ./bin/vgtest2 ==4142== a: 5 ==4142== ==4142== HEAP SUMMARY: ==4142== in use at exit: 0 bytes in 0 blocks ==4142== total heap usage: 1 allocs, 1 frees, 4 bytes allocated ==4142== ==4142== All heap blocks were freed -- no leaks are possible ==4142== ==4142== For counts of detected and suppressed errors, rerun with: -v ==4142== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) That is with: gcc --version gcc (SUSE Linux) 4.8.5 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The assembly generated is: $ gcc -S -Ofast -o vgtest2.asm vgtest2.c $ cat vgtest2.asm .file "vgtest2.c" .section.rodata.str1.1,"aMS",@progbits,1 .LC0: .string "a: %d\n" .section.text.startup,"ax",@progbits .p2align 4,,15 .globl main .type main, @function main: .LFB21: .cfi_startproc pushq %rbx .cfi_def_cfa_offset 16 .cfi_offset 3, -16 movl$4, %edi callmalloc movl$5, %esi movq%rax, %rbx movl$5, (%rax) movl$.LC0, %edi xorl%eax, %eax callprintf movq%rbx, %rdi callfree popq%rbx .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE21: .size main, .-main .ident "GCC: (SUSE Linux) 4.8.5" .section.note.GNU-stack,"",@progbits Now on Archlinux, valgrind incorrectly reports the amount of memory allocated: $ gcc --version gcc (GCC) 7.3.1 20180406 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ valgrind ./bin/vgtest2 ==8639== Memcheck, a memory error detector ==8639== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8639== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==8639== Command: ./bin/vgtest2 ==8639== a: 5 ==8639== ==8639== HEAP SUMMARY: ==8639== in use at exit: 0 bytes in 0 blocks ==8639== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==8639== ==8639== All heap blocks were freed -- no leaks are possible ==8639== ==8639== For counts of detected and suppressed errors, rerun with: -v ==8639== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) The generated assembly is different: gcc -S -Ofast -o vgtest2.asm vgtest2.c $ cat vgtest2.asm .file "vgtest2.c" .text .section.rodata.str1.1,"aMS",@progbits,1 .LC0: .string "a: %d\n" .section.text.startup,"ax",@progbits .p2align 4,,15 .globl main .type main, @function main: .LFB24: .cfi_startproc leaq.LC0(%rip), %rdi subq$8, %rsp .cfi_def_cfa_offset 16 movl$5, %esi xorl%eax, %eax callprintf@PLT xorl%eax, %eax addq$8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE24: .size main, .-main .ident "GCC: (GNU) 7.3.1 20180406" .section.note.GNU-stack,"",@progbits Now something is broken in the valgrind reporting of memory allocated. It can't work correctly -- and then not work correctly -- and ho, hum, something must have change Yes, there is a bug somewhere. If this isn't a valgrind bug, then I would appreciate suggestions on who the proper owner for the bug is. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392855] New: valgrind reports 1 additional allocation and 1024 additional bytes allocated (again...)
https://bugs.kde.org/show_bug.cgi?id=392855
Bug ID: 392855
Summary: valgrind reports 1 additional allocation and 1024
additional bytes allocated (again...)
Product: valgrind
Version: 3.13.0
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: drankina...@suddenlinkmail.com
Target Milestone: ---
Devs,
This is an issue that appears to be a regression of a bug reported to Arch in
June 2016 and has stayed fixed, but now it back again. The arch bug is:
https://bugs.archlinux.org/task/49681
Basically valgrind started reporting an additional allocation and an additional
1024 bytes of memory allocated (for just about every allocation). Within the
last couple of days (I suspect related to changes in gcc-glibc) it now reports
the correct number of allocations, but still reports at least 1024 additional
bytes, e.g.
#include
#include
int main (void) {
int *a = malloc (sizeof *a);
*a = 5;
printf ("a: %d\n", *a);
free (a);
}
valgrind reports:
valgrind ./bin/vgtest2
==15274== Memcheck, a memory error detector
==15274== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==15274== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==15274== Command: ./bin/vgtest2
==15274==
a: 5
==15274==
==15274== HEAP SUMMARY:
==15274== in use at exit: 0 bytes in 0 blocks
==15274== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==15274==
==15274== All heap blocks were freed -- no leaks are possible
==15274==
==15274== For counts of detected and suppressed errors, rerun with: -v
==15274== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
So instead of correctly reporting 4-bytes, valgrind now reports 1024 bytes.
There appears to be a regression not properly handled by the exclusions.
--
You are receiving this mail because:
You are watching all bug changes.
[konsole] [Bug 383976] newer vim outputs $q q on konsole (broken xterm-256color compatibility)
https://bugs.kde.org/show_bug.cgi?id=383976 David Rankin <drankina...@suddenlinkmail.com> changed: What|Removed |Added CC||drankinatty@suddenlinkmail. ||com --- Comment #3 from David Rankin <drankina...@suddenlinkmail.com> --- Just for the sake of completeness, this effects all versions of konsole back to 3.5.10. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 374193] New: konqueror - view -> Addn'l Info -> size/date will not stay set independently in linked view
https://bugs.kde.org/show_bug.cgi?id=374193 Bug ID: 374193 Summary: konqueror - view -> Addn'l Info -> size/date will not stay set independently in linked view Product: konqueror Version: Git Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konq-b...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 103011 --> https://bugs.kde.org/attachment.cgi?id=103011=edit attachment 1 - showing config of left/right windows that is lost on restart Version 5.0.97 KDE Frameworks 5.29.0 Qt 5.7.1 (built against 5.7.1) The xcb windowing system When setting konqueror to provide the traditional left (folder) / right (file detail) view, changes to the additional information shown in the left (folder) or right (file detail) windows does not stay set and is not saved in the File -> Session -> Save As, settings. When setting konqueror to look/behave in its traditional (kfmclient Profile filemanagement) or (konqueror --profile filemanagement) configuration, I display the folder list "locked" in the left pane and I want to turn off all "additional information" (all you care about in the navigation pane is the folders). However, I should be able to display the 'size', 'type', or 'date' in the right window and have that setting be persistent between sessions. After configuring to my liking, closing konqueror and restarting and choosing my saved session, does not restore the additional information in only the right side. What happens is all additional information is either 'completely gone in both windows' (if I was turning off the unwanted 'size', 'date', etc in the left (folder) pane, or the additional information is present in both 'left/right' windows (if I last enabled 'size', 'date', etc. in the right windows). This is frustrating as heck to take the time to pick though the setting to configure konqueror so that it provides the functionality that was provided by default setting in the past only to have konqueror lose the setting on restart or on minimize/restore. Attachment 1 shows the way I configure konqueror and save the session. When konqueror is restarted, either 'size', 'date' will be shown in both sides, or will be missing from both sides. This must be fixed. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 373888] New: kdiff3 functionality missing from konqueror 5 and is not shown in Right-Click context menu
https://bugs.kde.org/show_bug.cgi?id=373888 Bug ID: 373888 Summary: kdiff3 functionality missing from konqueror 5 and is not shown in Right-Click context menu Product: konqueror Version: Git Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konq-b...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- When clicking a file or folder, there is no KDIFF3 integration in the context menu that allows you to either 'save file for later comparison' or compare files with kdiff3 when that plugin is installed. This has always been vital to konqueror. When rt-clicking a file or folder, the KDIFF3 context menu entry should appear and provide the traditional functionality is has provided. It is currently missing. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 373887] konqueror 'linked' view fails to update path in location bar (no default filemanagement session)
https://bugs.kde.org/show_bug.cgi?id=373887
--- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> ---
This looks to be somewhat the result of not having any predefined session for
'--profile filemanagement' (or webbrowsing, etc..) under the (now)
File->Sessions->{manage,save as}. If those were set at compile time, then I
suspect you have a lot more control over this type behavior than the user is
given in the current, very limited, settings for konqueror. (for example:
settings->Filemanagement -- the entire settings page has 2 little checkboxes
for the entire layout) Where before that page provided options for:
[ ] Open folders in separate windows (the only one shown for konq5)
[ ] Show network operations in a single window (functionality missing)
[ ] Show file tips (functionality missing)
[ ] Show previoew in file tips(functionality missing)
[ ] Rename icons inline
Home URL: (functionality missing)
[ ] Show 'Delete' context menu entries which bypass the trashcan (present!)
Ask Confirmation For
[ ] Move to trash (functionality missing)
[ ] Delete (functionality missing)
You could easily add an option here for
Linked View
[ ] Selection of file/folder updates path in Location bar
and have the location bar path update with focus set on a file or folder in any
of the linked views.
--
You are receiving this mail because:
You are watching all bug changes.
[konqueror] [Bug 373887] New: konqueror 'linked' view fails to update path in location bar (no default filemanagement session)
https://bugs.kde.org/show_bug.cgi?id=373887 Bug ID: 373887 Summary: konqueror 'linked' view fails to update path in location bar (no default filemanagement session) Product: konqueror Version: Git Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konq-b...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102871 --> https://bugs.kde.org/attachment.cgi?id=102871=edit attachment 1 - showing focus on 'david' home folder but location bar still showing '/' Version 5.0.97 KDE Frameworks 5.29.0 Qt 5.7.1 (built against 5.7.1) When try to get reasonable behavior for navigating directories in the left-pane (where they have always gone in --profile filemanagement) and 'link' the directories (which appears to be the only way to have konqueror be more than a kommander split-view) selecting any directory on the left does not update the path in the 'location bar'. attachment 1 shows this setup where my home directory is selected on the left side, but the location bar still shows '/' as the current directory. This is unexpected and just plain wrong. When clicking anywhere lower in the filesystem tree, the location bar should reflect the current path to the file or directory with focus. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 373866] konqueror directory 'F9' and normal shortcuts gone in frameworks 5
https://bugs.kde.org/show_bug.cgi?id=373866 David Rankin <drankina...@suddenlinkmail.com> changed: What|Removed |Added Attachment #102865|0 |1 is obsolete|| --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102867 --> https://bugs.kde.org/attachment.cgi?id=102867=edit attachment 1 - showing drag where single-click should place focus for focus follows mouse users replacement for original snapshot which omitted the mouse cursor. The mouse cursor shows where a single-click should provide the focus for the file/folder without having to do a 2-pixel drag. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 373866] New: konqueror directory 'F9' and normal shortcuts gone in frameworks 5
https://bugs.kde.org/show_bug.cgi?id=373866 Bug ID: 373866 Summary: konqueror directory 'F9' and normal shortcuts gone in frameworks 5 Product: konqueror Version: Git Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konq-b...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102865 --> https://bugs.kde.org/attachment.cgi?id=102865=edit attachment 1 - showing drag where single-click should place focus for focus follows mouse users Version 5.0.97 Pressing 'F9' in konqueror no longer open the home, root, services, system, media left side view pane. The best you can do is a kludgy side-by-side view, but THANK YOU FOR FIXING katepart preview in advanced text editor!! We now how preview with SYNTAX HIGHLIGHTING working again!! The focus model is still all screwed up for users of 'single-click' focus follows mouse, and there is no way to click to the right of the filename to provide focus to the file or folder (and it is totally bewildering why dragging over 2-pixels provides the focus just fine, but for reasons unexplained the konquer dev has been unable to provide that same functionality with a click in the same area...) See attachment 1 for an example of a 2-px drag doing what a single-click should. The jury is still out on whether this will provide the replacement konqueror for power-users we were promised when kde4 gave us the dumbed-down dolphin, but this looks like a step in the right direction. Thanks for fixing katepart preview, and I'll work with this and provide additional requests as warranted. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373737] New: Desktop Effects - Present Windows - Window Descriptions Unreadable
https://bugs.kde.org/show_bug.cgi?id=373737 Bug ID: 373737 Summary: Desktop Effects - Present Windows - Window Descriptions Unreadable Product: plasmashell Version: master Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: drankina...@suddenlinkmail.com CC: bhus...@gmail.com, plasma-b...@kde.org Target Milestone: 1.0 Created attachment 102823 --> https://bugs.kde.org/attachment.cgi?id=102823=edit attachment 1 - snapshot of 'Present Windows' with descriptions unreadable When there are a number of applications open and the default "Present Windows" activity is activated (by mouseover top-left of the desktop) the resulting display of window descriptions are unreadable. There needs to be some type of check on the size of the scaled window to either reduce the window description font size so the description that plasma generates fits within the window shown, or allow the description to wrap so it is readable rather than clip. It appears the description is currently shown 'centered' and clipped at both ends of the text widget the description is display within. Attachment 1 - is a snapshot showing the problem with the window descriptions unreadable. -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 373719] kcalc only displays 40-bits of 64-bit number in binary and lacks binary display in all but Numeral mode
https://bugs.kde.org/show_bug.cgi?id=373719 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102816 --> https://bugs.kde.org/attachment.cgi?id=102816=edit attachment 2 - kcalc KDE3 showing proper 64-bit binary display in any 'Mode' KDE3 kcalc showing proper display of 64-bit number available in every 'Mode' -- You are receiving this mail because: You are watching all bug changes.
[kcalc] [Bug 373719] New: kcalc only displays 40-bits of 64-bit number in binary and lacks binary display in all but Numeral mode
https://bugs.kde.org/show_bug.cgi?id=373719 Bug ID: 373719 Summary: kcalc only displays 40-bits of 64-bit number in binary and lacks binary display in all but Numeral mode Product: kcalc Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: ete...@alum.rit.edu Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102815 --> https://bugs.kde.org/attachment.cgi?id=102815=edit attachment 1 - kcalc in plasma limited to display of 40-bit binary Version 16.08.3 KDE Frameworks 5.28.0 Qt 5.7.0 (built against 5.7.0) kcalc cannot display any more than 40-bits of a binary number and the window cannot be resized. Attachment 1 shows the maximum 40-bits the new plasma kcalc is capable of displaying. Attachment 2 shows the full 64-bits properly displayed in KDE3 kcalc. The new plasma version needs to be fixed to include proper functionality to display a 64-bit binary number. Further, plasma kcalc lacks the functionality to display a binary representation of a number in every mode but 'Numeral System Mode'. In KDE3 this was available in every mode with 'Logic Buttons' selected. It wasn't a separate 'Mode' where you could only look at a binary representation if you flipped kcalc to some 'Mode', it was simply an option available in every mode. kcalc should be fixed to properly allow display of binary, octal, hex, and decimal in any 'Mode' as it was capable of doing a decade ago. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 373464] New: lines (leaders) no longer drawn before folders in sidebar folder view (F9)
https://bugs.kde.org/show_bug.cgi?id=373464 Bug ID: 373464 Summary: lines (leaders) no longer drawn before folders in sidebar folder view (F9) Product: konqueror Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: sidebar Assignee: fa...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102701 --> https://bugs.kde.org/attachment.cgi?id=102701=edit attachment 1 - snapshot of konqueror window showing missing leaders highlighted version 4.14.25 using kde platform 4.14.26 The lines (leaders) that are drawn in folder-view in konqueror sidebar are no longer drawn. Further the [+] and [-] symbols (or the goofy >) are not shown either. At first I thought it was drawn in black on a dark background and just hard to see, but then changing to a light color confirmed, they are simply not being drawn. Clicking where the [+] and [-] should be drawn still expands/collapses the directory tree, but it is just a guess for how far from the folder you need to click. This started fairly recently. They were present several versions back if I recall correctly. See attachment 1 for a screenshot showing the highlighted area where the leaders are missing. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 373462] New: Kate help - Kate (C++) Application Plugins -- broken link to Git "Hello World" source
https://bugs.kde.org/show_bug.cgi?id=373462 Bug ID: 373462 Summary: Kate help - Kate (C++) Application Plugins -- broken link to Git "Hello World" source Product: kate Version: 16.08 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- In the kate help documentation page "Kate (C++) Application Plugins" the link 'http://quickgit.kde.org/?p=kate.git=tree=addons%2Fkate%2Fhelloworld' is broken in the sentence "There is also a classic “Hello, world!” example plugin included with the Kate source code." Clicking on the link results in a Git repository error "Invalid request" -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 373008] kate/kwrite autocomplete typecast in ternary deletes variable after conditional
https://bugs.kde.org/show_bug.cgi?id=373008 --- Comment #2 from David Rankin <drankina...@suddenlinkmail.com> --- OK, Laughing... That's what that option does for which there is no help available or '?' tooltip to determine. Yes, that option is getting unchecked. But KUDOS!!! to the awesome dev that knew "A new feature is a bug if it cannot be turned off!" and was smart enough to provide an option to disable it. Now, if you can just pass that around to the rest of the KDE team who dream up the latest "gotta have feature" that "everybody will just love..." and fail to include an option to disable it, that would be a huge leap forward. Good job KDE team on providing user control to this feature. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372909] glibc 2.23+ fopen/printf change causes valgrind to report 1024 byte allocation
https://bugs.kde.org/show_bug.cgi?id=372909 David Rankin <drankina...@suddenlinkmail.com> changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372909] glibc 2.23+ fopen/printf change causes valgrind to report 1024 byte allocation
https://bugs.kde.org/show_bug.cgi?id=372909 --- Comment #2 from David Rankin <drankina...@suddenlinkmail.com> --- Really?? You don't see the difference?? total heap usage: 0 allocs, 0 frees, 0 bytes allocated -- CORRECT total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated -- FUBAR Same code... -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 373216] Spectacle - save-as dialog attempt to overwrite filename instead of loading it for edit on click
https://bugs.kde.org/show_bug.cgi?id=373216 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102597 --> https://bugs.kde.org/attachment.cgi?id=102597=edit attachment 2 - immediately thrown warning on click of filename to load name The warning message thrown when you click on any existing filename in the save-as dialog -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 373216] New: Spectacle - save-as dialog attempt to overwrite filename instead of loading it for edit on click
https://bugs.kde.org/show_bug.cgi?id=373216 Bug ID: 373216 Summary: Spectacle - save-as dialog attempt to overwrite filename instead of loading it for edit on click Product: Spectacle Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102596 --> https://bugs.kde.org/attachment.cgi?id=102596=edit attachment 1 - spectacle save-as dialog with name after click/cancel of warning Ver 16.08.3 KDE Frameworks 5.28.0 Qt 5.7.0 (built against 5.7.0) If you need to save a sequence of images, but need to give them different names (e.g. image_1234_buttons.png, image_1234_dialog.png, etc...) the spectacle save-as dialog attempts to overwrite the existing image immediately when you click on the filename in the file save-as dialog instead of loading the filename into the filename edit-box and waiting for the user to modify/save. This is unexpected behavior and different from the way most of the other file save-as dialogs work in kde (so much for consistency). When you choose save as, the dialog shown in attachment 1 appears. When you click on a filename an immediate warning is thrown to the screen (see attachment 2) This should not occur and the warning is premature. Instead, clicking on the filename should load the filename in the filename box for the user to edit. If, and only if, the user fails to change the filename and presses save such that the original file would be overwritten -- then the warning dialog should appear. The spectacle save-as should not actually attempt to write to the file when the filename is clicked to load it for editing. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 373215] Spectacle no longer shows thumbnail/preview after snapshot
https://bugs.kde.org/show_bug.cgi?id=373215 --- Comment #3 from David Rankin <drankina...@suddenlinkmail.com> --- This should not make any difference, but at the time spectacle was called, both Firefox and LibreOffice were open. I don't know if having 2 high-res gtk apps open when spectacle is called breaks the preview. the preview worked fine when kde3/ksnapshot was called to document this bug. I thought I would pass this information along for completeness. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 373215] Spectacle no longer shows thumbnail/preview after snapshot
https://bugs.kde.org/show_bug.cgi?id=373215 --- Comment #2 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102595 --> https://bugs.kde.org/attachment.cgi?id=102595=edit attachment 3 - method of screenshot capture Image of ksnapshot which was required to document this problem since spectacle is not capable of multiple instances. That means it is totally useless to capture images of anything related to spectacle operation. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 373215] Spectacle no longer shows thumbnail/preview after snapshot
https://bugs.kde.org/show_bug.cgi?id=373215 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102594 --> https://bugs.kde.org/attachment.cgi?id=102594=edit attachment 2 - showing result of drag on preview area Snapshot showing result of drag on invisible preview. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 373215] New: Spectacle no longer shows thumbnail/preview after snapshot
https://bugs.kde.org/show_bug.cgi?id=373215 Bug ID: 373215 Summary: Spectacle no longer shows thumbnail/preview after snapshot Product: Spectacle Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102593 --> https://bugs.kde.org/attachment.cgi?id=102593=edit Spectacle showing no preview but with tool tip of image size With the latest release of spectacle ver. 16.0.8.3 KDE Frameworks 5.28 Qt 5.7.0 (built against 5.7.0) Spectacle no longer show the preview after the screenshot is taken. (see the first attachment with tooltip showing a preview of the image is present for an image of 314x171 pixels). You can also grab the blank area with the mouse and drag it which reveals the image (see attachment 2 showing drag of invisible preview). The image is actually there because it saves. Which brings up another HUGE bug with spectacle -- it's too dumb to be able to take a picture of itself. So the only way I had to produce these diagnostic snapshots was to run kde3/ksnapshot via ssh to capture the problem with plasma spectacle - which I could thankfully save to my web server via the sftpkio -- something else that is broken in spectacle. (see attachment or image capture) I don't know what broke with spectacle. The preview did work not too long ago. The only changes have been updates to kdebase-runtime, etc. The relevant update history is: [2016-11-25 21:59] [ALPM] upgraded kdebase-runtime (16.08.3-1 -> 16.08.3-3) [2016-11-29 03:45] [ALPM] upgraded kdebase-runtime (16.08.3-3 -> 16.08.3-4) [2016-11-29 03:45] [ALPM] upgraded kdegraphics-okular (16.08.3-1 -> 16.08.3-2) [2016-12-01 14:25] [ALPM] upgraded kdevplatform (5.0.2-1 -> 5.0.3-1) [2016-12-01 14:25] [ALPM] upgraded kdevelop (5.0.2-2 -> 5.0.3-1) That or the kdegraphics-okular update seem like likely suspects. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373101] Incorrect reflection for cylinder animation (it uses cube reflection causing it to separate at edge)
https://bugs.kde.org/show_bug.cgi?id=373101 --- Comment #3 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102541 --> https://bugs.kde.org/attachment.cgi?id=102541=edit cylinder reflection looking straight-on desktop showing reflection with cylinder looking straight-on the desktop (as it should be, it is attached at the bottom desktop edge) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373101] Incorrect reflection for cylinder animation (it uses cube reflection causing it to separate at edge)
https://bugs.kde.org/show_bug.cgi?id=373101 --- Comment #2 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102540 --> https://bugs.kde.org/attachment.cgi?id=102540=edit cylinder rotation between desktops (reflection detached) Showing the reflection detached from cylinder rotation between desktops (moving down away from the cylinder because it is using the cube rotation code) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373101] Incorrect reflection for cylinder animation (it uses cube reflection causing it to separate at edge)
https://bugs.kde.org/show_bug.cgi?id=373101 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102539 --> https://bugs.kde.org/attachment.cgi?id=102539=edit cube reflection between desktops showing proper reflection attachment at the corner of desktops with cube rotation -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373101] New: Incorrect reflection for cylinder animation (it uses cube reflection causing it to separate at edge)
https://bugs.kde.org/show_bug.cgi?id=373101 Bug ID: 373101 Summary: Incorrect reflection for cylinder animation (it uses cube reflection causing it to separate at edge) Product: plasmashell Version: master Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: drankina...@suddenlinkmail.com CC: bhus...@gmail.com, plasma-b...@kde.org Target Milestone: 1.0 Created attachment 102538 --> https://bugs.kde.org/attachment.cgi?id=102538=edit cube reflection looking straight-on at the desktop If this should go with some other component, feel free to change the selected component, there isn't a desktop effects choice. When using the cylinder animation (with zoom set at roughly 1/4), the reflection bounces up and down below the cylinder on rotation. Meaning, with reflection enabled, when you invoke the cylinder animation (e.g. win+F11 key) and tilt the cylinder toward, or away, from you about 15-20 degrees, you find the reflection properly bound to the lower edge of the desktop. Now, if you rotate the cylinder 45 degrees left/right so you are looking at the divider between desktop 1/2 (or 4/1) you see the reflection is now detached from the cylinder and it has moved down (and sometimes off the screen) depending on the amount you have the cylinder tilted toward or away from you. If you rotate the cylinder (make it spin slowly), the reflection hops up-and-down at the bottom of the screen. Why? The 'cube' reflection code is being used for the 'cylinder' rotation. That's not right -- they are separate pieces of code. Why? with the 'cylinder', the reflection distance from the cube does NOT change with rotation angle (you are rotating a circle, (the radius never changes), but with the 'cube' it does (e.g. the perpendicular distance from the center to the front edge is shorter than the distance from the center of the cube to the corner between virtual desktops) Now go perform the same test with the 'cube' animation. The reflection moves up and down to stay attached to the cube rotation as it should, both when viewing a desktop straight-on (see: cube_reflection_desktop.png) and between desktops (see: cube_reflection_corner.png) Now do it with the cylinder. The reflection is attached when viewing the desktop straight-on (see: cylinder_reflection_desktop.png), but detaches from the cylinder between desktops (see: cylinder_reflection_corner.png) The reflection should remain attached at all points during the rotation, because the distance from the center of the cylinder to the edge never changes. It looks like somebody simply forgot to implement the cylinder rotation code from compiz (it's actually much simpler than the cube model), or it may be there, but all rotations are using the cube code for rotation (I haven't tested the sphere, it has more serious issues with the skydome deformation bug), but I suspect it is using the cube rotation code as well for reflection control. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 341143] Wallpaper on every desktop is gone.
https://bugs.kde.org/show_bug.cgi?id=341143 David Rankin <drankina...@suddenlinkmail.com> changed: What|Removed |Added CC||drankinatty@suddenlinkmail. ||com --- Comment #207 from David Rankin <drankina...@suddenlinkmail.com> --- Why not just enable different wallpaper on each virtual desktop like KDE3? Choose the virtual desktop, set the wallpaper for that desktop. I have no use for activities, and could care less about widgets. To me that nonsense has been nothing but a 9 year waste of time that should be an optional package, but I do like a different wallpaper on each desktop. There is no reason anyone should have to set 10 different activity and widget settings just to have a different wallpaper on each virtual desktop work and have the task manager and desktop switcher still continue to function correctly. As of Frameworks 5.28.0 and Qt 5.7.0, there is still no simple way to put a different wallpaper on each virtual desktop in system settings. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 373009] New: indention following single-statement loop over-indents the following command, must undo twice
https://bugs.kde.org/show_bug.cgi?id=373009
Bug ID: 373009
Summary: indention following single-statement loop over-indents
the following command, must undo twice
Product: kate
Version: 16.08
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: indentation
Assignee: kwrite-bugs-n...@kde.org
Reporter: drankina...@suddenlinkmail.com
Target Milestone: ---
Indent config: Soft Tabs: 4 (Indent using spaces)
If you attempt to add an additional line before the next statement after a
single-statement loop in a C source, autoindent indents the statement on the
current line 3-levels too many. Example, save the following as a C-source (e.g.
bug.c)
while (whatever) printf ("please fix indentation.\n");
return 0;
(make sure it has 4-spaces, a single level of indention before it in the file,
e.g. select it and press ctrl+i) Now place the cursor at the insertion point
immediately before the 'r' in 'return' (or at the beginning of the line) and
press enter ('.' inserted to preserve spacing below):
while (whatever) printf ("please fix indentation.\n");
..return 0;
That is 14-spaces before 'return' instead of the expected `4`. The expected
result is simply 4-spaces before each line with a blank line in between the
commands. Moreover, `14` spaces??? That should never happen anyway with 'Soft
Tabs: 4' set. Your indents are at 12 or 16, but never 14, something is borked.
Now try and 'undo' (e.g. ctrl+z). You can't in one step. You have to undo
twice. You should never have to 'undo' twice for the result of a single
keystroke. One keystroke, one undo should restore to the previous state.
Both of these make the indent model in kate/kwrite seems clumsy and broken.
With more than a decade using kate/kwrite, these bugs were never present and
the indent model in kde3. That indent model was very elegant and enjoyable to
use for C, C++, php, html, etc.. There were never any surprises and it was
rock-solid. The current indent model is more annoying than helpful in many
circumstances. A slip of the finger attempting to insert a 'single-quote' that
hits enter key and inserts a new line now takes '2 ctrl+z' to undo and restore
the editor state. That's just broken and a symptom of fundamental problems with
the current indent model. Is that a problem with KDE or Qt?
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 373008] New: kate/kwrite autocomplete typecast in ternary deletes variable after conditional
https://bugs.kde.org/show_bug.cgi?id=373008 Bug ID: 373008 Summary: kate/kwrite autocomplete typecast in ternary deletes variable after conditional Product: kate Version: 16.08 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- In kate/kwrite in a C source, attempting to insert a typecast before the variable name in the 'true condition' of a ternary causes autocomplete to overwrite/delete the variable name. This is reproducible 100% of the time. Example, save the following a as a C-source file (e.g. bug.c) /* attempt to insert (ssize_t) as typecast following '?' with autocomplete * will cause autocomplete to delete 'idx' resulting in: * * return idx ? (ssize_t : -1; * * after accepting the proposed autocomplete */ return idx ? idx : -1; Now, with autocomplete enabled, attempt to insert '(ssize_t)' prior to the 'idx' following the '?'. [ e.g. start typing '(ssiidx' ] When autocomplete suggests 'ssize_t in the autocomplete window, hit 'return' to accept the proposal. 'idx' is delete leaving only: return idx ? (ssize_t : -1; -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 372208] kwrite File -> New directory fails to follow current, defaults to $HOME
https://bugs.kde.org/show_bug.cgi?id=372208 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- This occurs with both kate and kwrite. When you open a new session in kate (or a file in kwrite) and save a source file at $HOME/prg/src-c/tmp/debug. If you then create a new document (ctrl+n) and attempt to save the second file. Instead of offering to save the document in the directory where the first file was just saved, kate/kwrite defaults to asking to save in $HOME, instead of in $HOME/prg/src-c/tmp/debug. This requires that you again navigate to the directory of interest. That is unexpected behavior. Similarly, if you use dolphin or konqueror to navigate and open a file in kwrite (or kate, depending on you file association order set in file properties), then 'save-as' in a new directory, kwrite or kate will always default to saving all new documents created with (ctrl+n) to the directory where the first file was opened, completely ignoring the directory where the most recent file was saved. This seems to be the same failure to update the directory information based on the last save. For more than a decade I've used kate/kwrite and I have never had a problem with them not remembering and following the last saved directory. This should be common to the file save dialog in KDE, not just kate/kwrite, but it is very much a problem when dealing with multiple source files in a highly nested directory structure. This is occurring with: Kate/Kwrite Versions 16.08.3 Kate Part version 5.28 KDE Frameworks 5.28.0 Qt 5.7.0 (built against 5.7.0) The xcb windowing system Let me know if you need any additional information, I'm happy to provide anything needed to help get this fixed. This, along with the other handful of bugs I've filed recently, are the top annoyances I find in trying to use Plasma/FW5, moving from KDE3. These very simple things, that have always just worked correctly in KDE, are what made KDE so wonderfully efficient and a joy to use. It is very notable when these things don't work. I'm committed to helping make Plasma/FW5 as efficient and enjoyable to use as KDE3, but the simple things that make KDE KDE, really need to work. There is no reason anyone should ever have to repeatedly click down a 10 component directory path just to save a file in the same location. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372909] New: glibc 2.23+ fopen/printf change causes valgrind to report 1024 byte allocation
https://bugs.kde.org/show_bug.cgi?id=372909
Bug ID: 372909
Summary: glibc 2.23+ fopen/printf change causes valgrind to
report 1024 byte allocation
Product: valgrind
Version: 3.12 SVN
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: drankina...@suddenlinkmail.com
Target Milestone: ---
OS: Archlinux x86_64, valgrind 3.12, glibc 2.24
I'm not sure whether this has been previously reported, but with the change to
printf in glibc 2.23, valgrind now reports 1024 bytes allocated when printf (or
any of the printf family of function) are used. (It was explained to me as
being related to the following mmap to malloc change:
https://sourceware.org/bugzilla/show_bug.cgi?id=16734) This results in the
unexpected reporting of memory allocated, where before the same code would
report none. Example:
#include
int main (int argc, char **argv) {
char *s = argc > 1 ? argv[1] : "hello valgrind";
printf ("%s\n", s);
return 0;
}
Expected Heap Summary:
$ valgrind ./bin/hello
==9626== Memcheck, a memory error detector
==9626== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9626== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==9626== Command: ./bin/hello
total heap usage: 0 allocs, 0 frees, 0 bytes allocated
Actual Heap Summary:
$ valgrind ./hello
==18061== Memcheck, a memory error detector
==18061== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==18061== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==18061== Command: ./hello
total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
I don't know whether a new exclusion needs to be written or what, but I cannot
see this being expected behavior from valgrind.
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 372486] kate/kwrite bracket highlight off by 1 set - highlights previous open instead of current
https://bugs.kde.org/show_bug.cgi?id=372486 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102241 --> https://bugs.kde.org/attachment.cgi?id=102241=edit Screenshot of Improper Bracket Highlight in Ver. 16.08.3 Screenshot showing improper activation of preceding bracket set for assignment of 'pp' when cursor is at the bracket closing position for the 'popen' command. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 372486] New: kate/kwrite bracket highlight off by 1 set - highlights previous open instead of current
https://bugs.kde.org/show_bug.cgi?id=372486
Bug ID: 372486
Summary: kate/kwrite bracket highlight off by 1 set -
highlights previous open instead of current
Product: kate
Version: 16.08
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: kwrite-bugs-n...@kde.org
Reporter: drankina...@suddenlinkmail.com
Target Milestone: ---
Created attachment 102240
--> https://bugs.kde.org/attachment.cgi?id=102240=edit
Screenshot of Proper Bracket Highlight of Enclosed Parenthetical
kate/kwrite ver. 16.08.3.
The bracket highlight in kate/kwrite highlights the previous set's opening
bracket instead of the opening for the current bracket set. Take for example
the following C code (with the cursor position denoted by the pipe '|'):
if (!(pp = popen (cmd, "r")|)) {
In all previous versions of kate/kwrite the open parenthesis '(' before command
would be highlighted by bracket highlight to show the closing parenthesis just
typed would be closing the set related to the 'popen' command, e.g.
popen (cmd, "r")
This is the expected behavior. A screenshot is attached showing the expected
proper highlighting as it currently works in k3 kwrite.
Inexplicably, the bracket highlight in version 16.08.3 highlights the opening
parenthesis before the assignment when the cursor is in the position shown.
This is unexpected behavior and horribly distracting as the highlight should
not display until the closing parenthesis is on the left of the current
insertion point -- not to the right of the insertion point.
--
You are receiving this mail because:
You are watching all bug changes.
[basket] [Bug 372456] Empty notes not removed, tag shortcuts duplicated on customize, not applied within note
https://bugs.kde.org/show_bug.cgi?id=372456 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Note: the font-size combo list mix up (e.g. font sizes as 7 9 9 10 11) is intermittent and will display all sizes correctly most of the time. -- You are receiving this mail because: You are watching all bug changes.
[basket] [Bug 372456] New: Empty notes not removed, tag shortcuts duplicated on customize, not applied within note
https://bugs.kde.org/show_bug.cgi?id=372456 Bug ID: 372456 Summary: Empty notes not removed, tag shortcuts duplicated on customize, not applied within note Product: basket Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kel...@ieee.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- I have about 10 years of notes in basket and I would be in big trouble without it. The current Arch package of 1.8.1 is against KDE Platform Version 4.14.26 in KDE Frameworks 5.27.0, Qt 5.7.0 (built against 5.7.0). There are real problems with basket 1.81 in plasma. For starters, the following are broken or provide unexpected behavior: 1) if you click and a new empty note is created, and you didn't mean to, it does not automatically get deleted when you click somewhere else. Stray empty notes were always auto-removed in the past. This can quickly lead to your baskets turning into a giant mess; 2) 'Tags' shortcuts are duplicated and generate errors for duplicate keystrokes when you "Customize Tags" and then 'save'. It is like the list of shortcuts is duplicated in memory causing basket to think each shortcut for a tag is a duplicate. Quitting basket and restarting clears the duplicates from memory, but this means you have to shutdown/restart basket if you change 'any' tag setting; 3) Changing a tag (like Title) does not update all Title tagged items in the list; 4) Clicking in a note and applying a tag doesn't apply the formatting if the note already contained a tag. It is like the signals and slots get mixed up after the first time a tag is applied (something is also funny with the font-size combo-list, at times it will report available font sizes as 7 9 9 10 11, ... and you must manually enter 8 because it doesn't display in the list; 5) Grouping is totally unpredictable. (probably in large part due to the problem in (1) above.) Any unintended click slightly above/below the current note baseline (when the Config > General > [ ] group note option is use) creates a mess quickly. Now there is simply a pixel or two difference between the note trying to group 'above' or group 'below' the current when clicking to the right side of the insertion line. 6) Configure > General > System Tray Icon [ ] Show main window when mouse hovers over the system tray icon for 7 tenths -- no longer works at all. This is probably due to some change in the systray in plasma, but this was a brilliant time saving option that should be continued. (the balloon notices for Global shortcut actions no longer works as well) I'm sure these are fixable and baskets is well worth the effort. Let me know if I can provide an further information. I'm happy to do it. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 372409] New: Background for Rectangular Region Interferes with Region Selection
https://bugs.kde.org/show_bug.cgi?id=372409 Bug ID: 372409 Summary: Background for Rectangular Region Interferes with Region Selection Product: Spectacle Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Version 16.08.3 - Sorry For Any Inconvenience KDE Frameworks 5.27.0 Qt 5.7.0 (built against 5.7.0) The xcb windowing system When capturing a rectangular region Spectacle shades the screen obscuring the details needed to mark the start and end of the desired capture region. Changing the preferences, unselecting [ ] Use light background color, does not remove the shading, but makes the shading dark making it virtually impossible to see the screen at all on laptops. There should be a way to completely disable this shading entirely as it makes it more difficult in many cases to select the desired rectangular region. ksnapshot worked perfectly without any shading allowing you to accurately capture the region of interest. The shading makes it impossible to determine where to start/stop a region when attempting to avoid parts of gradients, etc... forcing yet another import into gimp to clean up what should have been a simple screen grab. I would include a screenshot showing the problem, but since spectacle can't even run a multiple instance -- that is impossible too. (frustrating, when ksnapshot had none of these issues) -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 372408] Spectacle Capture Active Window includes Unwanted Margin Outside Active Window
https://bugs.kde.org/show_bug.cgi?id=372408 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Note: the space around the 'Active Window' shown in the snapshot is actually transparent in color, but is shown in KDE as a solid color based on your current color scheme. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 372408] New: Spectacle Capture Active Window includes Unwanted Margin Outside Active Window
https://bugs.kde.org/show_bug.cgi?id=372408 Bug ID: 372408 Summary: Spectacle Capture Active Window includes Unwanted Margin Outside Active Window Product: Spectacle Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102195 --> https://bugs.kde.org/attachment.cgi?id=102195=edit Screenshot Showing Areas Outside Active Window (in blue) Version 16.08.3 KDE Frameworks 5.27.0 Qt 5.7.0 (built against 5.7.0) The xcb windowing system Spectacle Capture Active Window includes an unwanted additional 10-15 pixel margin or buffer around the outside of the Active Window causing the user to have to manually crop every image taken just to get an actual snapshot of the current window. This is incredibly cumbersome and frustrating. Why would capture 'Active Window' be grabbing an additional 10-15 pixels outside the current window? Expected behavior - when capturing any window, especially the 'Active Window' spectacle should only capture the 'Active Window' without including any extraneous margin or buffer outside the 'Active Window' A screenshot is attached showing the unwanted additional info captured outside the active window -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 372407] Edit Scheme Color Preview Not Working (black & white only) and No Update
https://bugs.kde.org/show_bug.cgi?id=372407 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102194 --> https://bugs.kde.org/attachment.cgi?id=102194=edit General Dialog Preview General 'Application Color Scheme' dialog that does show static colors of current scheme on entry into kcm_color module -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 372407] New: Edit Scheme Color Preview Not Working (black & white only) and No Update
https://bugs.kde.org/show_bug.cgi?id=372407 Bug ID: 372407 Summary: Edit Scheme Color Preview Not Working (black & white only) and No Update Product: systemsettings Version: 5.8.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: kcm_colors Assignee: mwoehlke.fl...@gmail.com Reporter: drankina...@suddenlinkmail.com CC: jpwhit...@kde.org Target Milestone: --- Created attachment 102193 --> https://bugs.kde.org/attachment.cgi?id=102193=edit Edit Preview System Settings > Appearance > Colors > Edit Scheme > [Colors tab] The color preview for the current scheme shown at the top of the dialog when the colors tab is selected does not reflect the current color scheme and does not respond to any changes to the color scheme. Of all the color scheme previews in KDE, this is the one that must work to aid the color scheme setting changes. Expected behavior - upon selecting the color tab the preview should reflect the current color scheme. Upon a change of a color setting, the preview should update to reflect the change. This does not happen. (in fact, it doesn't appear to work at all) The preview box shown on the general 'Application Color Scheme' dialog does at least have colors shown when you enter the 'Colors' part of System Settings, but it ignores any changes made during editing. On selection of 'Edit Scheme' > [Colors] tab, the preview box shown appears to have only 2 colors (gray and darker gray). (see screenshot 'Editing Preview') It does not reflect the colors for the current scheme being edited and it fails to shown any changes made to the scheme. (at first I though maybe it only displays 'changes' so I set all text to Red to test -- nope, it just doesn't display any color and does not work at all) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 372353] New: Independent zoom needed for 'cube', 'cylinder', and 'sphere' animations
https://bugs.kde.org/show_bug.cgi?id=372353 Bug ID: 372353 Summary: Independent zoom needed for 'cube', 'cylinder', and 'sphere' animations Product: systemsettings Version: 5.8.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Originally, there were settings to set the 'zoom' independently for the 'cube', 'cylinder', and 'sphere' animations. (in Compiz 0.8.8, etc...) This was needed because each scale at wildly different rates. For example, currently setting the zoom for the cube (say 25%) makes the sphere unusable and makes the cylinder animation too small. Setting the zoom to make the cylinder look right makes the cube to big and the sphere still unusable. Setting the zoom on the sphere properly, makes both the cube and cylinder tiny. In compiz, there were independent zoom settings for each for this reason. If the hooks still exist for independent settings, it would be a simple task to add the two additional sliders to kcontol > Desktop Behavior > Desktop Effects > Settings > Advanced (tab) (where the current single zoom control is located) If the independent zoom code wasn't implemented in plasma (or where ever it goes in the current code), it would be worth looking at what it would take to add them. A single zoom setting for all 3 animations is unworkable due to the different scaling requirements. I didn't know whether this should be a feature request of bug. It is set at bug because there is missing functionality and the current implementation does not work for all 3 animations. Feel free to bump it to a wish-list item if you view it differently. As it sits, you cannot set a zoom that makes all 3 look proper (or even roughly equal in zoom for that matter) Let me know if you need screenshots. This is fairly self-explanatory. Just set the zoom at different level and look at each of the animations. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 372351] New: sphere cap deformation incorrectly scales sphere radius (should be cap radius only)
https://bugs.kde.org/show_bug.cgi?id=372351 Bug ID: 372351 Summary: sphere cap deformation incorrectly scales sphere radius (should be cap radius only) Product: systemsettings Version: 5.8.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102173 --> https://bugs.kde.org/attachment.cgi?id=102173=edit Snapshot of 'sphere cap deformation' at 50% The 'sphere cap deformation' slider does not work on the 'sphere caps', instead it works by scaling the whole sphere into an oval which causes the desktop to fly off the sphere with a setting anywhere close to 50% or above. This is wrong, (an incorrect implementation). The desktop portion of the sphere should remain unchanged regardless of the sphere cap deformation, and only the radius of the 'caps' should reduced as the 'cap deformation' increases (toward the plane end of the slider). Screenshot showing 50% cap deformation squishing the whole sphere causing desktop to fly off included. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 372309] New: Appearance -> Colors -> Edit Scheme (dialog breakup on vertical expand)
https://bugs.kde.org/show_bug.cgi?id=372309 Bug ID: 372309 Summary: Appearance -> Colors -> Edit Scheme (dialog breakup on vertical expand) Product: systemsettings Version: 5.8.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: kcm_colors Assignee: mwoehlke.fl...@gmail.com Reporter: drankina...@suddenlinkmail.com CC: jpwhit...@kde.org Target Milestone: --- Created attachment 102161 --> https://bugs.kde.org/attachment.cgi?id=102161=edit Snapshot showing 'Edit scheme' dialog breaking apart exposing blank dialog. Version 5.8.3 When expanding the Appearance -> Colors -> Edit Scheme dialog vertically, the dialog does not properly expand the 'Color set:' portion to maximize editing the color scheme list of colors. Instead the 'Window text' widget and the 'Color set:' widgets separate and break apart wasting 1/3 to 1/2 of the 900px screen with completely wasted space. When maximizing the dialog vertically, the 'Color set:' widget should be the only widget that expands maximizing the space available for editing the color-scheme instead of just expanding the blank window behind the widgets. Screenshot included: -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 372224] New: Unable to 'save as' document opened in dolphin back to original network location
https://bugs.kde.org/show_bug.cgi?id=372224 Bug ID: 372224 Summary: Unable to 'save as' document opened in dolphin back to original network location Product: kio Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: fa...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- This applies to the latest build: KDE Frameworks 5.27.0 Qt 5.7.0 (built against 5.7.0) The xcb windowing system Opening a document from dolphin via either smb:// or sftp:// in e.g. libreoffice, there is no way to 'save as' back to the same network share. The problem appears to be with the temporary file created in $HOME/.cache/kioexec/krun/. The 'save as' dialog does not relate to the original location of the file, but instead to the temporary location created in .cache/kioexec/krun. This effectively prevents any meaningful use of network stored documents. I have confirmed this behavior with both smb:// and sftp:// kio-slaves. This may be related to, but is not a duplicate of, https://bugs.kde.org/show_bug.cgi?id=253547 (this involves the simple access of and saving of documents, not streaming contents) The sftp:// kio will work correctly from some kde applications (e.g. kwrite), but does not work at all from others like spectacle and does not work from libreoffice (even with KDE integration) In KDE file 'save/save as' dialog and kio should work regardless of application. At present, there is no way to 'save as' on a file opened from dolphin in libreoffice (which defeats the purpose of opening the network file to begin with unless you want to overwrite the original). The spectacle 'save as' is the subject of an existing bug, but seems related here. There is no ability to 'save as' to any network location, while in ksnapshot that was a trivial task with the sftp-kio. The ability to 'save as' using kio seems like hit-or-miss functionality in the current KDE. Without it, you are back to the decades old scheme of saving the new file locally, then scp or sftp the new file back to the proper location on the original server. That's doable and better than a floppy drive, but not really what is usable today. The expected behavior is to be able to save or 'save as' to the desired local or remote location from any KDE dialog. To reproduce, use dolphin to navigate to any remote location holding a libreoffice document and open the document. Try and 'save as' to the original location. Instead of having a path to the original server, you are presented with $HOME/.cache/kioexec/krun/. Similarly, take a snapshot with spectacle and try to 'save as' to a remote location. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 372208] New: kwrite File -> New directory fails to follow current, defaults to $HOME
https://bugs.kde.org/show_bug.cgi?id=372208 Bug ID: 372208 Summary: kwrite File -> New directory fails to follow current, defaults to $HOME Product: kate Version: 16.08 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- In kwrite (not kate - new follows current there) choosing File -> New does not preserve (or follow) the current document directory causing you to have to navigate back though the filesystem to save a new document in the current document location. Instead, kwrite defaults to $HOME for all new document saves. This is incorrect behavior. The correct behavior on File -> New is to preserve the current document directory information so saving, by default, will be to the current document directory. Instead, the default save is to $HOME. To reproduce, start kwrite, navigate to /tmp, save the current document as 'foo.txt'. Press File -> New. Attempt to save the new document. The default save is to $HOME, not /tmp as it should be. Inconsistently (and thankfully) this behavior is not observed in kate. Using kate (in the example above) will allow saving bar.txt in /tmp as it should. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 372207] New: kwrite file open dialog, filenames overwrite icons (probably all apps)
https://bugs.kde.org/show_bug.cgi?id=372207 Bug ID: 372207 Summary: kwrite file open dialog, filenames overwrite icons (probably all apps) Product: kate Version: 16.08 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102118 --> https://bugs.kde.org/attachment.cgi?id=102118=edit File open dialog showing filename overwriting file icon in dialog. When using File -> Open, filenames with the .dat, .rdf (probably any binary file) the filename is not shown correctly, instead it is shown "On Top Of" the file icon itself. This should not happen. A screenshot is attached. Look at, e.g.: localstore.rdf mailViews.dat for examples of the problem. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 372162] New: Click in Empty Region to Right of Filename Fails to Set Focus
https://bugs.kde.org/show_bug.cgi?id=372162 Bug ID: 372162 Summary: Click in Empty Region to Right of Filename Fails to Set Focus Product: dolphin Version: 16.08.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102080 --> https://bugs.kde.org/attachment.cgi?id=102080=edit Region where left-click should set focus outlined in orange In both Dolphin (Version 16.08.2) and Konqueror (Version 4.14.24) clicking in the empty region to the right of the filename fails to set focus on file or directory in single-click/focus follows mouse mode (screenshot provided). If you click and drag (even 2 pixels) then focus is properly set. There is no reason a 'click and drag' is required to set focus when a simple 'left-click' has always sufficed (preventing inadvertent selection of neighboring files). For single-click mode, focus has always been set by a single left-click to the right of the filename. With focus follows mouse, the file knows the mouse is overhead as a focus indicator is shown. Somewhere the 'click and drag' that now sets focus needs to be corrected and changed to a simple 'click'. It is horribly distracting to have to try and click-and-drag within the small region to set focus when only a simple click should be required. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 372160] Image Size Field not Populated and tooltip missing EXIF information
https://bugs.kde.org/show_bug.cgi?id=372160 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 102079 --> https://bugs.kde.org/attachment.cgi?id=102079=edit Original tooltips showing proper EXIF information Here is a screenshot of the original tooltip preview showing complete EXIF information. This information is critical for anyone doing any type of graphics work. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 372160] New: Image Size Field not Populated and tooltip missing EXIF information
https://bugs.kde.org/show_bug.cgi?id=372160 Bug ID: 372160 Summary: Image Size Field not Populated and tooltip missing EXIF information Product: dolphin Version: 16.08.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: view-engine: details mode Assignee: dolphin-bugs-n...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102078 --> https://bugs.kde.org/attachment.cgi?id=102078=edit Dolphin Preview devoid of exif Version 16.08.2 KDE Frameworks 5.27.0 Qt 5.7.0 (built against 5.7.0) The xcb windowing system When displaying the 'Image Size' field in Dolphin no information is shown for image files (screenshot attached). Additionally, the tooltip preview does not provide any of the normal exif information (height/width resolution) (normal tooltip content screenshot provided). The image tooltip should provide the: - original photo name - type - size B (KiB) - image date (generally ctime) - dimensions w x h in pixels - color depth (Bit depth) - color mode (e.g. RGB/Alpha) - compression - interlaced mode All of the foregoing information is missing from the current tooltip preview in Dolphin, and tooltip previews are just flat broken in konqueror filemanagement. -- You are receiving this mail because: You are watching all bug changes.
[kfile] [Bug 372126] New: file open/save dialog for kde4 applications does not respect single-click to open
https://bugs.kde.org/show_bug.cgi?id=372126 Bug ID: 372126 Summary: file open/save dialog for kde4 applications does not respect single-click to open Product: kfile Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 102061 --> https://bugs.kde.org/attachment.cgi?id=102061=edit File open dialog frok kde4 konqueror When using the file/open saved dailog in: KDE Frameworks 5.27.0 Qt 5.7.0 (built against 5.7.0) The xcb windowing system If the dialog is called from a kde4 application, e.g. basket, konqueror, etc..., the file open/save action requires a double-click to actually open a directory or open a file. A single-click seems to load the file or directory name into the filename edit widget, but does not actually change directory or open the file. For example, open your favorite kde4 app, (e.g. konqueror --profile filemanagement) and the press 'ctrl+o' or choose 'File -> Open'. The dialog that is presented does not work on a single-click basis. However, if you do the same with a kde5 app (e.g. kwrite, kate, etc..) the single-click to change directory, open a file, works as it should. A screenshot of the dialog at issue is provided in case it helps with identifying which dialog is at issue. This may be a regression as it seems that this has been marked fixed related to a couple of individual apps or non-kde apps, but it is not fixed now regarding kde apps (see, e.g. Bugs https://bugs.kde.org/show_bug.cgi?id=181017, https://bugs.kde.org/show_bug.cgi?id=235159) -- You are receiving this mail because: You are watching all bug changes.
[kcoloredit] [Bug 372008] kcolorchooser - focus model broken for 'Val:' slider - unresponsive to mouse wheel
https://bugs.kde.org/show_bug.cgi?id=372008 --- Comment #4 from David Rankin <drankina...@suddenlinkmail.com> --- Filed as QtBug 56897 https://bugreports.qt.io/browse/QTBUG-56897 -- You are receiving this mail because: You are watching all bug changes.
[kcoloredit] [Bug 372008] kcolorchooser - focus model broken for 'Val:' slider - unresponsive to mouse wheel
https://bugs.kde.org/show_bug.cgi?id=372008 --- Comment #3 from David Rankin <drankina...@suddenlinkmail.com> --- Christoph, thanks, good to know the kdialog trick. I find the traditional dialogs much more useful than the KF5 versions. I have run into problems over and over again with missing sftpkio, etc.. functionality in the new dialogs. I'm used to maintaining files on a server where all of my saves are to sftp://place/they/go, and the new dialogs are hit and miss on whether that is even possible. Sad, I've been working that way for over a decade and it is very frustrating to have functionality broken or removed. Will report the remaining colorchooser issues to trolltech. -- You are receiving this mail because: You are watching all bug changes.
[kcoloredit] [Bug 372009] kcolorchooser - 'Add to Custom Colors' overwrites previous custom color
https://bugs.kde.org/show_bug.cgi?id=372009 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Custom Colors are not preserved between uses of kcolorchooser. It doesn't appear any backend file saving the information. Setting a custom color, and then opening kcolorchooser again (e.g. to set a color in the Breeze theme) the previous custom colors are gone. -- You are receiving this mail because: You are watching all bug changes.
[kcoloredit] [Bug 372009] New: kcolorchooser - 'Add to Custom Colors' overwrites previous custom color
https://bugs.kde.org/show_bug.cgi?id=372009 Bug ID: 372009 Summary: kcolorchooser - 'Add to Custom Colors' overwrites previous custom color Product: kcoloredit Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: percy.camilo...@gmail.com Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Version v2.0.0 on KDE Frameworks 5.27.0 Qt 5.7.0 (built against 5.7.0) 'Add to Custom Colors' does not 'Add' it 'Wipes Out' any prior custom color unless an empty custom color slot is manually chosen. Attempting to set focus on an empty custom color slot destroys the current color selected replacing the current with #FF (this is completely broken and mimics the way M$ Win 95 color chooser worked) Color chooser has always added to the 'next available' custom color slot and the RBG values stored in .kde/share/config/colors/Custom_Colors. Now you must manually set focus on the next available slot which sets the current color to #FF -- completely unwanted behavior. Any time 'Add to Custom Colors' is chosen, it should store the current color in the next open custom color slot. When all custom colors are filled, scroll-bars should be provided to accommodate. This has worked flawlessly in the past. -- You are receiving this mail because: You are watching all bug changes.
[kcoloredit] [Bug 372008] New: kcolorchooser - focus model broken for 'Val:' slider - unresponsive to mouse wheel
https://bugs.kde.org/show_bug.cgi?id=372008 Bug ID: 372008 Summary: kcolorchooser - focus model broken for 'Val:' slider - unresponsive to mouse wheel Product: kcoloredit Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: percy.camilo...@gmail.com Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Version v2.0.0 on KDE Frameworks 5.27.0 Qt 5.7.0 (built against 5.7.0) Focus not provided for mouse wheel adjustment of 'Val:' (brightness) *slider* (on right-side of backwards color panel (ROYGBIV is backwards from previous versions) . When using focus follows mouse, the slider should take focus on mouseover and respond with 1-increment adjustments to wheel-up/wheel-down inputs. That no longer works. (possibly related to widget issues in https://bugs.kde.org/show_bug.cgi?id=136714 and https://bugs.kde.org/show_bug.cgi?id=311241) -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 371996] Embedded Advanced Text Editor Preview Missing - no syntax highlighting without
https://bugs.kde.org/show_bug.cgi?id=371996 --- Comment #1 from David Rankin <drankina...@suddenlinkmail.com> --- Created attachment 101984 --> https://bugs.kde.org/attachment.cgi?id=101984=edit Same screenshot shown in okular preview not providing highlighting Here is the same screenshot without the Embedded Advanced Text Editor preview. It is unusable compared to the proper highlighted version. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 371996] New: Embedded Advanced Text Editor Preview Missing - no syntax highlighting without
https://bugs.kde.org/show_bug.cgi?id=371996 Bug ID: 371996 Summary: Embedded Advanced Text Editor Preview Missing - no syntax highlighting without Product: konqueror Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konq-b...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 101983 --> https://bugs.kde.org/attachment.cgi?id=101983=edit Embedded Advanced Test Editor Preview screenshot KDE Frameworks 5.27, including Konqueror Version 4.14.24 Using KDE Development Platform 4.14.25 Embedded Advanced Text Editor preview is missing. The only text preview offered currently is the okular preview which is wholly ill-suited for viewing code or other text that uses syntax highlight. When a code preview is requested, it should provide katepart syntax highlighting color configurable in the settings. A screenshot is provided showing the prior syntax highlighting provided by this feature. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 371994] New: Version 4.14.24 - busy icon spins continually over file/directory names
https://bugs.kde.org/show_bug.cgi?id=371994 Bug ID: 371994 Summary: Version 4.14.24 - busy icon spins continually over file/directory names Product: konqueror Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: file list view Assignee: konq-b...@kde.org Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 101982 --> https://bugs.kde.org/attachment.cgi?id=101982=edit Screenshot showing busy-icon over file/directory names KDE Framework 5.27, including Konqueror Version 4.14.24 Using KDE Development Platform 4.14.25 New in this version. A busy icon continually spins when the mouse is moved over any file or directory name in detailed view and no tooltip previews are shown. This should not happen. Instead a preview of the file contents should be shown in the tooltip allowing for easy identification and selection of the proper file, without having to change views. A screenshot is provided showing the new multi-color spinning icon that appears. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 371993] New: Spectacle - missing kioslave interface, no sftp, and no multi-instance capability
https://bugs.kde.org/show_bug.cgi?id=371993 Bug ID: 371993 Summary: Spectacle - missing kioslave interface, no sftp, and no multi-instance capability Product: Spectacle Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: drankina...@suddenlinkmail.com Target Milestone: --- Created attachment 101980 --> https://bugs.kde.org/attachment.cgi?id=101980=edit snapshot of dialog at issue KDE Frameworks 5.27, Spectacle Version 16.08.2 - Sorry for Any Inconvenience (that puts it mildly) There is no kioslave interface in the save/save as dialog making it impossible to save the image to a remote directory. Why doesn't this rendition of ksnapshot have a normal save dialog. No matter where I am in KDE, I should have full dialog capability, just like has always been there since KDE3. An editable path component where the requested kioslave can be entered as a prefix to the path (e.g. sftp://server/path). Next, there is no ability to run multiple instances of spectacle making it impossible to take a screenshot of this issue. Instead, you have to overlay a new snapshot of the save-as dialog on top of the already full image and use gimp or some other app to crop all the unwanted junk out of the image. Just make a new instance of spectacle launch on each press of 'print screen' like it always has. (it is much more useful that way) I've attached a screenshot showing the current limited dialog that appears (I hope it is the right image, tooltip previews no longer work in this version of KDE) -- You are receiving this mail because: You are watching all bug changes.
