[frameworks-kfilemetadata] [Bug 463598] External plugins are not found, findPlugins used by findExtractors only searches for files/libraries
https://bugs.kde.org/show_bug.cgi?id=463598 Gabriel Marcano changed: What|Removed |Added Attachment #154894|0 |1 is obsolete|| --- Comment #7 from Gabriel Marcano --- Created attachment 155224 --> https://bugs.kde.org/attachment.cgi?id=155224=edit add_external_plugins.patch Commit 5bd67e925db7db2f9619139f7e8000ce0321d52d almost fixed the bug, it just missed adding the found external plugins to the list of all extract plugins. This patch, once applied on top of 5bd67e925db7db2f9619139f7e8000ce0321d52d, fixes the problem for me. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kfilemetadata] [Bug 463598] External plugins are not found, findPlugins used by findExtractors only searches for files/libraries
https://bugs.kde.org/show_bug.cgi?id=463598 Gabriel Marcano changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Gabriel Marcano --- (In reply to Andreas Sturmlechner from comment #3) > Gabriel, thanks for your report. Could you please test the linked patch > provided by upstream? Sorry, was traveling. No, the patch does not fix the problem. In particular, the problem is that it fails to add the external plugins found to the `m_allExtractors` list. I don't see a similar issue in the writercollection class. I'll attach a rough patch that fixes the issue for me. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kfilemetadata] [Bug 463598] External plugins are not found, findPlugins used by findExtractors only searches for files/libraries
https://bugs.kde.org/show_bug.cgi?id=463598 --- Comment #1 from Gabriel Marcano --- Created attachment 154894 --> https://bugs.kde.org/attachment.cgi?id=154894=edit external_extractor_plugin.patch After looking at the more recent changes to the code that manages the external plugins, I reverted the changes only for the external plugin handling, yielding this patch. With this in place I can successfully use an external plugin with kfilemetadata. I took a brief look at the writer collection class, and it looks like the external plugins code isn't affected... but might have the same bug reported in bug 438186. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kfilemetadata] [Bug 463598] External plugins are not found, findPlugins used by findExtractors only searches for files/libraries
https://bugs.kde.org/show_bug.cgi?id=463598 Gabriel Marcano changed: What|Removed |Added CC||gabemarc...@yahoo.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kfilemetadata] [Bug 463598] New: External plugins are not found, findPlugins used by findExtractors only searches for files/libraries
https://bugs.kde.org/show_bug.cgi?id=463598
Bug ID: 463598
Summary: External plugins are not found, findPlugins used by
findExtractors only searches for files/libraries
Classification: Frameworks and Libraries
Product: frameworks-kfilemetadata
Version: 5.101.0
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: pinak.ah...@gmail.com
Reporter: gabemarc...@yahoo.com
Target Milestone: ---
SUMMARY
***
External plugins are not found by kfilemetadata. I did some digging, and it
turns out that the current implementation in
`ExtractorCollectionPrivate::findExtractors` for external plugins relies on
`KPluginMetaData::findPlugins`, which uses
`KPluginMetaDataPrivate::forEachPlugin` which only searches for files, and
these files must be libraries.
***
STEPS TO REPRODUCE
1. Compile kfilemetadata and kcoreaddons with debugging symbols and install
them
2. Install an external plugin at
libexec/kf5/kfilemetadata/externalextractors/test/ (on my system, this is at
`/usr/lib64/libexec/kf5/kfilemetadata/externalextractors/test/`)
2. gdb --args /usr/bin/baloo_filemetadata_temp_extractor
[some-audio-file-as-an-example]
3. Place a breakpoint at `ExtractorCollectionPrivate::findExtractors` and
`KPluginMetaDataPrivate::forEachPlugin`
OBSERVED RESULT
When trying to find external plugins, `KPluginMetaDataPrivate::forEachPlugin`
skips over these are they aren't files (`QDirIterator it(dir, QDir::Files);`)
nor libraries (`if (QLibrary::isLibrary(it.fileName())) {`.
EXPECTED RESULT
The kfilemetadata implementation uses something else to find external plugins
so that they are found by `ExtractorCollectionPrivate::findExtractors`
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo Linux
(available in About System)
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
ADDITIONAL INFORMATION
Let me know if you need additional information, but this should be fairly easy
to reproduce. The new-ish `KPluginMetaData::findPlugins` support from
KPluginMetaData doesn't have a concept for external plugins-- not sure if
that's intentional or a bug. In any case, currently, it assumes all plugins are
files and libraries, which explains why the current kfilemetadata
implementation fails to find any external libraries, as these are in
directories, and are not libraries.
--
You are receiving this mail because:
You are watching all bug changes.
[Elisa] [Bug 443184] Elisa Music Player Stutters on Each Track Start with Bluetooth Headphones (fine otherwise)
https://bugs.kde.org/show_bug.cgi?id=443184 Gabriel Marcano changed: What|Removed |Added CC||gabemarc...@yahoo.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 458591] OSC 7 stopped working to preserve path when creating a new tab
https://bugs.kde.org/show_bug.cgi?id=458591 --- Comment #4 from Gabriel Marcano --- I can confirm that the changes at https://invent.kde.org/utilities/konsole/-/merge_requests/758 do fix the problem for me. To make sure the problem is still on the current release, I tried reproducing the problem without the patch, and I can confirm it is still happening. Applying the patch from the PR makes is such that I cannot reproduce the bug. So, at least from what I can see, it looks like once the PR is merged, this bug report can be closed. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 458591] OSC 7 stopped working to preserve path when creating a new tab
https://bugs.kde.org/show_bug.cgi?id=458591 Gabriel Marcano changed: What|Removed |Added CC||gabemarc...@yahoo.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 458591] New: OSC 7 stopped working to preserve path when creating a new tab
https://bugs.kde.org/show_bug.cgi?id=458591
Bug ID: 458591
Summary: OSC 7 stopped working to preserve path when creating a
new tab
Product: konsole
Version: 22.08.0
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: emulation
Assignee: konsole-de...@kde.org
Reporter: gabemarc...@yahoo.com
Target Milestone: ---
Created attachment 151752
--> https://bugs.kde.org/attachment.cgi?id=151752=edit
List of packages updated today
SUMMARY
This may not be a Konsole problem, but I have not been able to track down where
the problem originates (it's either in Qt or in KDE dependencies of Konsole or
Konsole itself).
I have the following on my .bashrc:
_osc7 () {
printf "\033]7;file://%s%s\033\\" "$HOSTNAME" $(pwd)
}
PROMPT_COMMAND=_osc7
With this, I was able to create new tabs when in symlinked folders, and the new
tab would preserve the path taken to get there in the path shown on bash. As an
example, /tmp/foo is an folder, /tmp/bar is a symlink to /tmp/foo:
/tmp/foo
/tmp/bar -> /tmp/foo
If I cd'd to /tmp/bar and then launched a new tab (Ctrl-Shift-T), the current
working directory on the new tab would show as /tmp/bar instead of /tmp/foo.
This stopped working with the latest update. Now, if I `cd /tmp/bar` and launch
a new tab, the new tab shows the current working directory as /tmp/foo.
STEPS TO REPRODUCE
1. mkdir /tmp/foo
2. ln -s /tmp/foo /tmp/bar
3. cd /tmp/bar
4. printf "\033]7;file://%s%s\033\\" "$HOSTNAME" $(pwd)
5. launch a new tab in Konsole
6. in the new tab, run pwd
OBSERVED RESULT
$ pwd
/tmp/foo
EXPECTED RESULT
$ pwd
/tmp/bar
SOFTWARE/OS VERSIONS
Linux: Gentoo Linux
(available in About System)
KDE Plasma Version: 5.25.4
KDE Frameworks Version: 5.97.0
Qt Version: 5.15.5
ADDITIONAL INFORMATION
I spent a couple of hours tracing through Konsole, qtcore, and a couple of KDE
framework projects, trying to figure out the culprit. I've ruled out the shell
as a problem, as the issue appears whether I use /bin/bash or /bin/sh as the
shell for the session.
I tried rolling back to an older Konsole release from 2021, and the problem
persists... which hints that the problem might be deeper than Konsole. I don't
have the knowledge necessary to identify the actual source of the problem,
though, so I'm choosing Konsole as the source until something more specific
can be found.
As far as I can tell through debugging, the QProcessPrivate::execChild call
deep in qtcore done by the forked process that spawns the new tab does receive
the right directory to change into. As Konsole spawns a bunch of other
processes around this time, and they all time out if I take too long stepping
through things, I was not able to debug any deeper to see what, if anything,
changed the working directory.
>From what I can tell, though, there doesn't appear to be anything in Konsole to
pass the OSC 7 from one tab to the new one. Not sure if that information has a
different way to make it from one tab to another.
Let me know if you need anything specific, or if there are specific things I
can try to help debug this issue. I can build and debug Konsole, as well as any
of its dependencies. I can reproduce this on both of my Gentoo systems
currently (a desktop and a laptop), and I did confirm this morning that before
the updates, OSC 7 was working fine on my desktop.
I'm attaching the full list of KDE and QT applications/libraries that I updated
today on my desktop, in case it helps. There are a lot of applications there,
though.
--
You are receiving this mail because:
You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #19 from Gabriel Marcano --- I can check later today (or sometime this week? Being back in school is consuming my life), but I suspect part of the reason you won't be able to reproduce it (if your commit didn't fix it) is if you updated PowerDevil since I last posted a comment, they fixed a bug related to this that I also found (https://bugs.kde.org/show_bug.cgi?id=423131). As that particular bug is fixed, I would expect this Elisa bug to be swept under the metaphorical rug by PowerDevil if it doesn't send an inhibition request before quitting. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662
--- Comment #15 from Gabriel Marcano ---
I've been doing some reading to understand what's going on. At least with the
libvlc audiowrapper, it does look like at some point something is causing the
AudioWrapper::stop() slot to be called, which is good. The problem is this slot
isn't what causes the inhibition management to happen-- it instead sends a stop
command to libvlc. The vlc_callback function is called, and we queue the method
that will actually update the inhibit status (audiowrapper_libvcl.cppp:360):
QMetaObject::invokeMethod(this, [this, newStatus]() {Q_EMIT
statusChanged(newStatus);}, Qt::QueuedConnection);
The problem is that this queued method might never run (and it seems to never
run) if it is queued right as the application is ending (my guess is the main
loop is no longer servicing events at that point).
--
You are receiving this mail because:
You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #13 from Gabriel Marcano --- I'd love to take a stab, but I can't do it for the next month and a half, as my employer limits what code I can contribute (intellectual property assignment clause in contract). I'm actually leaving for grad school in August, so I should be able to get around to trying this out around then, if no one has figured this out. Once bug 423131 is fixed, arguably the importance of this bug should drop to minor, as powerdevil should be handling elisa exiting itself. I'd argue we still should have elisa emit an Uninhibit request even if in theory powerdevil will do it. I don't know if Gnome's session implementation is similar or not to Plasma's, so I don't know if they handle undoing all inhibits of applications that exit automatically. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #11 from Gabriel Marcano --- In terms of what could be done by elise, I'm not too sure as I'm not familiar with the entire codebase, but maybe we could install a custom handler for "file_quit" that somehow tells the AudioWrapper to stop playing before killing the application? That should get the underlying code of AudioWrapper to call setPreventSleep (at least both implementations of the AudioWrapper interface do this). -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 423131] powerdevil does not release pending Inhibit cookie if source application exits too quickly
https://bugs.kde.org/show_bug.cgi?id=423131 --- Comment #1 from Gabriel Marcano --- I think the solution is to move the m_busWatcher parts in addInhibitionWithExplicitDBusService and ReleaseInhibition further up, so that they are processed before the functions are short-circuited by the pending checks. This way a service will be registered as soon as we have even a pending request, and thus the pending cookie will be released properly when that service dies or goes away. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #10 from Gabriel Marcano --- I've opened a new bug report for Powerdevil: bug 423131 Even with that bug in place, I still think elisa should try to uninhibit during a regular application exit. I think it's fair to not bother with corner cases such as crashing and receiving an unhandled signal. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 423131] New: powerdevil does not release pending Inhibit cookie if source application exits too quickly
https://bugs.kde.org/show_bug.cgi?id=423131 Bug ID: 423131 Summary: powerdevil does not release pending Inhibit cookie if source application exits too quickly Product: Powerdevil Version: 5.19.1 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: gabemarc...@yahoo.com Target Milestone: --- SUMMARY Powerdevil delays registering an Inhibit request from dbus for 5 seconds (commit eca79138c). If the requesting application/service dies during those 5 seconds, the Inhibit is still registered. STEPS TO REPRODUCE 1. Launch an application that sends a request to Inhibit via org.freedesktop.PowerManagement.Inhibit.Inhibit or directly to Powerdevil via its dbus interface. I used the elisa music player. 2. Have said application send an Inhibit. With elisa, just play some music. 3. Exit the application before 5 seconds after sending an Inhibit. With elisa, that's just exiting the application quickly after pressing play. OBSERVED RESULT Using: watch -n1 dbus-send --session --dest=org.kde.Solid.PowerManagement.PolicyAgent --type=method_call --print-reply /org/kde/Solid/PowerManagement/PolicyAgent org.kde.Solid.PowerManagement.PolicyAgent.ListInhibitions A new inhibition is listed after the application has exited, 5 seconds after the inhibit was sent. EXPECTED RESULT No new inhibition is listed by the application that just exited. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux (unstable) (available in About System) KDE Plasma Version: 5.19.1 KDE Frameworks Version: 5.71.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION I found this while debugging bug #421662 . While arguably elisa should be sending an inhibit on a controlled exit (it can't reasonably do this if it gets a SIGTERM or SIGKILL, or triggers a SIGSEGV, though), there is code in Powerdevil to handle cases where the external service exits without getting rid of the inhibitor. In fact, if I exit elisa after the Inhibit has posted successfully, I do see the Inhibit being removed by Powerdevil. The root of the problem is that currently, due to commit eca79138c, Powerdevil quasi-registers the pending request, but it doesn't actually fully register it so that the service is being listened to in case it dies. Specifically, in daemon/powerdevilpolicyagent.cpp: m_busWatcher.data()->addWatchedService(service); isn't called until after the 5 second timer goes off. >From what I can tell, this file hasn't changed since 5.19.1 and the current master commit b009a7d856220b9ca64e34cc887069798c801fe9. I'm experimenting to see what could be a possible solution, but I'm not familiar with the codebase. In addition, due to contract clauses with my employer, I can't provide patches without their permission, at least until I am no longer employed by them. I may be able to provide ideas, though, once I come up with something that works. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 423131] powerdevil does not release pending Inhibit cookie if source application exits too quickly
https://bugs.kde.org/show_bug.cgi?id=423131 Gabriel Marcano changed: What|Removed |Added CC||gabemarc...@yahoo.com -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #9 from Gabriel Marcano --- So, playing an mp3, AudioWrapper::playerStateSignalChanges doesn't fire when exiting the application (https://github.com/KDE/elisa/blob/aecd9917a45d6c8e3c698490ab5404baacefdcf1/src/audiowrapper_libvlc.cpp#L335). I would wager that it should. Without this being called, we don't make a call to uninhibit. That said, I'm looking through the powerdevil code right now. Something, seemingly not elisa (I set a breakpoint in the function where we set the inhibition, this does not fire on exit), is causing the inhibition to go away when elisa shuts down, only if the inhibition has posted by the time elisa exits. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #8 from Gabriel Marcano --- Here's the PowerDevil commit that introduced the delay: https://github.com/KDE/powerdevil/commit/eca79138c15575f6f523a8680919b407f84da2e2 It's a conscious decision by the powerdevil developers. As far as I can tell, even though powerdevil takes 5 seconds to post an inhibit request, they DO track if they receive an uninhibit request before those 5 seconds are up (https://github.com/KDE/powerdevil/blob/master/daemon/powerdevilpolicyagent.cpp#L599). As far as I can tell powerdevil returns a cookie immediately, so elisa should receive one before the inhibit is officially posted. In other words, for some reason elisa isn't sending a request when it should to uninhibit. I "fixed" this problem by doing synchronous dbus commands on the destructor (not ideal, because of possible exceptions? Maybe? Not sure, haven't looked to see how dangerous calling dbus related classes in the destructor is), making sure that if we have a cookie, to send a message to uninhibit. I could do a bit more digging to make sure https://github.com/KDE/elisa/blob/master/src/audiowrapper_qtmultimedia.cpp#L194 is being fired when we're exiting, and that elisa is actually requesting for the power manager to be uninhibited. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #6 from Gabriel Marcano --- Interesting. It looks like I wasn't hallucinating about the 5 seconds:https://github.com/KDE/powerdevil/blob/master/daemon/powerdevilpolicyagent.cpp#L509 PowerDevil is the thing that is implementing the inhibitor. It itself has a 5 second delay before actually recording the inhibition. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #5 from Gabriel Marcano --- Interesting. Looks like a race condition. Here's a quick screen capture I did with OBS (so it's also inhibiting): https://i.imgur.com/wtmo7pC.mp4 Let me know if you can't access that video for some reason. In short, I show two terminals, with me launching the compiled elisa, and the other one showing the output of me querying powerdevil for active inhibitions using watch with a 1 second interval. Elisa began playing back something from the beginning, which I paused after I saw the elisa inhibition show up (about 5 seconds AFTER playing begun). Pausing it caused it to be dropped fairly quickly. Pressing play again, I waited another 5 seconds until the inhibition came up again. I then paused the player again, and saw the inhibition disappear again. For the final test, I clicked play and quickly pressed X to exit the application, before the elisa inhibitor showed up. Like clockwork, it showed up 5 seconds after I pressed play, even though the player had already exited. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662
--- Comment #4 from Gabriel Marcano ---
Yes, I can still reproduce the problem. I re-built elisa with commit
1f400cf32e434479a0b35e19e34a9081e2bd78cc.
$ dbus-send --session --dest=org.kde.Solid.PowerManagement.PolicyAgent
--type=method_call --print-reply /org/kde/Solid/PowerManagement/PolicyAgent
org.kde.Solid.PowerManagement.PolicyAgent.ListInhibitions
method return time=1591840161.651687 sender=:1.31 -> destination=:1.310
serial=2274 reply_serial=2
array [
struct {
string "elisa"
string "Playing Music"
}
]
$ ps -ef | grep elisa
gabriel 4181 22395 0 21:49 pts/800:00:00 grep --colour=auto elisa
$
--
You are receiving this mail because:
You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #3 from Gabriel Marcano --- I'll take a look tonight to see if I can reproduce it. I'm curious to see how it's being handled now, if you can't reproduce the problem. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421660] PowerManagementInterface printing incessantly about non-existent service
https://bugs.kde.org/show_bug.cgi?id=421660 --- Comment #2 from Gabriel Marcano --- I know, I'd love to offer a patch, but due to IP waiver forms I signed with my employer I can't release code without their consent, even if I develop it on my own time :( This is what happens in the US when there are poor worker protections in place, even for a well paid software engineer. On the plus side, I'll be going back to grad school come August, so I won't be under said contract limitations then. If no one has provided a patch by then, I'll try making one. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 --- Comment #1 from Gabriel Marcano --- I've been able to hack something on my end, by making QDBusInterface objects and using them to send a synchronous message to release the active Inhibit cookie. I'm still a little uneasy, as I'm afraid of a collision between a pending async job and the destructor (I don't know how all of these threads work together). Ideally, I think, it would be a good idea to make sure all pending async tasks are done, and then prevent them from starting once the destructor is going. There's also the added problem of what happens if Elisa is forcibly killed by a signal... this would leave the Inhibit in place, still. I would share what I have hacked together, but I'm under contract to not share any code I write while employed at my current employer without explicit permission from them (yay USA /s). -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 Gabriel Marcano changed: What|Removed |Added CC||gabemarc...@yahoo.com -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421662] New: Elisa does not release PowerManagement inhibitions on exit if it's playing when exited
https://bugs.kde.org/show_bug.cgi?id=421662 Bug ID: 421662 Summary: Elisa does not release PowerManagement inhibitions on exit if it's playing when exited Product: elisa Version: 20.04.1 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: matthieu_gall...@yahoo.fr Reporter: gabemarc...@yahoo.com Target Milestone: --- SUMMARY Elisa does not release the inhibition it places on org.freedesktop.PowerManagement.Inhibit while it's playing if it's exited while it is playing. STEPS TO REPRODUCE 1. Launch Elisa 2. Play music through Elisa 3. Exit Elisa without pausing the music OBSERVED RESULT dbus-send --session --dest=org.kde.Solid.PowerManagement.PolicyAgent --type=method_call --print-reply /org/kde/Solid/PowerManagement/PolicyAgent org.kde.Solid.PowerManagement.PolicyAgent.ListInhibitions Shows that there is still elisa's inhibition. dbus-send --session --dest=org.freedesktop.PowerManagement.Inhibit --type=method_call --print-reply /org/freedesktop/PowerManagement/Inhibit org.freedesktop.PowerManagement.Inhibit.HasInhibit returns true. EXPECTED RESULT For there to be no inhibitions from elisa. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo, Plasma (available in About System) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION I'll check out of curiosity on my end, but it should be possible to fix this by adding something to the PowerManagementInterface destructor, specifically to send a blocking message to the session bus if Elisa is still inhibiting during destruction. -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 421660] New: PowerManagementInterface printing incessantly about non-existent service
https://bugs.kde.org/show_bug.cgi?id=421660
Bug ID: 421660
Summary: PowerManagementInterface printing incessantly about
non-existent service
Product: elisa
Version: 20.04.1
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: general
Assignee: matthieu_gall...@yahoo.fr
Reporter: gabemarc...@yahoo.com
Target Milestone: ---
SUMMARY
Poking around at the code, in src/powermanagementinterface.cpp, in the function
PowerManagementInterface::setPreventSleep, I see checks for management the
inhibition state for both Plasma and Gnome are always called. On my system,
that only has Plasma, this leads to spam on the console whenever music is
played, specifically:
PowerManagementInterface::inhibitDBusCallFinishedGnomeWorkspace
QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name
org.gnome.SessionManager was not provided by any .service files")
STEPS TO REPRODUCE
1. Have a Linux distro with either Plasma or Gnome installed (not both?)
2. Run Elisa
3. Play a file/music archive
OBSERVED RESULT
PowerManagementInterface::inhibitDBusCallFinishedGnomeWorkspace
QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name
org.gnome.SessionManager was not provided by any .service files")
is printed in the console.
EXPECTED RESULT
No error messages displayed due to non-existent D-Bus service on a computer
without said service installed.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo, Plasma
(available in About System)
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.70.0
Qt Version: 5.14.2
ADDITIONAL INFORMATION
There are a couple ways to fix this-- one is to remove the qDebug statement, or
somehow hide it (I'm unfamiliar with verbosity levels in Qt/KDE). Another is to
detect the existence of services in PowerManagementInterface initialization,
and only call inhibitor functions of the services found.
--
You are receiving this mail because:
You are watching all bug changes.
[elisa] [Bug 421660] PowerManagementInterface printing incessantly about non-existent service
https://bugs.kde.org/show_bug.cgi?id=421660 Gabriel Marcano changed: What|Removed |Added CC||gabemarc...@yahoo.com -- You are receiving this mail because: You are watching all bug changes.
[elisa] [Bug 389187] elisa is not support file name that contain none English word
https://bugs.kde.org/show_bug.cgi?id=389187 Gabriel Marcano changed: What|Removed |Added CC||gabemarc...@yahoo.com --- Comment #5 from Gabriel Marcano --- So, I did a little bit of experimentation. It looks like the proper playlist file extension for UTF-8 encoded files is .m3u8 . The Elisa "Load Playlist" prompt does not show .m3u8 files, but putting in the full path in the selection works. For testing, I made a playlist with the name ゾ.m3u and with a two entries, one ゾ.flac and another test.flac. I copied the ゾ.m3u playlist to ゾ.m4u8 . Elisa's UI silently chokes on the ゾ.m3u and prints out in the console: kf5.kfilemetadata: Unable to open file readonly: "/home/test/Music/ã\u0082¾.flac Only the test.flac entry is shown in the UI in this case. If I give it the ゾ.m4u8 manually by specifying the full path, both files in the playlist show. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 400832] kdeconnect, remote input plugin does not seem to be working at all (no input on Desktop)
https://bugs.kde.org/show_bug.cgi?id=400832 --- Comment #2 from Gabriel Marcano --- There is a recent change to the application behavior. I recompiled kdeconnect on Gentoo with support for libmouse or something like that, and I can now control the mouse. I am unable to type with the keyboard, but I suspect it's a bug on the Android side and 9.0 (I saw a commit on the Android app changing some behavior to fix 9.0 Android devices). I'll try to recompile the Android app and see if that fixes it. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 400832] kdeconnect, remote input plugin does not seem to be working at all (no input on Desktop)
https://bugs.kde.org/show_bug.cgi?id=400832 Gabriel Marcano changed: What|Removed |Added CC||gabemarc...@yahoo.com -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 400832] New: kdeconnect, remote input plugin does not seem to be working at all (no input on Desktop)
https://bugs.kde.org/show_bug.cgi?id=400832 Bug ID: 400832 Summary: kdeconnect, remote input plugin does not seem to be working at all (no input on Desktop) Product: kdeconnect Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: gabemarc...@yahoo.com Target Milestone: --- SUMMARY Remote input plugin does not appear to work. After pairing device with Desktop, navigating to the remote input plugin on the phone leads to nothing being detected on the Desktop. xev does not return any input. Other plugins seem to be working (I can see files, I can ping and ring the phone, I can share notifications between the Desktop and the phone, etc.). STEPS TO REPRODUCE 1. Pair kdeconnect on phone and desktop 2. Go to remote input on phone 3. try to move mouse through remote input screen, or click OBSERVED RESULT Nothing happens EXPECTED RESULT Mouse moves in desktop, or some clicking occurs SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.51.0 Qt Version: 5.11.2 ADDITIONAL INFORMATION My Desktop runs Plasma 5 on Gentoo, and my phone is running Android 9 on a OnePlus 6 (OxygenOS, stock for OnePlus 6). My desktop doesn't have a firewall active (internal network, no IPv6). Let me know if you need more information, or what diagnostic tools I can run to check for remote input. I tried using xev, but it didn't pick anything up. -- You are receiving this mail because: You are watching all bug changes.
[plasma4] [Bug 323230] windows (maximized) are going under the vertical panel on dual screen setup
https://bugs.kde.org/show_bug.cgi?id=323230 Gabriel Marcano <gabemarc...@yahoo.com> changed: What|Removed |Added CC||gabemarc...@yahoo.com --- Comment #49 from Gabriel Marcano <gabemarc...@yahoo.com> --- Should I check if there is another bug for Plasma5? I have the same issue being described here, running Gentoo unstable AMD64, seemingly having Plasma and KDE applications installed of version 16.12.0. I have a dual monitor setup, where they are of slightly different resolutions. I have the panel on the smaller screen. If one places the window above where the panel ends, on the larger screen, the window can be moved there. If one tries to move it to anywhere in the same horizontal plane(?) as the panel, then the window being dragged jumps to the bottom. -- You are receiving this mail because: You are watching all bug changes.
