Yep, it should be part of the main repo meanwhile.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Sep 12 2022
Aug 22 2022
Looks like both callaudiod and its dependency libfeedback are packaged, but not submitted to Tumbleweed yet. I requested that, let's see.
Aug 21 2022
IMO all of those are valid options, no idea what's the best one. If there's someone willing to maintain it, it might even be possible to contribute to qtfeedback upstream and revive it. Only if that's for some reason not accepted by Qt upstream forking it as KDE project should be considered IMO.
qtfeedback is unmaintained since 2018, so IMO actively introducing that now is not a good idea.
Nov 30 2021
In one of the KF6 meetings, it was noted that kdesu won't work in Wayland because the latter doesn't allow GUI apps to run as root at all (IIUC).
Feb 19 2021
According to https://github.com/moby/moby/commit/a18139111d8a203bd211b0861c281ebe77daccd9, anything >= v20.10.0 should do.
Additional issue is that there's a bug in libseccomp (first issue I linked), which broke that if built against a kernel which doesn't have that syscall.
That seems to be the case for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1914939
Feb 18 2021
Dec 14 2020
It seems like there are still parts which need discussion here, so reopening.
Nov 14 2020
(Originally written on https://invent.kde.org/plasma/systemsettings/-/merge_requests/32#note_136280, so this copy doesn't have images embedded)
Nov 10 2020
I just tried that here and it works fine (Qt 5.15.1). Maybe there's something else in the environment which breaks it?
In D12405#676733, @memeplex wrote:So I set QT_SCREEN_SCALE_FACTORS='eDP-1=2;DP-2=1.7;'. But consider:
- QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCREEN_SCALE_FACTORS='eDP-1=2;DP-2=1.7;' konsole
- QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS='eDP-1=2;DP-2=1.7;' konsole
The first one correctly reduces the size of konsole (menubar, text inside the terminal emulator). The second one does nothing at all.
So since plasma seems to be deliveratelt setting QT_AUTO_SCREEN_SCALE_FACTOR=0, I don't see how this would possibly work.
Jul 11 2020
In T2050#235181, @ngraham wrote:In general I think it's sub-optimal to maintain two different tools that do essentially the same thing, even if both are working fine.
Jul 10 2020
In T2050#235112, @davidedmundson wrote:I'm against dropping something which works just because it's unmaintained as long as there is no replacement.
Ack, the original position in the email was that it's mostly duplicating functionality that now exists scattered in other places.
I'm curious about the arbitrary keypresses usage, and understanding the workflow people have for that.
Is it overlapping with the advanced features of klipper or is it a way of doing shortcut remapping...
So far khotkeys was something which "just worked" and didn't need much work on it at all.
Jun 29 2020
Jun 28 2020
Jun 13 2020
In D9875#675107, @mkoller wrote:They did not overwrite each other since the entry for the Username holds an URL _without_ user but the password entry did.
In D9875#675101, @mkoller wrote:This patch breaks usage for git (and probably others):
git first asks for a "Username for 'https:...." which leads to ksshaskpass open the input dialog but the typed-in user
is no longer stored into the wallet!!
(See case TypeClearText)
This leads to git again and again ask for the Username on each invokation.Please ensure that even the Username is stored again _in the same folder_ in kwallet as before (e.g. below Passwords)
otherwise it also breaks using existing passwords. E.g. readingif (type != TypePassword) { QByteArray retrievedBytes; wallet->readEntry(identifier, retrievedBytes);is wrong (backwards incompatible).
Jun 7 2020
May 18 2020
May 17 2020
Landed to invent - hopefully correctly: https://invent.kde.org/frameworks/kio/commit/84e9372f4fa2636f57dc456ac2fa2be271d6a7ec
May 16 2020
May 8 2020
For some reason I can't get the reminder to trigger.
May 7 2020
In D29503#665612, @ngraham wrote:I can't reproduce it, but I wonder if this could fix or help https://bugs.kde.org/show_bug.cgi?id=417488?
Apr 28 2020
Didn't test myself, but apparently you did, so LGTM.
Apr 27 2020
Apr 24 2020
In D28936#656422, @broulik wrote:this doesn't catch something like this
Yeah it doesn't. I thought I could "monitor" an Object but the caller actually has to use the Proxy for it to detect anything :/
Any ideas? :)
AFAICT (take with a grain of salt, I'm a JS n00b) this doesn't catch something like this:
FIXED-IN: 5.19.0 (or should we consider this a bugfix and land it on the stable branch?)
Apr 19 2020
Apr 18 2020
Repository R120 Plasma Workspace
Apr 17 2020
Proper fix with refactoring will take too long, let's take this for now.
Tested, works. I didn't even notice that it broke...
Apr 15 2020
In D24956#648968, @davidedmundson wrote:[14:12] <d_ed> DavidRedondo1: my understanding is that a system might ship "konsole opens with control+t" . The UI allows you to remove that. This would remove the entry in kglobalshortcutsrc, but because it's still in the system defaults file as soon as you log in again it'll add it back
[14:25] <DavidRedondo1> d_ed, fvogt Apparently the runtime writes the hidden thing when a component is cleanedUp https://cgit.kde.org/kglobalaccel.git/tree/src/runtime/kserviceactioncomponent.cpp#n135
[14:27] <DavidRedondo1> Does that fail or something when the file is not writeable?
[14:31] <DavidRedondo1> I think it fails
[14:31] <DavidRedondo1> I just tested itif it is indeed broken...then we may as well just merge this.
In D24956#648905, @davidedmundson wrote:kglobalshortcutseditor.cpp
needs updating to matchI think you're right with your reasoning about NoDisplay, but we do want something to be able to mask system files. From the spec should we be checking Hidden= ?
Apr 13 2020
Just have to make sure not to add anything to DEFAULT_EXTENSION_SETTINGS.mpris.websiteSettings now. Previously that would've been ignored.
Apr 10 2020
In D28709#645296, @broulik wrote:I've originally injected breeze scroll bar CSS as style with src in the extension but that also cause other issues where websites weren't allowed to access the different origin of the style sheet...
Looks fragile, but I don't have a better idea either.
In D28705#645038, @broulik wrote:Yeah, wondering the same... maybe it didn't. Anyway this also fixes Spotify's previous/next buttons not working since when the player is gone we clear media session actions (not sure if that is someting we should do though)
I guess spotify had unsave-eval, but not unsafe-inline, so this method just breaks different pages...
Apr 9 2020
I just tried this with google translate on FF ESR 68(.1.0 IIRC) and it worked, but there was an error about the content security policy having blocked an eval. The error is gone if the extension is disabled.
So this needs a test with spotify/nextcloud. Do you have any public URL?
I'm not sure about the // Firefox enforces Content-Security-Policy also for scripts injected by the content-script part, but I'm not sure how to test it.
Note: Remains to be tested on non-firefox and old firefox ESR.
D28709 conflicts/supersedes this now. window.Audio.prototype != Audio is a separate issue though, which might still need fixing.
Use full URL in comment
I can't find a better way to do this either...
In D28705#644982, @broulik wrote:It worked on Chrome, and the properties can be accessed from the same context.
It's just that the mutation.removedNodes loop above which is in content script cannot access those JS properties, so I had to change it, so it can.
So was the case handled by line 805 completely broken?
That sounds like a Qt bug, which fails to use the QT_SCREEN_SCALE_FACTORS value for pixmaps for some reason. Is it a multi-monitor setup? Can you open a new issue with details and a screenshot?
Apr 6 2020
For false positives the player would get added again by the playing event, which is not ideal, but as it doesn't require a reload it's IMO close enough.
In D28614#642630, @broulik wrote:If there is a false positive in the detection, how would those be handled? AFAICT the players would never appear in mpris again?
I believe whenever a player starts playing again, it is propagated through MPRIS again. The playerGone handling is no different from the player being removed from DOM and being added back.
If there is a false positive in the detection, how would those be handled? AFAICT the players would never appear in mpris again?
Apr 4 2020
Apr 3 2020
I assume there is a reason why MTPDevice::getDevice() has code for handling this very specific case, so I wouldn't just remove it without figuring out why: https://i.redd.it/hfnl7xo8yovy.gif
In D28535#640682, @feverfew wrote:In D28535#640674, @fvogt wrote:What you're suggesting is to change MTPDevice::getDevice to return the old device if reopening fails - but reopening without releasing might not work.
This seems to be a robust solution IMO, why do you suspect this might not work?
In D28535#640680, @anthonyfieroni wrote:I see we don't speak in same language :)
LIBMTP_Open_Raw_Device_Uncached(&m_rawdevice);
returns nullptr that's normal since device is inaccessible, i mean it does not need to call LIBMTP_Release_Device using m_mtpdevice is safe it's not nullptr, it's just a disconnected device and libmtp knows that.
There is no such thing as an "invalid device" at that point anymore. There's only nullptr.
In D28535#640656, @anthonyfieroni wrote:You're right about bug report, but it can fail in any other place, just in particular version it happen in updateStorageInfo Can we cache getDevice in m_device (in constructor) then use it everywhere. I think libmtp has guard against disconnected device and will not crash.
Mar 28 2020
Mar 5 2020
Do it differently, just like it's done below
In D27863#622655, @mlaurent wrote:if splitting is already done why this code re-call "m_desktopFile.desktopGroup().readEntry(QStringLiteral("Exec"), QString())" ?
=> QProcess::startDetached(commands, parts) no ?
The split arguments are already available as parts above, as used in the klauncher call AFAICT.
Mar 2 2020
Treat scripting as a feature instead
Currently processui/scripting.cpp has this:
Feb 27 2020
I need some input on how to express HAVE_QTWEBENGINEWIDGETS with this. Currently it would fail to build if Qt5WebEngineWidgets is installed but Qt5WebChannel isn't.
Feb 26 2020
In D27643#618310, @jgrulich wrote:In D27643#618132, @fvogt wrote:In D27643#618125, @jgrulich wrote:I have never used fuse. I see you can use kio-fuse over dbus to mount a file, but you still have to unmount it, which will be a problem, because from the portal I don't know whether the app is still using it or not.
kio-fuse was designed with this in mind and does not even support unmounting. When the file isn't being used anymore, it drops everything except what's needed to reopen the file when requested.
If anyone is familiar with fuse and have solution in mind, can you give me a hint?
In this case it would be as easy as just calling org.kde.KIOFuse org.kde.KIOFuse.VFS mountUrl with the url and it gets a local path back.
This should ideally be handled transparently by the KDE file dialog though.
I will make the portal not to freeze the app when there is no local file selected and we can revisit this later. As I can see, there is not even a stable relase of kio-fuse,
In D27643#618125, @jgrulich wrote:I have never used fuse. I see you can use kio-fuse over dbus to mount a file, but you still have to unmount it, which will be a problem, because from the portal I don't know whether the app is still using it or not.
Feb 25 2020
In D27643#617558, @ngraham wrote:Shouldn't KIO take care of this stuff automatically? I wouldn't want to lose streaming support for Flatpak apps.