[plasmashell] [Bug 431675] Disk Space Usage widget should not include /snap/XXX mount points
https://bugs.kde.org/show_bug.cgi?id=431675 --- Comment #5 from Valdo --- (In reply to Nate Graham from comment #3) > Hello and thank you again for the bug report! Unfortunately we were not able > to address it yet, nor even manage to reproduce the issue ourselves. Can we > ask you to please check if this issue is still happening with Plasma 5.27? > > If it is, please change the status to REPORTED. Thanks a lot! Hi Nate, thanks for getting in touch. The issue is not present with Plasma 5.27.5. I'm not sure what to do with the status of this bug report in that case, so I leave current settings unchanged. Regards. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 421290] Filename: double quote sign (") used in filename is not kept as-is in resulting filename on disk
https://bugs.kde.org/show_bug.cgi?id=421290 --- Comment #5 from Valdo --- Created attachment 140436 --> https://bugs.kde.org/attachment.cgi?id=140436=edit File saved as « my "blah" file.txt » is actually saved as just « blah » on disk. In reply to comment #3: that's really strange... I don't face any error message (Kate 19.12.3 - KDE Frameworks 5.68.0). Instead, the file keeps being saved as « blah » (without quotation marks). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 431675] Disk Space Usage widget should not include /snap/XXX mount points
https://bugs.kde.org/show_bug.cgi?id=431675 --- Comment #1 from Valdo --- Created attachment 134921 --> https://bugs.kde.org/attachment.cgi?id=134921=edit "Disk Space Usage" widget settings (after all /snap mount points have been deselected one by one) Deselecting all /snap mount points one by one is a pain. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 431675] New: Disk Space Usage widget should not include /snap/XXX mount points
https://bugs.kde.org/show_bug.cgi?id=431675
Bug ID: 431675
Summary: Disk Space Usage widget should not include /snap/XXX
mount points
Product: plasmashell
Version: 5.18.5
Platform: Kubuntu Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: System Monitor
Assignee: plasma-b...@kde.org
Reporter: gnu4e...@netc.eu
CC: ahiems...@heimr.nl, notm...@gmail.com
Target Milestone: 1.0
Created attachment 134920
--> https://bugs.kde.org/attachment.cgi?id=134920=edit
Default aspect of the "Disk Space Usage" widget when added to the desktop
SUMMARY
For an unknown reason (at least to me), the "Disk Space Usage" widget includes
all /snap/ mount points. Why? How useful is that? IMO, it's not
useful at all.
Worse, /snap mount points invade the widget when the widget is added to the
desktop (see first screenshot), making it ugly and unreadable.
Furthermore, since there is no "[un]select all" checkbox in the widget
settings, making it a pain to deselect all /snap mount points one by one (that
requires a total of 15 clicks in my case - see second screenshot).
Lastly, the French translation of this widget ("Utilisation de l'espace des
disques dur") is too long, improvable (I'd rather suggest "Occupation des
disques") and contains a conjugation mistake (misses an S at the end).
STEPS TO REPRODUCE
1. Simply add the Disk Space Usage widget to your desktop.
OBSERVED RESULT
Many /snap/XXX mount points are visible.
EXPECTED RESULT
No /snap/XXX mount point should be visible at all.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux 5.4.0-62-generic / Plasma 5
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
ADDITIONAL INFORMATION
N/A
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 421290] Filename: double quote sign (") used in filename is not kept as-is in resulting filename on disk
https://bugs.kde.org/show_bug.cgi?id=421290 Valdo changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Valdo --- (In reply to Justin Zobel from comment #1) > Case 1 for me results in an error and I'm not sure double quotes should ever > be in filenames. > > Case 2 I can't reproduce. > > Can you please test and confirm if the case 2 issue is still occurring or if > this bug report can be marked as resolved. I'm setting status to "needsinfo" > pending your response, please change back to "reported" or "resolved" when > you respond, thanks. Thanks for you reply. What are your locale and regional language please? They may play a role, considering your Kate behaviour is totally different from mine's. * CASE 1: what kind of error message do you get? (the fact that one should or should not include double quotes in filenames is out of scope IMO) * CASE 2: meaning your filename preserves double quotes and doesn't turn them into %22, then into %2522, %252522, etc.? On my end, it still behaves as it did when I raised these bugs. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 398081] No inline option to remove splash screens installed from the KDE Store
https://bugs.kde.org/show_bug.cgi?id=398081 Valdo changed: What|Removed |Added CC||gnu4e...@netc.eu --- Comment #3 from Valdo --- Agreed, a removal option - directly accessible - would be a real plus. For the time being, there is such an option if you go to "Get new splash screens..." > "Display [Installed only]". The point is it doesn't behave as expected (asking to remove an installed splash screen does not actually remove it from ~/.local/share/plasma/look-and-feel/ - I had to remove them manually from this directory). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 --- Comment #124 from Valdo --- (In reply to Valdo from comment #122) > (In reply to toon.pepermans from comment #119) > > Would be nice if someone else with similar problems to mine could confirm > > they have the following two lines in /home/user/.xsession-errors when the > > bug occurs: > > > > org.kde.plasma: requesting config for "Folder View" without a containment! > > QObject::disconnect: Unexpected null parameter > > # or translation of "Folder View" in the first line Second occurrence for me! Still at boot time. And again these lines logged in .xsession-errors: org.kde.plasma: requesting config for "Vue de dossier" without a containment! QObject::disconnect: Unexpected null parameter QObject::disconnect: Unexpected null parameter I hope this interesting hint can be investigated by devs at the end of summer time. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 --- Comment #123 from Valdo --- (In reply to i.Dark_Templar from comment #107) > Following settings were reset for me: > desktop wallpaper > desktop icons size > all desktop icon positions > > Since I don't use desktop widgets I have no idea if they'd be reset as well. I didn't realize it at first, but when this bug hit me (still once only), the only widget I had on my desktop got removed. So it looks like widgets get reset as well. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 --- Comment #122 from Valdo --- (In reply to toon.pepermans from comment #119) > Would be nice if someone else with similar problems to mine could confirm > they have the following two lines in /home/user/.xsession-errors when the > bug occurs: > > org.kde.plasma: requesting config for "Folder View" without a containment! > QObject::disconnect: Unexpected null parameter > # or translation of "Folder View" in the first line Nice finding Toon! I'm in a situation very close to yours (Kubuntu 20.04, and same behaviour: icons sorted at boot time (only once so far) - folders first, then files - and wallpaper reset as well) except that my Kubuntu install is a FRESH one (not an upgrade from 18.04). As a matter of fact, I can also find this set of lines in file .xsession-errors (3 "Plasma Shell startup completed" ago, meaning 3 days ago - I usually boot my PC only once a day - meaning in turn that it occurred on the exact day I faced this issue - July 17th): org.kde.plasma: requesting config for "Vue de dossier" without a containment! # "Vue de dossier" means "Folder View" QObject::disconnect: Unexpected null parameter QObject::disconnect: Unexpected null parameter (last line does appear twice in the log) Whether "our bug" (leaving evidences in .xsession-errors) is the same as the initial 354802 or not, I can't really tell... (the wallpaper reset is new!) Inputs from other users facing initial bug 354802 saying whether they find the same message in .xsession-errors or not would really help triage bugs. Thanks in advance folks. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 403956] Save new file does not default to same folder as open txt file
https://bugs.kde.org/show_bug.cgi?id=403956 Valdo changed: What|Removed |Added Version|17.12.0 |19.12.3 --- Comment #5 from Valdo --- Hi everyone, I can confirm that the OP's wish is now implemented in Kate 19.12.3. However, since my own additional suggestions/requests have not been answered yet (see comments 3 & 4), I've changed the Version field of this bug to value 19.12.3 (current LTS version I guess). Can someone from the KDE team tell me if I should open a new bug to handle my own wishes? And/or at least share his/her opinion regarding these wishes? Thank you in advance. If a new bug is needed, then bug 403956 should be closed I believe. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 421290] New: Filename: double quote sign (") used in filename is not kept as-is in resulting filename on disk
https://bugs.kde.org/show_bug.cgi?id=421290
Bug ID: 421290
Summary: Filename: double quote sign (") used in filename is
not kept as-is in resulting filename on disk
Product: kate
Version: 19.12.3
Platform: Ubuntu Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kwrite-bugs-n...@kde.org
Reporter: gnu4e...@netc.eu
Target Milestone: ---
SUMMARY
Handling of double quote signs in filenames has never been satisfying with
Kate, but version 19.x might even be worst than before.
* CASE 1:
STEPS TO REPRODUCE
1. Create a new file with Kate.
2. Save it under name:
my "blah" file.txt
OBSERVED RESULT
Saved file is named:
blah
EXPECTED RESULT
Saved file should be named on disk:
my "blah" file.txt
* CASE 2:
STEPS TO REPRODUCE
1. Create a new file with Kate.
2. Click on Save button
3. Name file (but don't save yet!):
my "blah" file.txt
4. Enter some subdirectory from current location -> filename is automatically
renamed as:
my %22blah%22 file.txt
(doesn't sound bad... but wait ^^)
5. Go up one level (to the initial location) -> filename is automatically
renamed as:
my %2522blah%2522 file.txt
6. Enter some subdirectory again -> filename is automatically renamed as:
my %252522blah%252522 file.txt
7. Etc.?
OBSERVED RESULT
1. Filename changes each time a directory is entered or exited.
2. If you finally click "Save", the resulting filename is actually what it
reads, for e.g.:
my %252522blah%252522 file.txt
EXPECTED RESULT
1. Filename should not change each time a directory is entered or exited.
2. Saved file should be named on disk:
my "bla" file.txt
SOFTWARE/OS VERSIONS
Linux/KDE Plasma:
KDE Plasma Version: 5.18.4
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
ADDITIONAL INFORMATION
My Kate encoding: Unicode (UTF-8)
My Plasma regional setting: French
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 403956] Save new file does not default to same folder as open txt file
https://bugs.kde.org/show_bug.cgi?id=403956
--- Comment #4 from Valdo ---
Addendum: it looks like my suggestion #3 ("Remember Last Save Location") has
already been implemented (Kate 19.12.3). Good! However, having a related option
in Kate's preferences ("Open/Save" section) would even be better. To allow
users to check/uncheck this option.
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 403956] Save new file does not default to same folder as open txt file
https://bugs.kde.org/show_bug.cgi?id=403956 Valdo changed: What|Removed |Added CC||gnu4e...@netc.eu --- Comment #3 from Valdo --- To complete jg's request, I also have "complaints" to share regarding Kate's default save directory: 1. Why not offer a "Default Save Directory" option users could customize to their will? I totally share jg's opinion: it can be a real pain having to start from the home directory (location decided by s.o. else than the user), over and over for each new file to save. For e.g. a major part of my text files are located on a dedicated disk partition. I would like to be offered (for each new file) to save in a given directory on that partition. 2. Why not offer a "Remember Last Save Location" option, that would override the "Default Save Directory" option I suggested at section 1., that users could check (radio button)? Some people prefer to have this kind of default save behaviour. 3. Another (additional) save option could be jg's suggestion: "Remember Last Opened File Directory", that would override options I suggested at sections 1. and 2., that users could check (radio button)? 4. I'm adding another wish, a bit different in nature, but still linked to new file "saving": please _bypass_ the "File Close Confirmation" dialog box, when a) file's _current_ content is empty (whether or not users had added some text at some point in the past) _and_ b) file has never been saved to disk. Explanation: I often use Kate as a _temporary_ text editing tool, to copy/paste/rearrange some text from application A to application B. The new file I created with Kate is not meant to be saved to disk. So once emptied by me, I would like to close this temporary file without having to _confirm_ that it shouldn't be saved to disk. This is for e.g. the default behaviour of Notepad++ (very practical). Please tell me if I should open a new bug (features request) for my suggestions. - If not needed, can we change Kate's version of this bug (403956) to version 19.12.3 (since my suggestions are not implemented in version 19.12.3 - I can't tell for sure about jg's initial suggestion)? And possibly rephrase bug's title to a more generic features request? - If recommended to open a new bug (features request), can KDE team do something about this bug (403956)? I mean, take a position regarding jg's suggestion, to avoid keeping this bug open for too long (as much as possible). Thank you very much for reading, I remain available for any subsequent steps I'd have to take (just tell me). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 420614] Devices panel: "Hard disk of xxx.x GiB" displays a strange xxx.x value (NOT being GiB)
https://bugs.kde.org/show_bug.cgi?id=420614 --- Comment #1 from Valdo --- Sorry for mixing , (comma) and . (dot) in my report for the decimal separator. In French, a comma is used, in English it's a dot :) -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 420614] New: Devices panel: "Hard disk of xxx.x GiB" displays a strange xxx.x value (NOT being GiB)
https://bugs.kde.org/show_bug.cgi?id=420614 Bug ID: 420614 Summary: Devices panel: "Hard disk of xxx.x GiB" displays a strange xxx.x value (NOT being GiB) Product: dolphin Version: 19.12.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: gnu4e...@netc.eu CC: kfm-de...@kde.org Target Milestone: --- SUMMARY Wrong calculation of disk partitions' capacity? STEPS TO REPRODUCE The "Hard disk" I'm mentioning is actually a disk partition. Command 'df -k' lists a capacity of 294243128 blocks of 1K (that is, 280,6 GiB) for a given partition. OBSERVED RESULT Dolphin's "Devices" panel displays 286.1 GiB (wrong) for that partition. Note: same issue (if confirmed to be an issue - in all cases, pretty misleading) observed with kdepartitionmanager, showing 286.10 GiB. On the other hand, the Device properties (in Dolphin) show a capacity of 280,6 GiB (correct). EXPECTED RESULT According to me, Dolphin's "Devices" panel should display 280,6 GiB. Note: the same expected result goes for kdepartitionmanager. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION Not sure whether there is a link with Bug 292795 or not (KDE4 at the time). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 --- Comment #59 from Valdo --- (In reply to Claudio from comment #56) > I confirm it is fixed in 5.12.8 It looks like being solved for me as well (after 1 week). Note regarding my previous two comments: my Kubuntu is a former 14.04, later migrated to 16.04, then to 18.04. It could explain why my plasma-org.kde.plasma.desktop-appletsrc file contained some surprising data... (successfully cleaned up as I described) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802
--- Comment #55 from Valdo ---
(In reply to Valdo from comment #54)
> Anyway, I'm curious about last section of file
> ~/.config/plasma-org.kde.plasma.desktop-appletsrc. It's named
> [ScreenMapping] and seem to contain two subsections:
> itemsOnDisabledScreens=[...]
> screenMapping=[...]
> I'm tempted to manually remove them from file
> ~/.config/plasma-org.kde.plasma.desktop-appletsrc, but what would be the
> risk of doing so?...
What I did since my previous comment:
- moved all files and folders from my desktop to another location. It seemed to
me that sections "itemsOnDisabledScreens=" and "screenMapping=" did not change
(much). Note: the 2nd section was actually a 148,768 characters long line! For
which usage?... I still don't know.
- booted another GNU/Linux distro and emptied above Kubuntu sections so they
looked like:
[ScreenMapping]
itemsOnDisabledScreens=
screenMapping=
- booted Kubuntu again and moved all my files and folders back to the desktop.
2nd section ("screenMapping=") got filled again with a list of files now
present on my desktop (note: no more files from sub-sub-subfolders of my
desktop).
Desktop icons are now under my visual monitoring to see whether they get
scrambled again or not in the coming times...
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802
--- Comment #54 from Valdo ---
I'm not yet able to tell if this bug is solved with Plasma 5.12.8 or not...
All I can observe is that:
- icons seem to use more space (wider) than before.
- moving icons to the bottom of the desktop (bottom right of the screen, close
to the taskbar) is very imprecise. Icons end up "somewhere else" most of the
time, but rarely where I intend to drop them. Very frustrating.
Anyway, I'm curious about last section of file
~/.config/plasma-org.kde.plasma.desktop-appletsrc. It's named [ScreenMapping]
and seem to contain two subsections:
itemsOnDisabledScreens=[...]
screenMapping=[...]
I couldn't find any technical description of these sections (in case there is
one available somewhere, please tell me so), but I'm surprised to see that some
files are referenced in the 1st subsection ("itemsOnDisabledScreens="), while I
never connected any other physical screen to my PC in the last few years... So
what does "disabled screens" mean? Note: most of referenced files are no longer
present on my desktop (i.e. already moved elsewhere or trashed).
2nd subsection ("screenMapping=") references a very long list of files stored
in sub-sub-subfolders of my desktop. What for?... It also appears that none of
these files are present on my desktop today.
I'm tempted to manually remove them from file
~/.config/plasma-org.kde.plasma.desktop-appletsrc, but what would be the risk
of doing so?...
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 --- Comment #53 from Valdo --- (In reply to Christoph Feck from comment #51) > Claudio uses 5.12.7, but this bug says it was fixed for 5.12.8. Keeping open > because of comment #41 (which unfortunately lacks Plasma version > information). Plasma 5.12.8 has just hit Kubuntu 18.04 end users via the official updates channel \o/ -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 --- Comment #36 from Valdo --- I'd like to share my gratitude with all people who took time to analyze this awful bug and develop a fix. Still requires to hit end-users of course and prove its efficiency, but that's already a big step forward, so thank you! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 --- Comment #11 from Valdo --- In Bug 360212, file .config/plasma-org.kde.plasma.desktop-appletsrc what pointed out by some users as being the one storing icons position. Q1. Could KDE devs please confirm this is correct AND the only file storing information about files position on the desktop? Comment #12 (https://bugs.kde.org/show_bug.cgi?id=360212#c12) suggested that this file gets monitored to identify which process gets a read/write access (first logical step to identify the faulty process). Q2. Could KDE devs explain how users hit by this bug can set up this kind of monitoring on their PC? Which tool should be used for this? How to configure it? This is the only way to progress on the resolution of this very annoying bug. Users are willing to help as much as they can (as you can imagine), but KDE devs have to step in and give a hand... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 --- Comment #10 from Valdo --- Created attachment 116418 --> https://bugs.kde.org/attachment.cgi?id=116418=edit Before: 4 clean rows of icons. After shutdown/restart... a total mess. I recently made a new test in order to see "to which extent" my Plasma 5.12.6 desktop would get disorganized. So I sorted desktop icons manually in 4 rows, all aligned to the left: row #1 with MP3 files (grey) ; row #2 with PDF files (red) ; row #3 with text files (white) ; row #4 with all other kinds of files. I shut down my PC for the night. On the following day at startup, here is what my desktop looked like... No need to say it's getting painful to find a given file I wish to open... And this bug hits almost every day! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354802] Desktop Icon position gets scrambled sometimes on reboot.
https://bugs.kde.org/show_bug.cgi?id=354802 Valdo changed: What|Removed |Added CC||woualere.agn...@laposte.net -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 360212] Icon positions in folder view of the desktop are often scrambled after reboot or logout
https://bugs.kde.org/show_bug.cgi?id=360212 --- Comment #42 from Valdo --- (In reply to Valdo from comment #40) > This is an interesting > question however, because I have the feeling - so far - that depending on > the name of the first file/icon present at the top/left of my desktop, this > bug goes into action or not. Precisely, folders containing either a dash or > a parenthesis in their name SEEM to trigger the bug. I'm not 100% sure, so > I'll try sticking to a "conventional" naming for the 1st file/folder/icon > and see if the bug still scrambles my desktop icons or not... (probably a > bad bet ^^) "Bad bet" did I say, and I was right :) It took no long before this bug stroke again. So, as a conclusion, the naming of the first icon (top/left) has nothing to do with the triggering of the bug. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 360212] Icon positions in folder view of the desktop are often scrambled after reboot or logout
https://bugs.kde.org/show_bug.cgi?id=360212 Valdo changed: What|Removed |Added CC||woualere.agn...@laposte.net --- Comment #40 from Valdo --- Same bug here (Plasma Framework 5.44.0, that's 30 months since it was reported by Florian) and I fear I will end up crazy because of it... Reacting to some past comments: - Comment 6 (Sebastian Ernst): nothing to do with NVidia GPUs I believe, my PC being equipped with an AMD one (Radeon R7 370). My resolution: 1920x1200. Single screen display. Natural orientation (landscape) that I never change. - Comment 14 (firewalker): of course I do use national - non ASCII - characters, that's the aim of UTF-8 encoding. I can't imagine an operating system in 2018 not supporting correctly UTF-8 (although that can still happen here and there, but that's a shame nowadays). This is an interesting question however, because I have the feeling - so far - that depending on the name of the first file/icon present at the top/left of my desktop, this bug goes into action or not. Precisely, folders containing either a dash or a parenthesis in their name SEEM to trigger the bug. I'm not 100% sure, so I'll try sticking to a "conventional" naming for the 1st file/folder/icon and see if the bug still scrambles my desktop icons or not... (probably a bad bet ^^) - Comment 30 (Pasha): nothing to add. This bug has been disregarded/set aside/considered as "low priority" for too long. That makes me think of Firefox bug (feature request) 469421 that was opened 10 years ago (yes, years!) and never implemented since then... How many "improvements" were brought into Firefox since then? Tons of them. But users begging for such a common-sense feature were left aside for that long anyway... @Eike: your first comment (July 2017) was announcing the need to get in touch with some users. Was that done? HOW CAN WE HELP YOU investigate this annoying bug?... -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 392299] [Kubuntu 16.04.4] Dolphin crashed (unclear circumstances)
https://bugs.kde.org/show_bug.cgi?id=392299 --- Comment #6 from Valdo --- (In reply to Julian Schraner from comment #1) > You are using a very old version of Dolphin / Qt. Please try to reproduce > this crash with a newer version (available through the Kubuntu backports PPA > or by upgrading Kubuntu). Thanks for reporting! Sorry Julian, I totally missed your request for re-testing at the time! (I was ill) Here is my feedback (better late than never). In the meantime, I upgraded to Kubuntu 18.04 (Plasma 5.12.6 / KDE Frameworks 5.44.0). I've been UNABLE to reproduce Dolphin's crash (suspend to RAM -> wake up -> NTFS USB key plugged in -> navigate to a subfolder -> navigate up to parent folder -> right-click on the same subfolder -> Properties -> subfolder's properties display normally). I guess this bug was solved :) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 385511] Plasma crashed after connecting to an OpenVPN
https://bugs.kde.org/show_bug.cgi?id=385511 --- Comment #7 from Valdo --- I know KDE and Kubuntu teams are separate ones. Now, if Plasma 5.8 was the very first LTS, I understand there was no better solution at the time for the Kubuntu team than Plasma 5.5 (thanks for the explanation). Getting in touch with the Kubuntu team could be an option, but considering the support of Kubuntu 16.04 will end in April 2019 (9 months from now), I guess the wisest option will be to upgrade to Kubuntu 18.04 when possible :) Better concentrate on 18.04 bugs than backport an uncertain fix for a very short duration... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 385511] Plasma crashed after connecting to an OpenVPN
https://bugs.kde.org/show_bug.cgi?id=385511 --- Comment #5 from Valdo --- Thanks for your prompt reply David. It's too technical for me (I didn't get that part: "the line it refers to 566 is definitely changed and it isn't calling QAIM::dataChanged.") but never mind, at least I prefer a CLOSED status than a RESOLVED one, since I'm facing that bug every day :) So assuming Plasma 5.5.5 stopped being maintained a long time ago (funny for a Kubuntu LTS release btw), no chance there will ever be a fix, right? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 385511] Plasma crashed after connecting to an OpenVPN
https://bugs.kde.org/show_bug.cgi?id=385511
Valdo changed:
What|Removed |Added
CC||woualere.agn...@laposte.net
--- Comment #3 from Valdo ---
Created attachment 114297
--> https://bugs.kde.org/attachment.cgi?id=114297=edit
DrKonqi report (Aug. 4th 2018)
Reopening this bug to let everyone know it's NOT solved. Despite of its
previous status ("RESOLVED DUPLICATE of bug 346118" - I highly doubt it's a
duplicate).
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 392299] New: [Kubuntu 16.04.4] Dolphin crashed (unclear circumstances)
https://bugs.kde.org/show_bug.cgi?id=392299 Bug ID: 392299 Summary: [Kubuntu 16.04.4] Dolphin crashed (unclear circumstances) Product: dolphin Version: 15.12.3 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: woualere.agn...@laposte.net CC: elvis.angelac...@kde.org Target Milestone: --- Application: dolphin (15.12.3) Qt Version: 5.5.1 Operating System: Linux 4.4.0-116-generic x86_64 Distribution: Ubuntu 16.04.4 LTS -- Information about the crash: - What I was doing when the application crashed: After computer boot, KDE (5.5.5) restored my previous session. I plugged in my USB key (NTFS formatted) and chose to browse its contents with Dolphin. I entered a folder containing a 14.7 GB VMware virtual machine, then navigated up to the parent folder (root folder of my USB key) and right-clicked this same VMware folder willing to select the "Properties" option, but I just had the time to see the contextual menu appear before Dolphin crashed. -- Backtrace: Application: Dolphin (dolphin), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f221f2788c0 (LWP 12349))] Thread 8 (Thread 0x7f220a9b7700 (LWP 12609)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x7f222cc6a8b8 in _q_futex (op=0, val=3, timeout=0x0, addr=0x290abf8) at thread/qmutex_linux.cpp:146 #2 lockInternal_helper (timeout=-1, elapsedTimer=0x0, d_ptr=...) at thread/qmutex_linux.cpp:187 #3 QBasicMutex::lockInternal (this=0x290abf8) at thread/qmutex_linux.cpp:203 #4 0x7f222cc6a9ad in QBasicMutex::lock (this=0x290abf8) at thread/qmutex.h:59 #5 QRecursiveMutexPrivate::lock (timeout=-1, this=0x290abe0) at thread/qmutex.cpp:641 #6 QMutex::lock (this=) at thread/qmutex.cpp:215 #7 0x7f222cc719df in QMutexLocker::relock (this=) at ../../include/QtCore/../../src/corelib/thread/qmutex.h:146 #8 QThreadPrivate::finish (arg=arg@entry=0x291c7e0) at thread/qthread_unix.cpp:360 #9 0x7f222cc727df in __pthread_cleanup_class::~__pthread_cleanup_class (this=, __in_chrg=) at /usr/include/pthread.h:561 #10 QThreadPrivate::start (arg=0x291c7e0) at thread/qthread_unix.cpp:290 #11 0x7f22294206ba in start_thread (arg=0x7f220a9b7700) at pthread_create.c:333 #12 0x7f22320ad41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 7 (Thread 0x7f220bd2c700 (LWP 12357)): #0 0x7f2228893929 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f22288942bb in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f222889449c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f222cea97eb in QEventDispatcherGlib::processEvents (this=0x7f22040008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:420 #4 0x7f222ce50b4a in QEventLoop::exec (this=this@entry=0x7f220bd2bd00, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #5 0x7f222cc6d834 in QThread::exec (this=) at thread/qthread.cpp:503 #6 0x7f222cc727be in QThreadPrivate::start (arg=0x23f7970) at thread/qthread_unix.cpp:331 #7 0x7f22294206ba in start_thread (arg=0x7f220bd2c700) at pthread_create.c:333 #8 0x7f22320ad41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 6 (Thread 0x7f220f4b8700 (LWP 12356)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f221a0bd48b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #2 0x7f221a0bd397 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #3 0x7f22294206ba in start_thread (arg=0x7f220f4b8700) at pthread_create.c:333 #4 0x7f22320ad41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 5 (Thread 0x7f220fcb9700 (LWP 12355)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f221a0bd48b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #2 0x7f221a0bd397 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #3 0x7f22294206ba in start_thread (arg=0x7f220fcb9700) at pthread_create.c:333 #4 0x7f22320ad41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7f22106f2700 (LWP 12354)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f221a0bd48b in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #2 0x7f221a0bd397 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #3 0x7f22294206ba in start_thread (arg=0x7f22106f2700) at pthread_create.c:333 #4 0x7f22320ad41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
[kate] [Bug 390288] KIO/KDirModel: Kate crash while trying to save a new file to a Samba share
https://bugs.kde.org/show_bug.cgi?id=390288
--- Comment #2 from Valdo <woualere.agn...@laposte.net> ---
Hi Dominik,
yes I can reproduce this issue systematically.
A/ Test case avoiding the bug:
I can create an empty text file in the remote Samba share with Dolphin. Then
open that empty file with Kate, feed it with some text and save it: no issue.
B/ Test case hitting the bug:
Launch Kate, type in some text, then click Save, navigate to the "Network"
shortcut, then double-clicking "Samba shares": Kate crashes in less than a
second.
By reading the first part of bug #190535, I had the idea to launch Kate from
Konsole. As soon as I click Save (to select a destination folder), this
information displays in Konsole:
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find ""
kf5.kio.core: KSambaShare: Could not find smb.conf!
Each time I navigate to a new local subfolder, I get this information:
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find ""
Then clicking the "Network" shortcut to the left of the Save window:
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find ""
As soon as I double-click "Samba shares" to the right, I get this in Konsole:
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find ""
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find ""
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find ""
kf5.kio.widgets: Items emitted in directory QUrl("smb://") but that directory
isn't in KDirModel! Root directory: QUrl("smb:///")
Item: QUrl("smb://workgroup")
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kate path = /usr/bin pid = 1779
KCrash: Arguments: /usr/bin/kate
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from
kdeinit
sock_file=/run/user/1000/kdeinit5__0
[2]+ Arrêtékate
$
Remember my Samba share is hosted on a Linux Mint 18.3 machine. On that
machine, when right-clicking the folder shared with Samba and selecting option
"Sharing options" (or equivalent English translation), I can notice that
message: "The share name is too long" (or equivalent English translation). In
my case, the share name is "Partage Mint-land".
I hope this helps. Feel free to ask for more details if needed. And thanks for
your investigation.
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 390288] New: Kate crash while trying to save a new file to a Samba share
https://bugs.kde.org/show_bug.cgi?id=390288 Bug ID: 390288 Summary: Kate crash while trying to save a new file to a Samba share Product: kate Version: unspecified Platform: Neon Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: woualere.agn...@laposte.net Target Milestone: --- Application: kate (17.12.2) Qt Version: 5.9.3 Frameworks Version: 5.43.0 Operating System: Linux 4.13.0-32-generic x86_64 Distribution: KDE neon LTS User Edition 5.12 -- Information about the crash: - What I was doing when the application crashed: I had created a new text file and was about to save it to a Samba share hosted on another machine of mine (running Linux Mint 18.x). -- Backtrace: Application: Kate (kate), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fcf6183d900 (LWP 2425))] Thread 2 (Thread 0x7fcf40971700 (LWP 2427)): #0 0x7fcf5bf3974d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7fcf5642038c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fcf5642049c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fcf5cb696cb in QEventDispatcherGlib::processEvents (this=0x7fcf3c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x7fcf5cb11e2a in QEventLoop::exec (this=this@entry=0x7fcf40970c90, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x7fcf5c93a8f4 in QThread::exec (this=) at thread/qthread.cpp:515 #6 0x7fcf5cfe8315 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #7 0x7fcf5c93f709 in QThreadPrivate::start (arg=0x7fcf5d25cd40) at thread/qthread_unix.cpp:368 #8 0x7fcf580936ba in start_thread (arg=0x7fcf40971700) at pthread_create.c:333 #9 0x7fcf5bf4541d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7fcf6183d900 (LWP 2425)): [KCrash Handler] #6 KDirModelNode::rowNumber (this=0x0) at /workspace/build/src/widgets/kdirmodel.cpp:168 #7 KDirModelPrivate::indexForNode (this=0x2eae8f0, node=0x0, rowNumber=-1) at /workspace/build/src/widgets/kdirmodel.cpp:349 #8 0x7fcf60cb9ffa in KDirModelPrivate::_k_slotNewItems (this=, directoryUrl=..., items=...) at /workspace/build/src/widgets/kdirmodel.cpp:446 #9 0x7fcf5cb40279 in QMetaObject::activate (sender=0x2ed6340, signalOffset=, local_signal_index=local_signal_index@entry=10, argv=argv@entry=0x7329a4e0) at kernel/qobject.cpp:3766 #10 0x7fcf5cb40b87 in QMetaObject::activate (sender=, m=m@entry=0x7fcf60bc7760 , local_signal_index=local_signal_index@entry=10, argv=argv@entry=0x7329a4e0) at kernel/qobject.cpp:3628 #11 0x7fcf609500ba in KCoreDirLister::itemsAdded (this=, _t1=..., _t2=...) at /workspace/build/obj-x86_64-linux-gnu/src/core/moc_kcoredirlister.cpp:542 #12 0x7fcf6095335b in KCoreDirLister::Private::emitItems (this=0x2ac3700) at /workspace/build/src/core/kcoredirlister.cpp:2576 #13 0x7fcf609625e3 in KCoreDirListerCache::slotEntries (this=, job=, entries=...) at /workspace/build/src/core/kcoredirlister.cpp:1284 #14 0x7fcf60964000 in KCoreDirListerCache::qt_static_metacall (_o=0x7fcf60bcb1a0 <(anonymous namespace)::Q_QGS_kDirListerCache::innerFunction()::holder>, _c=, _id=, _a=) at /workspace/build/obj-x86_64-linux-gnu/src/core/moc_kcoredirlister_p.cpp:135 #15 0x7fcf5cb40279 in QMetaObject::activate (sender=sender@entry=0x2fa5540, signalOffset=, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7329a850) at kernel/qobject.cpp:3766 #16 0x7fcf5cb40b87 in QMetaObject::activate (sender=sender@entry=0x2fa5540, m=m@entry=0x7fcf60bc5c40 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7329a850) at kernel/qobject.cpp:3628 #17 0x7fcf6090b0d4 in KIO::ListJob::entries (this=this@entry=0x2fa5540, _t1=_t1@entry=0x2fa5540, _t2=...) at /workspace/build/obj-x86_64-linux-gnu/src/core/moc_listjob.cpp:266 #18 0x7fcf6090c5fa in KIO::ListJobPrivate::slotListEntries (this=, list=...) at /workspace/build/src/core/listjob.cpp:153 #19 0x7fcf6090cc7d in KIO::ListJob::qt_static_metacall (_o=, _c=, _id=, _a=) at /workspace/build/obj-x86_64-linux-gnu/src/core/moc_listjob.cpp:132 #20 0x7fcf5cb40279 in QMetaObject::activate (sender=sender@entry=0x30834d0, signalOffset=, local_signal_index=local_signal_index@entry=6, argv=argv@entry=0x7329aad0) at kernel/qobject.cpp:3766 #21 0x7fcf5cb40b87 in QMetaObject::activate (sender=sender@entry=0x30834d0, m=m@entry=0x7fcf60bc5760 , local_signal_index=local_signal_index@entry=6, argv=argv@entry=0x7329aad0) at kernel/qobject.cpp:3628 #22 0x7fcf608ec0e5 in KIO::SlaveInterface::listEntries (this=this@entry=0x30834d0, _t1=...) at
[Baloo] [Bug 338314] Bogus and duplicate info in information panel
https://bugs.kde.org/show_bug.cgi?id=338314 --- Comment #10 from Valdo <woualere.agn...@laposte.net> --- Hi, I confirm this bug is solved in KDE 5.5 (just tested successfully, thanks!), however is there a way to apply the fix to KDE 4.13? I'm still running Kubuntu 14.04 on my main machine and the bug is present... Best regards. -- You are receiving this mail because: You are watching all bug changes.
