[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 Matt Whitlock changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |UNCONFIRMED --- Comment #5 from Matt Whitlock --- This failure mode has recurred several times since I last commented. • I can always bring functionality back by rebooting my phone, but obviously I should not need to do this. • Merely stopping the app's "BackgroundService" and then relaunching the app's main activity does not fix the problem. • Force-stopping the app entirely and then relaunching its main activity also does not fix the problem. (Although the app's uptime does reset upon the Force Stop request, the app immediately restarts to start its "NotificationReceiver" service. The "BackgroundService" is not started until the app's main activity is launched.) • Disabling the notifications permission allows the app to be fully stopped. (It disappears from the list of running services upon a Force Stop.) Relaunching the main activity still does not fix the problem. To reiterate, the problem is that the KDE Connect app does not communicate with the computer unless its main activity is in the foreground. The background services continue running, but they do not maintain connectivity with the computer. Rebooting the phone restores background connectivity. The failure mode always seems to begin when the phone is removed from the WLAN for a while. Upon reconnecting to the WLAN, the app's background service does not maintain connectivity with the computer. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #6 from Matt Whitlock --- There is a data-race bug in LanLink.java: https://github.com/albertvaka/kdeconnect-android/blob/master/src/org/kde/kdeconnect/Backends/LanBackend/LanLink.java#L116 Because LanLink.socket is not declared volatile, the load from this field on line 116 can see a stale value that was stored before the call to Thread.sleep(…) on line 115. Declare LanLink.socket volatile to ensure that loads from it are always fresh from RAM and are never speculated out of program order. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] New: KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 Bug ID: 368438 Summary: KDE Connect does not communicate while running in background on phone Product: kdeconnect Version: 1.0 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: grave Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: k...@mattwhitlock.name All functionality of KDE Connect works only while the KDE Connect app is in the foreground on the phone. Switching to any other app causes KDE Connect to stop working. It does not receive pings from the desktop, and clipboard sharing is broken. In fact, about 25 seconds after switching away from KDE Connect on the phone, the phone becomes shown as disconnected in the desktop module. Reproducible: Always Steps to Reproduce: 1. Install KDE Connect 1.0 on a phone running Android 6.0.1 (e.g., CyanogenMod 13.0-20160901-NIGHTLY-d2spr). 2. Install KDE Connect 1.0 on desktop running Gentoo Linux, KDE Frameworks 5.25.0, Qt 5.6.1. 3. Pair phone with desktop. 4. Switch away from KDE Connect app on phone (e.g., by pressing Home button). 5. Try to send a ping from the desktop module. (No notification appears on phone.) 6. Switch back to KDE Connect app on phone. 7. Try again to send a ping from the desktop. (Notification appears.) Actual Results: KDE Connect communicates with desktop only while the app is the foreground activity. Expected Results: KDE Connect should continue functioning even while running in the background on the phone. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #2 from Matt Whitlock --- Created attachment 101003 --> https://bugs.kde.org/attachment.cgi?id=101003&action=edit Running app details Thanks for the reply. You've been too quick to dismiss this, though. In fact, the KDE Connect app is always running. You can see in the attached screen shot that its background services have been running continuously for the past 37+ hours. Android is not killing them. They simply don't work unless one of the app's activities is in the foreground. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 Matt Whitlock changed: What|Removed |Added Resolution|UPSTREAM|--- Status|RESOLVED|UNCONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #3 from Matt Whitlock --- Created attachment 101004 --> https://bugs.kde.org/attachment.cgi?id=101004&action=edit KDE Connect memory usage statistics Here's another screen shot. Android reports that the KDE Connect app is "Always running (100%)." -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 Matt Whitlock changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|UNCONFIRMED |NEEDSINFO --- Comment #4 from Matt Whitlock --- After a reboot of my phone, KDE Connect is remaining connected to my desktop even while running in the background. I will attempt to determine the exact conditions under which KDE Connect enters the failure mode described in this report. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 368580] New: Auto Brackets forgets about multiple levels of brackets when overtyping closing bracket
https://bugs.kde.org/show_bug.cgi?id=368580
Bug ID: 368580
Summary: Auto Brackets forgets about multiple levels of
brackets when overtyping closing bracket
Product: frameworks-ktexteditor
Version: unspecified
Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: kwrite-bugs-n...@kde.org
Reporter: k...@mattwhitlock.name
This is with ktexteditor 5.26.0.
The Auto Brackets feature appears to remember only one level of bracketing for
purposes of auto-overtyping closing brackets. Only the innermost closing
bracket is automatically overwritten.
Reproducible: Always
Steps to Reproduce:
In a new document in KWrite (or Kate, KDevelop, etc.) with Auto Brackets
enabled, type more than one opening bracket (of any kind). Then type the
corresponding closing brackets (in reverse order).
Actual Results:
Only the first closing bracket gets automatically overwritten. The remaining
closing brackets are inserted instead, leading to excessive closing brackets.
Expected Results:
All closing brackets should be automatically overwritten if they were
automatically inserted and have not yet been automatically overwritten.
This worked in KDE 4, presumably because *all* closing brackets were *always*
automatically overtyped by matching characters. This was an okay solution,
though it confounded the later insertion of additional closing brackets into a
run of closing brackets.
A better solution would be to remember which closing brackets on the current
editing line were automatically inserted and automatically overtype them if and
only if the character being typed matches the existing closing bracket and the
existing closing bracket has not already been automatically overtyped. (The set
of remembered auto-inserted closing brackets can be forgotten when the cursor
moves to another line.)
Some examples (pipe character indicates cursor position)…
Type these five characters: ((a))
Expected result: ((a))|
Actual result: ((a))|)
Type these seven characters: ({[a]})
Expected result: ({[a]})|
Actual result: ({[a]})|})
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 96431] Ability to use mouse buttons for shortcuts
https://bugs.kde.org/show_bug.cgi?id=96431 --- Comment #52 from Matt Whitlock --- (In reply to Aloysius from comment #51) > I'm afraid the only way is to use xbindkeys or switch to wayland. Preposterous. If xbindkeys can do it, then KDE's global hotkeys daemon can do the same thing. It's as simple as grabbing all the buttons that have shortcuts assigned to them, isn't it? -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 360567] Wrong parameter info displayed for variadic function templates
https://bugs.kde.org/show_bug.cgi?id=360567
Matt Whitlock changed:
What|Removed |Added
CC||k...@mattwhitlock.name
--- Comment #2 from Matt Whitlock ---
(In reply to Alexander Potashev from comment #0)
> In the sample code below, pressing Ctrl+Space shows "void print()". "void
> print()" is just wrong here, these two options should be displayed instead:
> * void print(int a, char b)
> * void print(std::string a, double b)
Your suggestion is wrong. The compiler is in fact free to instantiate the
variadic function template using *any* template parameters whatsoever. It is
true that there will be a compilation error for any but two distinct tuples of
argument types, but this has no bearing on the parameters with which the
template may be instantiated.
What you're asking for is effectively that the contextual assistant should
compute the set containing all tuples of argument types that would not result
in a compilation error, but this may in fact be an infinite set, and in general
there is no way to guess what type tuples might be in the set.
Consider the following addition to your example:
template
std::enable_if_t, void> print_impl(E value) {
std::cout << static_cast>(value);
}
Now what is the contextual assistant supposed to show when you press
Ctrl+Space? Do you expect it to search through every defined type, trying to
instantiate the print_impl(E) function template? Do you expect every defined
enumerated type to appear in the list of suggestions? That would be pretty
impractical.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 348123] Some processes (kuiserver) are left running after exiting KDE
https://bugs.kde.org/show_bug.cgi?id=348123 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[kactivitymanagerd] [Bug 348194] kactivitymanager sometimes crashes on logout
https://bugs.kde.org/show_bug.cgi?id=348194 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] New: tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 Bug ID: 362089 Summary: tooltips and menus in Qt5 apps are missing shadow Product: Oxygen Version: 5.6.3 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: hugo.pereira.da.co...@gmail.com Reporter: k...@mattwhitlock.name Tooltips and menus in old Qt4 apps (e.g., KMail, KSnapshot) have drop shadows, but tooltips and menus in Qt5 apps do not. This looks particularly bad in some apps (e.g., Kate) because the menu is drawn with a hard black outline that looks like a rendering bug. Reproducible: Always Steps to Reproduce: 1. Select Oxygen as the widget style. 2. Hover over a toolbar button or open a menu in a Qt4 application. 3. Hover over a toolbar button or open a menu in a Qt5 application. Actual Results: Toolbars and menus in Qt5 application lack drop shadows. Expected Results: Toolbars and menus in Qt5 applications have drop shadows as they do in Qt4 applications. -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 --- Comment #1 from Matt Whitlock --- Created attachment 98515 --> https://bugs.kde.org/attachment.cgi?id=98515&action=edit Comparison of menus in KMail (Qt4) and KCalc (Qt5) -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 --- Comment #2 from Matt Whitlock --- Created attachment 98516 --> https://bugs.kde.org/attachment.cgi?id=98516&action=edit Ugly hard black border around menu in Kate (Qt5) -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 --- Comment #4 from Matt Whitlock --- Created attachment 98534 --> https://bugs.kde.org/attachment.cgi?id=98534&action=edit KCalc (Qt5) running with "-style breeze" (In reply to Hugo Pereira Da Costa from comment #3) > You are running with kwin_x11 (from kf5) as a window manager, right ? Yes, I'm running kwin_x11 5.6.3 on KDE Frameworks 5.21.0. I am logging in using SDDM 0.13.0 as my display manager. > - can you check that shadows are indeed enabled in oxygen settings (either > via systemsettings5, style, oxygen -> configuration, or using > oxygen-settings5) I assume you mean the "Shadows" settings in the "Window Decoration" module of oxygen-settings5. Yes, everything is set to the defaults. > - do you have the same issue when using breeze as a widget theme ? (you > should: both code path are pretty similar) Yes, Breeze also lacks shadows behind menus and tooltips. See the attached screen shot. > - and what is the Qt5 version you are using ? 5.5.1 -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 --- Comment #5 from Matt Whitlock --- (In reply to Matt Whitlock from comment #4) > (In reply to Hugo Pereira Da Costa from comment #3) > > - and what is the Qt5 version you are using ? > > 5.5.1 Same problem exists when running on Qt 5.6.0. -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 270842] dolphin tooltips not displayed & information panel is empty when nepomuk is not installed
https://bugs.kde.org/show_bug.cgi?id=270842 --- Comment #19 from Matt Whitlock --- I still have the same problem in Dolphin 15.12.3 (using KDE Frameworks 5.21.0 and Qt 5.5.1). I presently have installed Baloo 4.14.3, Baloo 5.21.0, and Baloo-Widgets 15.12.3, yet Dolphin still gives me no hover-overs and no file details in the Information panel. How is this supposed to work? -- You are receiving this mail because: You are watching all bug changes.
