[dolphin] [Bug 450351] New: The player on media preview should not stop on hovering a different element
https://bugs.kde.org/show_bug.cgi?id=450351 Bug ID: 450351 Summary: The player on media preview should not stop on hovering a different element Product: dolphin Version: 21.08.2 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: panels: information Assignee: dolphin-bugs-n...@kde.org Reporter: bug@petzel.at CC: kfm-de...@kde.org Target Milestone: --- When using the media player in dolphin’s information panel hovering another file will result in a removal and thus a stop of this media player. This means that on previewing media files withing dolphin (which could be a super useful thing, as it is faster than opening a media player) is quite a hassle as we must make sure not to hover anything in the meantime. Thus I’d suggest to have the media preview remain playing on hovering a file. Maybe we could even have something like if we play a media file and hover or select something else the media control for the current files goes to the top of the information panel, effectively allowing us to use the media preview without limiting the use of the file manager at the same time. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 455088] New: Have widgets remember config when switching to Alternatives
https://bugs.kde.org/show_bug.cgi?id=455088 Bug ID: 455088 Summary: Have widgets remember config when switching to Alternatives Product: plasmashell Version: 5.24.5 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: bug@petzel.at CC: k...@davidedmundson.co.uk Target Milestone: 1.0 When switching to an alternative on a widget like kickoff or the task bar the old widget is removed and a new one is created. This has the effect of loosing all config of this widget. We could allow the configuration to also store for each Applet configurations of different plugins. Then switching to an alternative could store and recover such configurations. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 467033] New: Make the KATE preview plugin support additional mimetypes by external programs
https://bugs.kde.org/show_bug.cgi?id=467033 Bug ID: 467033 Summary: Make the KATE preview plugin support additional mimetypes by external programs Classification: Applications Product: kate Version: unspecified Platform: Archlinux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: plugin-preview Assignee: kwrite-bugs-n...@kde.org Reporter: bug@petzel.at Target Milestone: --- The preview plugin currently relies on the current document having a KPart able to view the current file. This strongly limits the use of the plugin. Often we are working with non preview-able files that are compiled to a preview-able file. Examples might be a TeX documents or Lilypond scores, which are turned into .pdf files using an external program. I think it would increase the use cases for the preview plugin significantly if we could get it to handle such cases. One thing that could be done for example is to allow specification of output files for certain Mimetype, e.g. to have a configuration telling the preview plugin that e.g. on a file file.tex it should attempt to locate file.pdf for preview. Maybe this could even include an optional call to an external program so that updating the preview automatically renders the document using the given program (although this is not particularly important, as one can already configure such actions e.g. on save). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwallet] [Bug 456986] New: KWallet occasionally looses wallet on irregular shutdown
https://bugs.kde.org/show_bug.cgi?id=456986 Bug ID: 456986 Summary: KWallet occasionally looses wallet on irregular shutdown Product: frameworks-kwallet Version: 5.96.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: va...@kde.org Reporter: bug@petzel.at CC: kdelibs-b...@kde.org Target Milestone: --- Occasionally it happens that after some sort of hard shutdown (such as powerloss or having to REISUB) KWallet looses it’s entire wallet file. This has happened to me twice so far. The first time major parts of my KDE config was lost, so this appears to be not strictly restrained to KWallet, but I suppose it’s most problematic for KWallet as we’d expect a Password manager to keep the passwords safe and not loose them easily. I suppose this might happen if the system shuts down while KWallet tries to write to the encrypted wallet. In any case I think that KWallet should handle it’s Wallet files more carefully, potentially creating backups before writing to the wallet and such. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwallet] [Bug 432713] New: KWallet should limit access of applications for security reasons
https://bugs.kde.org/show_bug.cgi?id=432713 Bug ID: 432713 Summary: KWallet should limit access of applications for security reasons Product: frameworks-kwallet Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: va...@kde.org Reporter: bug@petzel.at CC: kdelibs-b...@kde.org Target Milestone: --- A major problem of password managers like KWallet is that basically any application that has access to the Wallet will have full access to the Wallet. This is a HUGE security flaw, as this implies that ANY application that should use KWallet needs to be 100% trustworthy. So I suggest that KWallet should not only allow to give applications access to the whole wallet, but to limit an applications access to certain parts of the wallet. For example: One could have a default policy that an application is only allowed to access keys in the walled it created itself. If it wants to access other keys, it eighter has to explicitely get full permissions, or the user has to be prompted that this Applications wants access to a foreign key. Or something similar. Regards, Valentin -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441746] New: Make Favorites more accessible
https://bugs.kde.org/show_bug.cgi?id=441746 Bug ID: 441746 Summary: Make Favorites more accessible Product: plasmashell Version: 5.21.5 Platform: Debian testing OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Application Launcher (Kickoff) Assignee: k...@davidedmundson.co.uk Reporter: bug@petzel.at CC: mikel5...@gmail.com, plasma-b...@kde.org Target Milestone: 1.0 Hello, Most of the times I use Kicker it is to open one of a handful of applications (such as browser, e-mail client, text editor, terminal and such), for which I therefore use the favorites bar. Kickoff makes it quite hard to access these favorites quickly, because if you click on the application launcher (assuming it is in the bottom left corner) you have the list of categories between your mouse and your favorites. Thus it happens that moving the mouse towards the favorites you change the category. This is quite anoying, as it forces you to move around the mouse a lot to open a common application. Due to delays this only happens if you move your mouse slowly enough, but still it still happens. So I suggest some options how this could be solved: → Add an option to change category only on click, not on hover (or maybe a system where the hover changuing is unlocked by clicking and locked by clicking again or leaving the list or something) → Add an additional delay for activation of a category when you move the mouse into the category list (maybe even configurable?) → Add a small favorites bar of some sort to kickoff (one could potentially have a favbar as option for the primary actions bar?) → Maybe a system where if you are not in the favorites category the favorites are pushed into a bar on the right side? While some of these options would probably present an unreasonable amount of work, something like an option to change only on click should be little effort. Valentin -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 436995] New: Prevent network list from changing while selecting
https://bugs.kde.org/show_bug.cgi?id=436995 Bug ID: 436995 Summary: Prevent network list from changing while selecting Product: plasma-nm Version: 5.20.5 Platform: Debian unstable OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: applet Assignee: jgrul...@redhat.com Reporter: bug@petzel.at Target Milestone: --- When opening the widget some networks might only appear after some time potentially changing the order of the previous networks and thus leading to very annoying behaviour. E. g. in my case I’m sometimes using a VPN to access resources from the university network. Now the problem is that often right before I click on the VPN entry some network gets detected, pushing down the VPN, and thus it connects to the other network instead. So it would be nice to have some sort of behaviour where new networks will be appended to the bottom of the network list when you are currently hovering over the network list, and only be resorted when you stop hovering over the list. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 428073] New: KIO filesystem actions are very slow for small files
https://bugs.kde.org/show_bug.cgi?id=428073 Bug ID: 428073 Summary: KIO filesystem actions are very slow for small files Product: frameworks-kio Version: unspecified Platform: Debian unstable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kio-bugs-n...@kde.org Reporter: bug@petzel.at CC: kdelibs-b...@kde.org Target Milestone: --- Created attachment 132618 --> https://bugs.kde.org/attachment.cgi?id=132618&action=edit IO using cp and kcp Copying files over KIO is significantly slower than native filesystem actions when performing on many small files. I did a test with 4 files of 50K for a) On a tmpfs cp took about a second, kcp took about 6 seconds. I guess this is a good measure of the cpu overhead of KIO copy. b) On a hard drive cp took about 53 seconds, kcp took about 3m41s. Now this is a very significant difference. I monitored the process in KSysGuard, and I found that copying over KIO leads to much less reading operations per second and a much lower reading speed, as you can see from the attached screenshots. (kcp reads data at about 1/10 of the rate of cp!) I guess one possible reason for this could be an artificial limit to read ops to prevent system freezes on copy operations? -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 496719] New: When using automatic line breaks length can be at most 78 characters
https://bugs.kde.org/show_bug.cgi?id=496719 Bug ID: 496719 Summary: When using automatic line breaks length can be at most 78 characters Classification: Applications Product: kmail2 Version: 6.2.3 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: composer Assignee: kdepim-b...@kde.org Reporter: bug@petzel.at Target Milestone: --- When setting the automatic line break column to something higher than the default of 78 it has no effect. While it is generally advised to keep this value a good bit under 80 I think it is not a good if the configuration interface allows for larger values, but doesn’t use it. I would thus suggest either limiting the numeric input to the hard limit the program imposes, or alternatively to remove that hard limit and maybe display a warning when a higher value is entered. -- You are receiving this mail because: You are watching all bug changes.
