[kdesrc-build] [Bug 463474] kdesrc-buildrc provides no progress output in non-build (--src-only) mode
https://bugs.kde.org/show_bug.cgi?id=463474 FeRD (Frank Dana) changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from FeRD (Frank Dana) --- This seems to have been addressed (apparently coincidentally, or at least there's no indication in the commit message that this report had any influence on the discovery/correction of the issue) in commit 335caf0c7280b17d81a7ad1e6f0ad6b4501e1fcb a few weeks ago. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kapidox] [Bug 478145] New: API docs styling for (at least) deprecated list is broken in dark mode
https://bugs.kde.org/show_bug.cgi?id=478145
Bug ID: 478145
Summary: API docs styling for (at least) deprecated list is
broken in dark mode
Classification: Frameworks and Libraries
Product: frameworks-kapidox
Version: unspecified
Platform: Other
OS: All
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kdelibs-b...@kde.org
Reporter: ferd...@gmail.com
Target Milestone: ---
SUMMARY
See, for example,
https://api.kde.org/frameworks/kio/html/deprecated.html#_deprecated53
In dark mode, the list is unreadable, with the contents being rendered in
white-on-white.
I **believe** this is due to a typo(?) in the CSS files for the documentation.
The doxygen.css file contains the following CSS, which governs that content and
is not palette-aware:
.memdoc, dl.reflist dd {
border-bottom: 1px solid #A8B8D9;
border-left: 1px solid #A8B8D9;
border-right: 1px solid #A8B8D9;
padding: 6px 10px 2px 10px;
background-color: #FBFCFD;
border-top-width: 0;
background-image:url('nav_g.png');
background-repeat:repeat-x;
background-color: #FF;
/* opera specific markup */
border-bottom-left-radius: 4px;
border-bottom-right-radius: 4px;
box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
/* firefox specific markup */
-moz-border-radius-bottomleft: 4px;
-moz-border-radius-bottomright: 4px;
-moz-box-shadow: rgba(0, 0, 0, 0.15) 5px 5px 5px;
/* webkit specific markup */
-webkit-border-bottom-left-radius: 4px;
-webkit-border-bottom-right-radius: 4px;
-webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15);
}
customdoxygen.css, the palette-aware enhancement which SHOULD override those
colors, fails to in this case. The reason is because it contains no style rules
for ".memdoc, dl.reflist dd". Instead it contains this similar css, but note
the extra 'l' in "refllist":
.memdoc,
dl.refllist dd {
background:var(--card);
color:var(--on-card)
}
I don't know if "dl.refllist" — again, note the extra 'l' — is actually a valid
CSS selector anywhere ELSE in the code (but I doubt it). Or, perhaps it's
simply a typo of "dl.reflist" (probably). But, adding "dl.reflist" to that
style rule, like so:
.memdoc,
dl.reflist dd,
dl.refllist dd {
background:var(--card);
color:var(--on-card)
}
...conservatively fixes the styling for the deprecation-list page(s) (and
possibly elsewhere in the API docs), without any risk of breaking styling
elsewhere.
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kapidox] [Bug 478145] API docs styling for (at least) deprecated list is broken in dark mode
https://bugs.kde.org/show_bug.cgi?id=478145 --- Comment #1 from FeRD (Frank Dana) --- Fixed in kapidox with the merge of https://invent.kde.org/frameworks/kapidox/-/merge_requests/33, though I don't know what's involved in getting https://api.kde.org/resources/css/customdoxygen.css updated for the live site. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kapidox] [Bug 478145] API docs styling for (at least) deprecated list is broken in dark mode
https://bugs.kde.org/show_bug.cgi?id=478145 FeRD (Frank Dana) changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #2 from FeRD (Frank Dana) --- Fixed with a rebuild+deploy of Generate_API_Documentation by Carl Schwan. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 454120] New: Android app doesn't export TelephonyDisplayInfo#OVERRIDE_NETWORK_TYPE, needed for 5G detection
https://bugs.kde.org/show_bug.cgi?id=454120 Bug ID: 454120 Summary: Android app doesn't export TelephonyDisplayInfo#OVERRIDE_NETWORK_TYPE, needed for 5G detection Product: kdeconnect Version: unspecified Platform: Other OS: Android 11.x Status: REPORTED Severity: normal Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: ferd...@gmail.com Target Milestone: --- Apparently, detecting 5G network service[1] is more difficult than previous levels. Many 5G devices will report their network connection as TelephonyManager#NETWORK_TYPE_LTE. The actual state of 5G connectivity is only accessible by using the new (Android 11+) TelephonyDisplayInfo[2] API, where an "override" network type can be retrieved for display use. [1]: https://developer.android.com/about/versions/11/features/5g#how-to-detect [2]: https://developer.android.com/reference/android/telephony/TelephonyDisplayInfo Without access to that additional data, many US devices which provide 5G service via enhanced LTE will be reported as having only 4G connectivity. See also: GSConnect issue 1348. [3] [3]: https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/1348 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 447498] Minor issue, Android app says battery information not available
https://bugs.kde.org/show_bug.cgi?id=447498 FeRD (Frank Dana) changed: What|Removed |Added CC||ferd...@gmail.com --- Comment #4 from FeRD (Frank Dana) --- (In reply to Mark de Wet from comment #0) > At the bottom of the Android app, below the menu for send > files etc it says "Status battery information not available. Is this a > permission error or something else? _That_ message, in the "Status" area at the bottom of the device details page in the Android app, is actually related to the **paired** device that's currently selected. Specifically, in this case, it would be the PC your phone is paired with. The Android app is (correctly) reporting that it isn't able to retrieve battery-level information from your Linux system. So, it's normal that you'd see that message, and it's unrelated to KDE Connect on your Linux system showing or not showing battery information for the phone. As long as the battery plugin is enabled on the phone (from that same screen, upper-right-corner menu, "Plugin settings", and then enable "Battery report"), you *should* see battery data for it on the Linux side. I don't know of any permission specific to reading the device's battery level, but the permission that would be most likely to affect that is the "Phone" permission. (Which also controls access to things like network signal levels, etc.) Additionally, you may need to go into your phone's preferences for the app (Android's Settings > Apps > KDE Connect), tap "Battery", and set the mode to at least "Optimized", possibly "Unrestricted", to ensure that the app is able to provide battery (and other) data request. The more recent the Android release, the more aggressively it will attempt to powersave the app, which can sometimes interfere with its ability to handle network requests from the Linux side. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 443155] kdeconnect breaks when openssh is upgraded to version 8.8p1-1
https://bugs.kde.org/show_bug.cgi?id=443155 --- Comment #49 from FeRD (Frank Dana) --- (In reply to Brian from comment #48) > (I'm not sure if/how the decryption can be done with a tcpdump cmdline.) > Any saved traces should now contain the decrypted traffic -- a decrypted > packet should look like the image at that first link. The decryption happens when the packets are examined, not when they're captured. Loading a capture log containing encrypted traffic into WireShark, then decrypting it, should be no different from decrypting packets that were captured live _by_WireShark. (You do need the key dump created by having SSLKEYLOGFILE set in the environment at the time of capture, though.) > Your phone's live "adb logcat" would also be very useful to see app-level > errors. If you like, you can limit both traces and logcat to just the rough > time period when you run the tests. You'd think so, but... unlikely, in my experience. The SFTP stuff, in particular, has next to zero logging on the Android side, AFAICT. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 443155] kdeconnect breaks when openssh is upgraded to version 8.8p1-1
https://bugs.kde.org/show_bug.cgi?id=443155 --- Comment #50 from FeRD (Frank Dana) --- (In reply to FeRD (Frank Dana) from comment #49) > The SFTP stuff, in > particular, has next to zero logging on the Android side, AFAICT. (That wasn't meant as any sort of slight against kdeconnect-android, it's just a reality of the MINA SSH backend. The GSConnect side of things is even worse on that front, since it delegates SFTP operations to GVfs... which means we have basically zero control, and even less visibility into what's going on.) -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 443155] kdeconnect breaks when openssh is upgraded to version 8.8p1-1
https://bugs.kde.org/show_bug.cgi?id=443155 FeRD (Frank Dana) changed: What|Removed |Added CC||ferd...@gmail.com --- Comment #34 from FeRD (Frank Dana) --- I briefly looked at upgrading kdeconnect-android to more recent releases of the Apache MINA sshd libraries, not too long ago. Purely to satisfy my own curiosity. The issue I hit (aside from my relative lack of familiarity with Java) was, the library has evolved so much that vast chunks of the APIs kdeconnect-android uses just don't exist anymore. MINA sshd 0.14.0 was the last release before 1.0.0, and neither 1.0.0 nor anything later is fully compatible with the 0.x series. The farther forward you go, the more it diverges from 0.14.0. Since the 0.14.0 APIs are mostly long-gone by now, upgrading to a recent-ish release would likely require a rewrite of kdeconnect-android's ssh functionality on top of all-new-all-different 2.x APIs. (Rewriting against 1.x seems like it would just be a foolish half-measure, since the 1.x releases are already obsoleted by 2.x.) The code currently in kde-connect, and the code that it would need in order to work with 2.x, are so far apart they may not even be recognizable as providing the same functionality. [1]: https://github.com/apache/mina-sshd/blob/master/CHANGES.md -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcodecs] [Bug 463421] New: KCharsets::codecForName() deprecation breaks Kf6/Qt6 build of kconfigwidgets, which uses it unconditionally
https://bugs.kde.org/show_bug.cgi?id=463421
Bug ID: 463421
Summary: KCharsets::codecForName() deprecation breaks Kf6/Qt6
build of kconfigwidgets, which uses it unconditionally
Classification: Frameworks and Libraries
Product: frameworks-kcodecs
Version: 5.101.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kdelibs-b...@kde.org
Reporter: ferd...@gmail.com
Target Milestone: ---
SUMMARY
I'm really not sure whether I should be reporting this against kcodecs or
kconfigwidgets, but...
The recent change in kcodecs to mark KCharsets::codecForName() deprecated since
5.101 breaks the kf6-frameworks-build-include build of kconfigwidgets in
kdesrc-build (which is configured,in part:)
module-set frameworks
cmake-options -DBUILD_TESTING=TRUE -DBUILD_WITH_QT6=ON
-DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.101.0
end module-set
kcodecwidgets unconditionally uses codecForName() at several points within
kcodecaction.cpp, so removing the method causes build failures.
STEPS TO REPRODUCE
1. install kdesrc-build and configure to build kf6-frameworks for Qt6
2. kdesrc-build kconfigwidgets
OBSERVED RESULT
Building kconfigwidgets from frameworks (13/17)
Fetching remote changes to kconfigwidgets
Merging kconfigwidgets changes from branch master
Source update complete for kconfigwidgets: no files affected
Rebuilding because the build directory doesn't exist
Preparing build system for kconfigwidgets.
Running cmake targeting Unix Makefiles...
Compiling... failed (after 7 seconds)
See above for details.
EXPECTED RESULT
Successful compilation with no errors.
SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma:
(available in About System)
KDE Plasma Version:
KDE Frameworks Version: Building Kf6 from current sources with kdesrc-build
Qt Version: 6.4.1
ADDITIONAL INFORMATION
/log//kconfigwidgets/error.log with the default options:
[ 22%] Building CXX object
src/CMakeFiles/KF5ConfigWidgets.dir/kcolorscheme.cpp.o
.../kconfigwidgets/src/kcodecaction.cpp: In member function ‘int
KCodecAction::mibForName(const QString&, bool*) const’:
.../kconfigwidgets/src/kcodecaction.cpp:108:39: error: ‘class KCharsets’ has no
member named ‘codecForName’; did you mean ‘encodingForName’?
108 | QTextCodec *codec = charsets->codecForName(codecName, success);
| ^~~~
| encodingForName
.../kconfigwidgets/src/kcodecaction.cpp:111:31: error: ‘class KCharsets’ has no
member named ‘codecForName’; did you mean ‘encodingForName’?
111 | codec =
charsets->codecForName(charsets->encodingForName(codecName), success);
| ^~~~
| encodingForName
.../kconfigwidgets/src/kcodecaction.cpp: In member function ‘bool
KCodecAction::setCurrentCodec(QTextCodec*)’:
.../kconfigwidgets/src/kcodecaction.cpp:214:53: error: ‘class KCharsets’ has no
member named ‘codecForName’; did you mean ‘encodingForName’?
214 | if (codec ==
KCharsets::charsets()->codecForName(actions().at(i)->menu()->actions().at(j)->text()))
{
| ^~~~
| encodingForName
.../kconfigwidgets/src/kcodecaction.cpp: In member function ‘bool
KCodecAction::setCurrentCodec(const QString&)’:
.../kconfigwidgets/src/kcodecaction.cpp:232:51: error: ‘class KCharsets’ has no
member named ‘codecForName’; did you mean ‘encodingForName’?
232 | return
setCurrentCodec(KCharsets::charsets()->codecForName(codecName));
| ^~~~
| encodingForName
gmake[2]: *** [src/CMakeFiles/KF5ConfigWidgets.dir/build.make:97:
src/CMakeFiles/KF5ConfigWidgets.dir/kcodecaction.cpp.o] Error 1
gmake[2]: *** Waiting for unfinished jobs
gmake[1]: *** [CMakeFiles/Makefile2:741:
src/CMakeFiles/KF5ConfigWidgets.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
Downgrading to -DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.100.0 allows kconfigwidgets
to compile successfully, e.g. at the end of $HOME/.config/kdesrc-buildrc:
# Downgrade deprecation exclusions
options frameworks
cmake-options -DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.100.0
end options
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kcodecs] [Bug 463421] KCharsets::codecForName() deprecation breaks Kf6/Qt6 build of kconfigwidgets, which uses it unconditionally
https://bugs.kde.org/show_bug.cgi?id=463421 --- Comment #1 from FeRD (Frank Dana) --- (The kcodecs change in question was this one, merged as commit 19e7a37c845ccaf96bcd1b2b6ff571c936e05484) https://invent.kde.org/frameworks/kcodecs/-/merge_requests/27 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcodecs] [Bug 463421] KCharsets::codecForName() deprecation breaks Kf6/Qt6 build of kconfigwidgets, which uses it unconditionally
https://bugs.kde.org/show_bug.cgi?id=463421 --- Comment #2 from FeRD (Frank Dana) --- (In reply to FeRD (Frank Dana) from comment #0) > kcodecwidgets unconditionally uses codecForName() at several points within > kcodecaction.cpp, so removing the method causes build failures. It was virtually guaranteed I was going to do that at least once. s/kcodecwidgets/kconfigwidgets/ -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 463474] New: kdesrc-buildrc provides no progress output in non-build (--src-only) mode
https://bugs.kde.org/show_bug.cgi?id=463474 Bug ID: 463474 Summary: kdesrc-buildrc provides no progress output in non-build (--src-only) mode Classification: Developer tools Product: kdesrc-build Version: Git Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mp...@kde.org Reporter: ferd...@gmail.com Target Milestone: --- kdesrc-buildrc's documentation makes some claims about displaying progress, some more grand than others. But even the most conservative don't seem to hold in all situations. This, I found at https://docs.kde.org/trunk5/en/kdesrc-build/kdesrc-build/basic-features.html#build-progress Showing the progress of a module build -- This feature is always available, and is automatically enabled when possible. What this does is display an estimated build progress while building a module; that way you know about how much longer it will take to build a module. And this is from https://docs.kde.org/trunk5/en/kdesrc-build/kdesrc-build/features.html * kdesrc-build will show the progress of your build when using CMake, and will always time the build process so you know after the fact how long it took. While that's all apparently true for the **build**, it's far less true in other situations. Recently, while setting up kdesrc-build on a new system, I wanted to just check out all of the necessary sources, before I thought about starting to actually build anything. So, I ran it in `--src-only` mode: $ ./kdesrc-build --src-only Fetching remote changes to sysadmin-repo-metadata Merging sysadmin-repo-metadata changes from branch master Holding performance profile That was the last thing it printed before starting its work. Cut to THIRTEEN+ MINUTES of absolutely no output whatsoever. I could _see_ it working in the process list, or in a `top` display. But there was certainly no indication of that, from the terminal window where the process was actually _running_. And then, finally, all at once when everything was finished, it dumped out: The following modules were updated but not built: kfilemetadata kactivities-stats kcalendarcore plasma-wayland-protocols kservice kholidays karchive syndication poppler kde-dev-scripts purpose kunitconversion kcontacts breeze-icons kxmlgui threadweaver polkit-qt-1 kbookmarks kdoctools qca solid kwallet qqc2-desktop-style kdeclarative ktextwidgets phonon bluez-qt kitemmodels kcoreaddons extra-cmake-modules kdbusaddons kdnssd kparts knotifyconfig kwidgetsaddons kdav kglobalaccel kquickcharts networkmanager-qt kwayland kauth kconfig syntax-highlighting knotifications kidletime kirigami kdesrc-build oxygen-icons5 kimageformats kio kdesu frameworkintegration phonon-vlc plasma-framework kpeople krunner kcrash kcmutils ktexteditor ki18n modemmanager-qt kplotting kwindowsystem kded kguiaddons kiconthemes attica baloo prison kitemviews kconfigwidgets kactivities sonnet kcompletion kjobwidgets kpty kapidox kcodecs knewstuff kpackage :-) Your logs are saved in file:///... I know it took exactly 13m22s, in fact, because my zsh prompt times the execution of each previous command. That's an awful long time to go with _no indication whatsoever_ that the command you've run hasn't gone permanently out to lunch. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 462365] When only one device associated, share directly to it without additional confirmation
https://bugs.kde.org/show_bug.cgi?id=462365 --- Comment #3 from FeRD (Frank Dana) --- (In reply to kdebugs2023 from comment #1) >The way > it is supposed to work is that apps create "contacts" that show up as their > own target. And for a while, that is how it worked. KDE Connect on Android _used to_ publish a share target per connected, paired device, so not only could I select to share directly to my desktop PC by name, but that target would be stored as the default "Share..." quick-link by e.g. Google Chrome. That way, once selected, I could send another URL to the same paired device by simply opening the browser menu and tapping the KDE Connect icon next to "Share...". But at some point that seems to have stopped working, or at least it no longer works that way on my current Android 12 device. The APIs for doing this evolved some, in recent releases — in Android 6–9 the Direct Share API [1] was used to publish device targets, but that was supplanted by the newer Sharing Shortcuts API [2] starting with Android 10. Sharing Shortcuts is rather different from Direct Share, and the app may not be fully up to date with those newer APIs. There's some guidance on using Sharing Shortcuts, along with making them backwards-compatible with Android <= 9 Direct Share, here: https://developer.android.com/training/sharing/receive#sharing-shortcuts-api [1]: https://developer.android.com/about/versions/marshmallow/android-6.0#direct-share [2]: https://developer.android.com/about/versions/10/highlights#sharing_shortcuts -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 426541] Please clarify error message "SFTP: No storage locations configured"
https://bugs.kde.org/show_bug.cgi?id=426541 FeRD (Frank Dana) changed: What|Removed |Added CC||ferd...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 407293] New: Remote input plugin's scrolling speed is too fast, can't be adjusted
https://bugs.kde.org/show_bug.cgi?id=407293 Bug ID: 407293 Summary: Remote input plugin's scrolling speed is too fast, can't be adjusted Product: kdeconnect Version: unspecified Platform: Android OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: ferd...@gmail.com CC: albertv...@gmail.com, inverted...@gmail.com, myccl...@gmail.com Depends on: 350878 Target Milestone: --- SUMMARY Bug #350878 previously dealt with the remote input plugin, and at the time the ability to tweak the mouse-tracking responsiveness was added in the form of the plugin's "Set touchpad sensitivity" and "Set pointer acceleration" preferences. While those work great for tuning pointer movement, it has no effect whatsoever on two-finger scrolling speed, which remains uncomfortably fast and difficult to use with any precision. STEPS TO REPRODUCE 1. Pair an Android phone running KDE Connect to a Linux system, and enable the "Remote input" plugin on both ends. 2. Open the remote input mode on KDE Connect and use one finger to move the Linux mouse pointer around the screen. Note how finger movements translate into pointer motion. 3. Open a browser and load a long (ideally, continuously-scrolling) page — YouTube's default https://youtube.com/ homepage feed works well. 4. Use two fingers to scroll the page vertically. Choose a particular video and attempt to position it at the exact vertical center of the window. 5. Go into the Remote input plugin's preferences, and set: "Set touchpad sensitivity" to "Above Slowest"; "Set pointer acceleration" to "Weakest". 6. Return to the remote input interface and repeat the previous input tests. OBSERVED RESULT While pointer motion becomes positively glacial, scrolling response is exactly the same despite the preferences change. In general, scrolling is extremely hyperresponsive, with even small finger movements translating into exaggerated scrolls. Precise positioning of the scroll position is extremely difficult. There is no way to adjust the response curve governing how two-finger swipes are translated into scroll motions. EXPECTED RESULT Two-finger input motions would be, or could be configured to be, amplified less when translated into scroll events, allowing for more gradual and precise shifts of the scrollable canvas using scroll gestures. SOFTWARE/OS VERSIONS KDE Connect version: 1.12.7 (Bugzilla's Version selector only goes to 1.10) Linux: Fedora 29 with GNOME Shell 3.30.2 (via GSConnect v23) Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=350878 [Bug 350878] Add input speed/sensitivity settings for mouse input. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 350878] Add input speed/sensitivity settings for mouse input.
https://bugs.kde.org/show_bug.cgi?id=350878 FeRD (Frank Dana) changed: What|Removed |Added Blocks||407293 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=407293 [Bug 407293] Remote input plugin's scrolling speed is too fast, can't be adjusted -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 414120] Ring and photo not working in kdeconnect app when app is in background on Android 10.
https://bugs.kde.org/show_bug.cgi?id=414120 FeRD (Frank Dana) changed: What|Removed |Added CC||ferd...@gmail.com --- Comment #1 from FeRD (Frank Dana) --- I took a shot at reworking FindMyPhoneActivity to make use of newer Android APIs (on newer Android devices). The code should be considered a rough draft as it almost certainly needs additional polish, but it at least compiles and runs fine on Android 7 (which doesn't support those newer APIs, which makes it a poor test, but it's the best I can do). The code's in a branch on my GitHub fork of kdeconnect-android: https://github.com/ferdnyc/kdeconnect-android/tree/findmyphone-api-refresh I also created a PR in the KDE GitHub mirror (which was of course auto-closed, but I just wanted to get the code up somewhere): https://github.com/KDE/kdeconnect-android/pull/16 The text of that PR follows. This is an update to the FindMyPhone plugin, attempting to make use of newer APIs to more correctly manage audio playback on newer Android releases. Highlights: KDE Connect-wide * Raise minSdkVersion from 14 to 21 (To access more recent APIs w/o lots of legacy fallback.) * Add WAKE_LOCK to permissions requested in manifest file. FindMyPhoneActivity --- * Use AudioAttributes to replace deprecated SetAudioStreamType() * Request & manage audio focus, on Android 26+ * Prevent screen / CPU sleep during playback (using WAKE_LOCK) * Prepare MediaPlayer asynchronously, and release() when done I'll be honest, I wrote this code working off of API docs and code samples, but I'm not supremely confident that it's all correct. It compiles with no problems, and I built and installed it as an APK on my Android 7 phone, where it worked just the same as the version installed from Google Play. However, running on Android 7 means that most of the newer APIs (including Audio Focus) aren't accessed, and I don't have a newer device to test on. (Trying to run the app in an emulator failed, network-connectivity wise... I ended up with GSConnect trying to pair with itself.) So, I'm submitting this in case it might be useful, but I would be surprised if it doesn't need at least some cleanup. It certainly needs testing on newer devices, something I'm unable to do myself. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 495146] kdeconnect android 1.32.7 cannot receive OTP notifications after upgrading to Android 15
https://bugs.kde.org/show_bug.cgi?id=495146 --- Comment #7 from FeRD (Frank Dana) --- (In reply to FeRD (Frank Dana) from comment #6) > Disable Enhanced Notifications > > It seems like a discussion of the > consequences/tradeoffs of doing that would be warranted — I assume there > must be SOME, removing the sensitive-notifications restriction can't be the > only effect it has? Addressing my own concern, it appears from this Reddit conversation[1] that disabling Enhanced Notifications (which is a Messages app setting, turns out — I thought it was systemwide) will turn off all smart replies, response suggestions, notification reply actions, etc. So, it's pretty drastic. [1]: https://www.reddit.com/r/GooglePixel/comments/1gls85v/enhanced_notifications_keep_turning_on_after/ -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 495146] kdeconnect android 1.32.7 cannot receive OTP notifications after upgrading to Android 15
https://bugs.kde.org/show_bug.cgi?id=495146 FeRD (Frank Dana) changed: What|Removed |Added CC||ferd...@gmail.com --- Comment #6 from FeRD (Frank Dana) --- (In reply to Simon Redman from comment #5) > Updated documentation: > https://userbase.kde.org/ > KDEConnect#Sensitive_Notification_Content_(Android_15+) Part of the added content is this subsection: Disable Enhanced Notifications In the notification settings, disable "Enhanced notifications" which will remove this restriction. ...But that's it, full stop. It seems like a discussion of the consequences/tradeoffs of doing that would be warranted — I assume there must be SOME, removing the sensitive-notifications restriction can't be the only effect it has? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 498778] New, more-strict device ID requirements exclude current GSConnect IDs
https://bugs.kde.org/show_bug.cgi?id=498778 FeRD (Frank Dana) changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #1 from FeRD (Frank Dana) --- Withdrawing this, as we've concluded that it makes more sense to change our device IDs to fit the new format. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 498778] New: New, more-strict device ID requirements exclude current GSConnect IDs
https://bugs.kde.org/show_bug.cgi?id=498778
Bug ID: 498778
Summary: New, more-strict device ID requirements exclude
current GSConnect IDs
Classification: Applications
Product: kdeconnect
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: common
Assignee: albertv...@gmail.com
Reporter: ferd...@gmail.com
CC: andrew.g.r.hol...@gmail.com
Target Milestone: ---
A few days ago, @albertvaca changed[1] the KDE Connect protocol specification
for device ID format, with the message:
Enforce ID format
All implementations have been using UUIDs as device IDs for a while, so we can
start validating and enforcing this format.
The new format is expected to match this RegEx: /^[a-zA-Z0-9_]{32,38}$/
While GSConnect HAS been using UUIDs as device ID for some time now, we've been
using *real* UUIDs, with hyphens instead of underscores.
In the interest of not forcing all of our users to have to regenerate their
device IDs (and then re-pair all of their devices, and re-apply preferences),
would it be possible for the format to be expanded so that it also accepts
hyphen-separated UUID strings?
See also:
https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/1910
[1]:
https://invent.kde.org/network/kdeconnect-meta/-/commit/e4f93eecb876dccf1f35e6db4944d536a8b9bc53
--
You are receiving this mail because:
You are watching all bug changes.
[kphotoalbum] [Bug 425410] Names of tag categories suddenly have superfluous ampersands added to them
https://bugs.kde.org/show_bug.cgi?id=425410 FeRD (Frank Dana) changed: What|Removed |Added CC||ferd...@gmail.com --- Comment #17 from FeRD (Frank Dana) --- (In reply to Patrick Silva from comment #16) > Thanks for clarifying, Johannes. :) > Strawberry, a Qt 6 music player, is also affected: > > https://github.com/strawberrymusicplayer/strawberry/issues/1499 > > However, its developer says it's a KDE bug instead of a Qt bug. He is right, > or the Qt bug is not really fixed. As the strawberry developer says in that bug report, it's not the same bug. This issue, and the Qt bugs people have been referencing, are about QDockWidget title bars. The Strawberry bug was about QTabBar tab labels. Completely different widget, completely different bug. -- You are receiving this mail because: You are watching all bug changes.
