[konsole] [Bug 482628] Allow disabling toolBar accelerator
https://bugs.kde.org/show_bug.cgi?id=482628 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #13 from Raphaël Jakse --- Because of this bug, Alt+N triggers the "New tab" button (in French and English locales) when the main toolbar is displayed. This is an issue because Alt+N is used in terminal programs, for instance in Nano to toggle line numbers. I don't fink making it possible to disable keyboard accelerators is good enough, they should be disabled by default, and I'm not sure it's useful to make this configurable. I'm usually biased toward accessibility, and keyboard accelerators are a pretty important accessibility feature. However, in this case, removing the accelerator seems better because it is possible to configure keyboard shortcuts for all the actions of the main toolbar. Any keyboard accelerator is likely to override a terminal program's shortcut, and I would guess this is why there are none in the menu bar. > how did this get by testing? KDE always need testers, and this might be the indication that KDE lacks a tester like you to spot such bugs. Testing is one of the many ways to help KDE. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 492327] UI elements are resized for tablet mode on an external screen
https://bugs.kde.org/show_bug.cgi?id=492327 --- Comment #4 from Raphaël Jakse --- I agree this is a duplicate of these bugs, I don't know why I didn't find them when looking for existing bugs. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 492327] UI elements are resized for tablet mode on an external screen
https://bugs.kde.org/show_bug.cgi?id=492327 --- Comment #2 from Raphaël Jakse --- The screen of this laptop also happens to be a Wacom graphics tablet, with an active pen and all. The bug is something I spotted by trying to see if I could use the laptop as a regular graphics tablet (which is also a central unit). And the answer is yes, definitely. Someone who draws could definitely reach for such a computer, and draw with Krita using the large 14 inch screen of the laptop as a graphics tablet, possibly turned off. You don't need a laptop + a dedicated wacom tablet, you have both, it's one less device to have and to carry when on the go. I can also imagine someone with a regular tablet with an HDMI output wanting to connect an external screen. The bug gives a small unfinished feeling, but is definitely not a blocker. And I haven't found a way to turn this mechanism off. When the tablet screen is turned off, it might already be desirable to disable tablet mode without changing the architecture of the feature to be per screen, that's probably lower effort, maybe as a first step. > Maybe we should even suppress it when we detect there are any external > screens connected. Yep, it would not even make the tablet unusable, just a bit less practical (but totally manageable), and if you have an external screen you probably have a mouse and a keyboard anyway. Unless you plugged your tablet to play a video on a big screen, so maybe detecting the presence of a mouse / a keyboard is better. Or if the screens are cloned (then you may not want to disable tablet mode, probably the person is using the touchscreen in this case) -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 492327] New: UI elements are resized for tablet mode on an external screen
https://bugs.kde.org/show_bug.cgi?id=492327 Bug ID: 492327 Summary: UI elements are resized for tablet mode on an external screen Classification: I don't know Product: kde Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- Sorry for the lack of specific classification for this bug, I'm not sure which component(s) is involved. SUMMARY On a 2-in-1 convertible laptop, when converting to tablet, KWin titlebars and buttons in Plasmashell become bigger so one can tap and grab stuff more easily with the fingers. But when a (non-touch) external screen is connected, this also happens on the external screen. Bigger UI elements on the external screen is not necessary and looks weird. STEPS TO REPRODUCE 1. Put a convertible laptop in laptop mode 2. Connect an external screen 3. set the external screen to primary so you have a Plasmashell dock in it 4. move a window to the external screen so you have a window in it 5. convert the laptop to tablet mode, keyboard behind the screen. OBSERVED RESULT Nothing changes on the external screen EXPECTED RESULT Window titlebars and and buttons in the Plasmashell dock are bigger SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed Wayland KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Linux kernel: 6.10.5-1-default (64 bit) Lenovo ThinkPad X1 Yoga Gen 6 -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 486189] New: The current day is not updated from day to day when the computer is suspended at midnight
https://bugs.kde.org/show_bug.cgi?id=486189 Bug ID: 486189 Summary: The current day is not updated from day to day when the computer is suspended at midnight Classification: Applications Product: KDE Itinerary Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: vkra...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY I left KDE Itinerary open and suspended my computer for the night. After resuming, KDE itinerary still shows "Today - nothing planned for today" (approximate translation from French) . Today with its itinerary still shows as "Saturday, 27/04/2024". STEPS TO REPRODUCE 1. Plan a trip for tomorrow 2. Leave KDE itinerary open and suspend 3. Resume the computer the next day OBSERVED RESULT What is shown for today is actually what was planned for yesterday. Today is still displayed as if it were tomorrow. EXPECTED RESULT The days match with the current time. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed / Wayland KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION I don't know if the bug shows up if the computer is left running during the night. -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 454017] Integration of routes (like GPX)
https://bugs.kde.org/show_bug.cgi?id=454017 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #2 from Raphaël Jakse --- Hello, There's a case where such thing would be useful even without names displayed if there's nothing in the GPX trace. I can imagine: 27th of June - 10h -> 12h Train: City A -> City B, -> - Bike (clicking on this shows the map with the GPX trace) - 15h -> 16h Train: City C -> City D It is obvious at a glance that the bike is most likely between City B and City C between 12h and 15h even if those things are not explicit in the bike entry. It would be still very useful. Hours and location names could be manually editable too. The gpx trace could also be integrated in the whole map for the whole trip. I actually installed KDE Itinary to check if it allowed something like this. Amazing tool btw. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 409168] Add an option to save or print the QR codes
https://bugs.kde.org/show_bug.cgi?id=409168 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #8 from Raphaël Jakse --- Hi! I was about to create a new feature request and stumbled upon this one. Being able to drag is already very nice and noticed one could do this by myself, but it's not quite discoverable and you need to know where to drag, and dragging might not be so easy. I have the feeling many people still just search for a web service to generate a QR Code, when we have a perfectly fine and local one at hands. It's also still way quicker to just search "qr " in duck duck go, and right click on the result. Which is a shame. What about adding a small copy and a small save button on top of the QR Code in the clipboard and the wifi applets, and/or a context menu with these options? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-prison] [Bug 480662] New: kdesrc-build prison fails because -fexceptions is disabled
https://bugs.kde.org/show_bug.cgi?id=480662
Bug ID: 480662
Summary: kdesrc-build prison fails because -fexceptions is
disabled
Classification: Frameworks and Libraries
Product: frameworks-prison
Version: 5.248.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: s...@vuorela.dk
Reporter: raphael@jakse.fr
Target Milestone: ---
I am trying to build prison on an updated openSUSE Tumbleweed using
kdesrc-build prison. It fails with the following. Apparently, my version of g++
(g++ (SUSE Linux) 13.2.1 20240125 [revision
fc7d87e0ffadca49bec29b2107c1efd0da6b6ded]) wants -fexceptions:
FAILED: src/scanner/CMakeFiles/KF6PrisonScanner.dir/videoscannerworker.cpp.o
/usr/bin/c++ -DKF6PrisonScanner_EXPORTS
-DPRISONSCANNER_DEPRECATED_WARNINGS_SINCE=0x0
-DPRISONSCANNER_DISABLE_DEPRECATED_BEFORE_AND_AT=0x0 -DQT_CORE_LIB
-DQT_DEPRECATED_WARNINGS_SINCE=0x7 -DQT_DISABLE_DEPRECATED_BEFORE=0x60500
-DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_FROM_ASCII
-DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH
-DQT_NO_KEYWORDS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT
-DQT_NO_URL_CAST_FROM_STRING -DQT_STRICT_ITERATORS -DQT_USE_QSTRINGBUILDER
-D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/raph/kde/build/prison/src/scanner
-I/home/raph/kde/src/prison/src/scanner
-I/home/raph/kde/build/prison/src/scanner/KF6PrisonScanner_autogen/include
-I/home/raph/kde/build/prison -isystem /usr/include/qt6/QtMultimedia -isystem
/usr/include/qt6 -isystem /usr/include/qt6/QtCore -isystem
/usr/lib64/qt6/mkspecs/linux-g++ -isystem /usr/include/qt6/QtGui -isystem
/usr/include/qt6/QtNetwork -isystem /home/raph/kde/usr/include -pipe
-fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self
-Werror=undef -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -pedantic
-Wzero-as-null-pointer-constant -Wmissing-include-dirs
-fdiagnostics-color=always -O2 -g -DNDEBUG -std=c++20 -fPIC -fvisibility=hidden
-fvisibility-inlines-hidden -MD -MT
src/scanner/CMakeFiles/KF6PrisonScanner.dir/videoscannerworker.cpp.o -MF
src/scanner/CMakeFiles/KF6PrisonScanner.dir/videoscannerworker.cpp.o.d -o
src/scanner/CMakeFiles/KF6PrisonScanner.dir/videoscannerworker.cpp.o -c
/home/raph/kde/src/prison/src/scanner/videoscannerworker.cpp
In file included from /home/raph/kde/usr/include/ZXing/ReadBarcode.h:9,
from
/home/raph/kde/src/prison/src/scanner/videoscannerworker.cpp:17:
/home/raph/kde/usr/include/ZXing/ImageView.h: In constructor
‘ZXing::ImageView::ImageView(const uint8_t*, int, int, ZXing::ImageFormat, int,
int)’:
/home/raph/kde/usr/include/ZXing/ImageView.h:80:105: error: exception handling
disabled, use ‘-fexceptions’ to enable
80 | throw std::invalid_argument("Can not construct
an ImageView from a NULL pointer");
|
^
/home/raph/kde/src/prison/src/scanner/videoscannerworker.cpp: In member
function ‘void
Prison::VideoScannerWorker::slotScanFrame(Prison::VideoScannerFrame)’:
/home/raph/kde/src/prison/src/scanner/videoscannerworker.cpp:35:24: warning:
‘using ZXing::DecodeHints = class ZXing::ReaderOptions’ is deprecated
[-Wdeprecated-declarations]
35 | ZXing::DecodeHints hints;
|^
In file included from /home/raph/kde/usr/include/ZXing/ReadBarcode.h:8:
/home/raph/kde/usr/include/ZXing/ReaderOptions.h:176:7: note: declared here
176 | using DecodeHints [[deprecated]] = ReaderOptions;
| ^~~
[33/84] Linking CXX shared module bin/org/kde/prison/libprisonquickplugin.so
[34/84] Building CXX object
autotests/CMakeFiles/prison-aztecbarcodetest.dir/__/src/lib/aztecbarcode.cpp.o
In file included from /usr/include/c++/13/variant:44,
from /usr/include/qt6/QtCore/qtypeinfo.h:11,
from /usr/include/qt6/QtCore/qglobal.h:47,
from /home/raph/kde/src/prison/src/lib/barcode.h:13,
from /home/raph/kde/src/prison/src/lib/abstractbarcode_p.h:10,
from /home/raph/kde/src/prison/src/lib/aztecbarcode_p.h:10,
from /home/raph/kde/src/prison/src/lib/aztecbarcode.cpp:7:
In function ‘constexpr decltype (::new(void*(0)) _Tp) std::construct_at(_Tp*,
_Args&& ...) [with _Tp = aztec_code_t; _Args = {aztec_code_t}]’,
inlined from ‘static constexpr void
std::allocator_traits >::construct(allocator_type&, _Up*,
_Args&& ...) [with _Up = aztec_code_t; _Args = {aztec_code_t}; _Tp =
aztec_code_t]’ at /usr/include/c++/13/bits/alloc_traits.h:540:21,
inlined from ‘constexpr void std::vector<_Tp,
_Alloc
[plasma-mobile] [Bug 473028] New: Rotate to current orientation when enabling autorotate
https://bugs.kde.org/show_bug.cgi?id=473028 Bug ID: 473028 Summary: Rotate to current orientation when enabling autorotate Classification: Plasma Product: plasma-mobile Version: unspecified Platform: Debian testing OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: plasma-mobile-bugs-n...@kde.org Reporter: raphael@jakse.fr CC: c...@carlschwan.eu Target Milestone: --- SUMMARY When disabling auto rotate, then turning the device in and then enabling autorotate back, I would expect the screen to rotate to match the current orientation of the device. This would allow not to have to turn the device and turn it back to get the right orientation. This would also match Phosh's behavior. STEPS TO REPRODUCE 1. disable autorotate 2. turn the device 3. enable autorotate OBSERVED RESULT The current orientation remains. EXPECTED RESULT The new orientation is used. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION Mobian testing (up to date) -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 463034] "Battery low" notification persists even if battery fully charged
https://bugs.kde.org/show_bug.cgi?id=463034 Raphaël Jakse changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=471636 -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 471636] New: Notification about low battery still there after charging during suspend
https://bugs.kde.org/show_bug.cgi?id=471636 Bug ID: 471636 Summary: Notification about low battery still there after charging during suspend Classification: Plasma Product: Powerdevil Version: 5.27.6 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: raphael@jakse.fr CC: m...@ratijas.tk, natalie_clar...@yahoo.de Target Milestone: --- It's the "low battery: 98%" bug. I'm quite entertained by this bug, because it's mostly harmless and quite comical. Bear with me. SUMMARY The low battery notification is duly updated when the reported charge percentage changes. Which is a nice touch. Very KDE-like. So much polish. We are taken by the hand. Unfortunately, it does not seem to check whether the percentage still matches the need for displaying the notification. Therefore, you can trick it into telling a joke. See the steps. (well, you guessed the steps; unfortunately, I had to spoil the story in the title for a good bug report). STEPS TO REPRODUCE 1. Use your laptop until a low battery notification shows up. 2. Suspend 3. Plug the computer while it's asleep 4. Wait a while 5. Wake it up and unlock OBSERVED RESULT Notice how the low battery notification is still there, complete with the updated percentage. EXPECTED RESULT The battery notification should be gone. Now, a static notification that would not update the percentage would have the same issue, but with the updated charge, it's extra fun. SOFTWARE/OS VERSIONS Linux/KDE Plasma: updated openSUSE Tumbleweed KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION Related to #463034. But I believe they should be distinguished because #463034 seems to describe something that implies that some code detecting AC plug is not working correctly. We still want the notification to be hidden as soon as the AC is plugged, not only when the percentage is higher than the limit. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 455757] Please allow WallpaperFader to be disabled for Breeze theme in both SDDM and Lockscreen
https://bugs.kde.org/show_bug.cgi?id=455757 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #5 from Raphaël Jakse --- This discussion makes me sad. Nate has not rejected your idea, he is just telling you that this can be only implemented if someone is actually interested to do it *and* is not busy working on something else. He is kindly inviting / encouraging you to contribute some code. This kind of invitation may help getting people a bit shy to overcome their timidity and contribute. You seemed to know your way, that's why he did that. He could not have guessed you actually hated programming and this should not be taken as "then do it yourself, duh!". Of course nobody forces you to do it and if you don't like programming, that's fine! But it means you'll have to wait that somebody takes your idea and implement it. If you want to see this happen, you need to make people want to implement it. For this, you need to be nice to them and humble. It may be simple to implement but someone still needs to spend some time to do it, most likely in their spare time. There's no "irrational inflexibility" in not spending this time. Like you say, rational people may want to spend leisure time in something they like to do. It's not that they are actively against doing it, it's just that the incentives are not high so it'll not get done, through inaction. There are ways to increase the incentives, like offering a bounty for instance. Nate was nice to give you an answer and has done the best he could to hint at a likely outcome to your idea without rejecting it. You now have all the cards in your hand. He actually hinted at "yes, we might accept a patch that implements it", which is almost the best outcome for an idea (the best one being "I want to implement this", assuming the idea has been accepted). Everyone is well-intentioned, let's take a moment to take a step back. Everything is fine. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 455227] Password field in lock screen is not cleared after failed login attempt
https://bugs.kde.org/show_bug.cgi?id=455227 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #1 from Raphaël Jakse --- It was a surprising behavior when I noticed it the first time, but I started taking advantage of it. It happens that I fat finger the enter key and add a star at the end of the password for example. I fix the problem by removing the last character instead of retyping the whole password. It would be fine if the password gets selected, so if the user tries to type their password, the not deleted password is deleted when typing the first character. I just tried to reproduce this by locking the screen with CTRL+Shift+L and the password actually gets removed so it might just be the login screen, or the issue is already fixed. Operating System: openSUSE Tumbleweed 20220612 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 455104] Please consider not entering a space character when space bar is pressed to wake up the login screen
https://bugs.kde.org/show_bug.cgi?id=455104 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #1 from Raphaël Jakse --- This would eat the space also for people who's password starts with a space, which could be very confusing. Maybe another solution would be to display a message suggesting to press a key that don't normally produce a character to "wake up" the login screen? like escape, enter, ctrl, shift or something. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfigwidgets] [Bug 454481] New: KRecentFiles: allow temporary files to be added the list of recent files
https://bugs.kde.org/show_bug.cgi?id=454481
Bug ID: 454481
Summary: KRecentFiles: allow temporary files to be added the
list of recent files
Product: frameworks-kconfigwidgets
Version: 5.94.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kdelibs-b...@kde.org
Reporter: raphael@jakse.fr
Target Milestone: ---
Temporary files are not added to the list of recent files in Kate and KDevelop.
This is because KRecentFiles ignores them in krecentfilesaction.cpp:
void KRecentFilesAction::addUrl(const QUrl &url, const QString &name)
{
...
if (url.isLocalFile() &&
url.toLocalFile().startsWith(QDir::tempPath())) {
return;
}
...
}
I can see why it is this way, and this is useful, and this should probably be
the default. Usually, you don't want stale files in the recent files.
Now, I would like files I edit in /tmp to be in the recent files. My computer
is on for days, so files are going to stay for some time.
But if the goal is to avoid stale files to be in the recent files list, this is
incomplete: non-temporary files can also be (re)moved. I personally don't mind
having a few stale files in the recent files list, it is still useful to have
them in there, as a log of what as been edited in the past. But if it is
important, we could imagine a solution that iterates over the list and stat the
file system to see if they are still readable.
I see several solutions:
1. Don't care - let's keep it as it is
2. Add a configuration parameter somewhere that allows the user to say "I want
files in /tmp to be remembered in recent files"
3. Let's just accept there will be stale files in the recent files list and
unconditionally allow files in /tmp to be remembered.
4. No parameter while still avoiding stale files: iterate over the recent files
on initialization and check which ones are still readable. This might be costly
and not worth it, and should probably be done asynchronously to avoid making
apps lag just because we are doing something for the recent files.
My preference would be 3, but if it's there, it must be there of a reason and
probably to fix a former issue, so I guess 2. 1 is fine for me. 4 seems a bit
complicated and might cause other issues, but offer a more complete solution to
the problem at hand the developer who wrote this condition was probably facing.
STEPS TO REPRODUCE
1. Open Kate
2. Edit a file in /tmp
3. Save
OBSERVED RESULT
Notice the file is missing in the recent files menu (this is an intentional
behavior)
EXPECTED RESULT
I'd like the file to be in the recent files menu. I was not expecting a file I
edited not to show up in the list and caused me some confusion.
SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20220524
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 453691] Feature request: list of recently closed files / restore closed tabs
https://bugs.kde.org/show_bug.cgi?id=453691 --- Comment #4 from Raphaël Jakse --- Done here: https://invent.kde.org/utilities/kate/-/merge_requests/750 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfigwidgets] [Bug 453800] Kate's Recent Files List | every entry on list can be opened only once after update to 22.04.0 (restart of Kate necessary)
https://bugs.kde.org/show_bug.cgi?id=453800 --- Comment #6 from Raphaël Jakse --- Fix here: https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/142 Nate, this bug might be a 15-Minute Bug. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfigwidgets] [Bug 453800] Kate's Recent Files List | every entry on list can be opened only once after update to 22.04.0 (restart of Kate necessary)
https://bugs.kde.org/show_bug.cgi?id=453800 Raphaël Jakse changed: What|Removed |Added Version|22.04.0 |5.94.0 Product|kate|frameworks-kconfigwidgets Component|application |general Assignee|kwrite-bugs-n...@kde.org|kdelibs-b...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 453800] Kate's Recent Files List | every entry on list can be opened only once after update to 22.04.0 (restart of Kate necessary)
https://bugs.kde.org/show_bug.cgi?id=453800
--- Comment #5 from Raphaël Jakse ---
So, from reading the source code with naive eyes that haven't seen much Qt/KDE
code.
Recent files are managed with a KRecentFilesAction (subclass of KSelectAction,
itself a subclass of QWidgetAction, itself a subclass of QAction) object stored
in the m_fileOpenRecent member of KateMainWindow. This object is initialized
using inline/template function KStandardAction::openRecent.
m_fileOpenRecent = KStandardAction::openRecent(m_viewManager,
SLOT(openUrl(QUrl)), this);
I've noticed that KateMainWindow has a slotOpenDocument slot, that isn't used
anywhere. This one calls m_viewManager->openUrl(url, QString(), true);. It
seems like it should be used in the previous line instead of calling directly
KateViewManager::openUrl like this:
m_fileOpenRecent = KStandardAction::openRecent(this,
&KateMainWindow::slotOpenDocument, this);
Anyway, I tried and it does not fix the issue. Slot openUrl of KateViewManager
(m_viewManager) is supposed to be called when KRecentFilesAction's urlSelected
signal is emitted. This happens in KRecentFilesActionPrivate::urlSelected, a
function called when signal KSelectAction::triggered is emitted.
It lead me to explore KRecentFileAction's code, and in particular its addUrl
where the problem seem to happen.
More specifically:
using Info = KRecentFilesActionPrivate::RecentActionInfo;
// Reverse iterators because the most recent actions are at the end of
m_recentActions
auto it = std::find_if(d->m_recentActions.rbegin(),
d->m_recentActions.rend(), [&url](const Info &info) {
return info.url == url;
});
if (it != d->m_recentActions.rend()) { // url already has an action in the
menu
// Remove the action...
QAction *act = removeAction(it->action);
// ... move the relevant object to the end of m_recentActions
std::rotate(d->m_recentActions.rbegin(), it, it + 1);
// ... prepend the action to the menu
menu()->insertAction(menu()->actions().value(0), act);
return; // All done
}
If the URL is already in the menu, it moves it around by removing the
associated action, and reinserting the action. But reinserting the action does
not seem to work (anymore?). At this point, I suspect a bug in Qt, or a method
should be called to make the action work again. But I repeat, I didn't know
QAction before yesterday.
This version of the code works:
auto it = d->findByUrl(url);
if (it != d->m_recentActions.cend()) {
// Remove the action...
delete removeAction(it->action);
d->m_recentActions.erase(it);
addUrl(url, name);
return; // All done
}
It recreates the action from scratch. I'd also suggest defining a removeAction
method that takes the iterator and calls erase automatically because this is
what is done everywhere in this file. I'll submit a patch.
There's still a bug somewhere, so someone more experimented than me may want to
investigate why reusing the action does not work.
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-knotifications] [Bug 454076] New: Filter out notifications based on their content using keywords or regular expressions
https://bugs.kde.org/show_bug.cgi?id=454076 Bug ID: 454076 Summary: Filter out notifications based on their content using keywords or regular expressions Product: frameworks-knotifications Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: raphael@jakse.fr CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY I'd like to be able to define sub-strings, keywords or regular expressions that will make Plasma not show notifications whose content match the filter. Use case: I'm using a chat application and people are celebrating something on some days (say, a birthday or an anniversary). These messages are warm and very much welcome. However, they don't require immediate attention and notifications for these messages are just noise. The chat application doesn't support such filtering. It would also make sense to have a centralized place to define such filters. Ideally, one would be able to set a filter for a particular application, or restricted to some notification title. I'm imagining something like KWin's feature that allows to define fine-tuned window rules to match windows. OBSERVED RESULT I'm notified for these messages that don't require immediate attention. EXPECTED RESULT I can define some keywords matching these messages to block these notifications. The notifications could still be shown in the notification tray, but don't produce a popup. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220518 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Related: https://github.com/vector-im/element-web/issues/22291 -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 429101] Seg fault when clicking on new mail notification (KMail)
https://bugs.kde.org/show_bug.cgi?id=429101 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr Summary|Seg fault when clciking on |Seg fault when clicking on |new mail notification |new mail notification |(KMail) |(KMail) --- Comment #1 from Raphaël Jakse --- Is it still current? I've not run into this. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kmediaplayer] [Bug 453924] Add an option to pause the currently playing song/video on an audio sink that vanishes
https://bugs.kde.org/show_bug.cgi?id=453924 Raphaël Jakse changed: What|Removed |Added Severity|normal |wishlist -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kmediaplayer] [Bug 453924] New: Add an option to pause the currently playing song/video on an audio sink that vanishes
https://bugs.kde.org/show_bug.cgi?id=453924 Bug ID: 453924 Summary: Add an option to pause the currently playing song/video on an audio sink that vanishes Product: frameworks-kmediaplayer Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: alex.me...@kde.org Reporter: raphael@jakse.fr CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY I'm not sure where this should be reported, sorry if I picked the wrong one. On Android and probably other platforms, when an headset (bluetooth or jack) or a speaker is disconnected, the currently playing song is paused. This is a sensible behavior: if I'm listening to something on my headset and I unplug it, it's likely I want to pause the thing being played or that I unplugged it inadvertently and I don't want to annoy people next to me. Other problematic situation: Bluez gets updated and restarted, or the headset runs out of battery. This disconnects the headset, and this can result in my music suddenly screaming out of my internal speakers. In addition to annoy people, it's likely that if I'm actually listening to a podcast or watching a video, I will need to get back to the moment the disconnection happened because I missed what followed. The disconnection and sink switching is already a disruption in itself so pausing whatever can be paused would not add much disruption. IHMO, ideally, only things playing on this vanishing sink should be paused, not the other stuff. Pausing should be done before the sink switch. Otherwise, the sound could be heard for a brief moment or a bit of the song / video could be missed. I think this should be an option because likely not everyone want this, but it should be turned on by default because people are not likely to turn it on before being burned by the song that keeps playing after a disconnection. Maybe if the sink is back again without other user interaction / within some time interval, the song / video that has been paused could be restored automatically, a bit like when you get a call on a phone connected to the computer using KDE Connect. STEPS TO REPRODUCE 1. Play something with software that supports MPRIS 2. disconnect your headset (Bluetooth or jack) OBSERVED RESULT The player is automatically switched to another available sink. It still plays its thing, even if the sink is loud or muted. EXPECTED RESULT Whatever the player was playing is pause. Only then, the player is automatically switched to another available sink. Maybe the song/video is restored if the sink appears again. -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 405459] Adding possibility to control volume and music via bluetooth headphones
https://bugs.kde.org/show_bug.cgi?id=405459 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #2 from Raphaël Jakse --- Is this bug still current? It works for me. Should this be closed? -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 453800] Kate's Recent Files List | every entry on list can be opened only once after update to 22.04.0 (restart of Kate necessary)
https://bugs.kde.org/show_bug.cgi?id=453800 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #2 from Raphaël Jakse --- I'm not seeing the greyed out thing. I see something similar: once I open a file in Kate, either with the open file dialog or the open recent menu, I can't use the open recent menu again to focus or re-open it. I'm seeing this in Kate 22.04 and in HEAD (commit e22bd530f273ae0097ec47d9a004c60f3cbf597a). -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 453691] Feature request: list of recently closed files / restore closed tabs
https://bugs.kde.org/show_bug.cgi?id=453691 --- Comment #2 from Raphaël Jakse --- >From reading Kate's source code, I've noticed that recently open files are updated on saving a file. Maybe updating them on closing would be good enough actually? That would allow avoiding to add a new menu entry and a whole new feature for this. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 453691] Feature request: list of recently closed files / restore closed tabs
https://bugs.kde.org/show_bug.cgi?id=453691 --- Comment #1 from Raphaël Jakse --- I just noticed that the English label for the "recently open" menu in the "File" menu is actually "Open Recent", translated to "Récemment ouvert(s)" in French, which means "Recently open", which is more precise. This might be an issue to implement the "Recently Closed" menu: - The expression "Open Recent" might as well apply to recently closed file, so this could be confusing - An hypothetical menu "Recently closed" item next to "Open Recent" might look weird: differently worded for similar things, not very symmetrical. We could have "Open Recent" and "Open Recently closed" but that looks asymmetrical. (A) We could rename "Open Recent" to "Open Recently open(ed)" (don't know which one is more correct), but that looks very redundant. (B) We could rename "Open Recent" to "Recently open(ed)" (C), but then: - it is a "breaking" change - we lose the fact that the menu is written with a leading action verb - it's at odd with the nearby items beginning with "Open" -- though that never stroke me in the French version that already has this issue Or we could make the "Recently closed" as a submenu of "Open Recent" (D). That would make sense to me and would avoid cluttering the "File" menu. The vagueness of "Open Recent" would still allow it to be be accurate without rephrasing it. We'd have something weird in the French translation where "Recently closed" would be in the "Recently open" menu, but meh. Maybe we could rephrase this. Though the current phrasing is probably a compromise: it's just hard to translate "Open Recent" in a straightforward manner. I don't know how the English phrasing feels but in French that would be weird i guess. Recently closed files are still somewhat also recently open files anyway, so, that may work. My preference would be (C) or (D), and probably actually (D) more than (C). What do you think? Does the feature make sense / is it desirable anyway? -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 453691] New: Feature request: list of recently closed files / restore closed tabs
https://bugs.kde.org/show_bug.cgi?id=453691 Bug ID: 453691 Summary: Feature request: list of recently closed files / restore closed tabs Product: kate Version: 22.04.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY Kate has a recently opened files. Sometimes I close a tab inadvertently. I head over the recently opened files but the file I just closed Is not necessarily there because I could have opened a lot of files since I opened the inadvertently closed file. - A "recently closed" menu entry would be neat. Bonus if it restores the position of the cursor, or even the full state (including undo/redo). - Some menu entry / shortcut like CTRL+Shift+T in browsers to restore the tabs would be useful too, but that'd be icing on the cake SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220509 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441906] Reconnecting to internet after downtime triggers flood of notifications from apps that remained open during that time
https://bugs.kde.org/show_bug.cgi?id=441906 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #2 from Raphaël Jakse --- What about grouping notifications? If an application issues more than N notifications in a short time, display a (meta) notification saying "X notifications from this application", with the application and its icon in the notification title. A button "Show details" could open the notification drawer at the right place. It is still useful to be notified that something happened when reconnecting, leaving suspend or DND I think. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 401304] maybe inhibit suspend during updates
https://bugs.kde.org/show_bug.cgi?id=401304 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #5 from Raphaël Jakse --- Zypper on openSUSE indeed does this: it blocks the computer from going to suspend during updates. > Concerns raised: what if the user closes the lid and puts the laptop in a bag? It indeed happened to me several times that the system refuses to go on suspend without me noticing because of an update. I'm often not putting the computer in my bag at those times. When I put the computer in my bag, I'm extra careful that it did go to suspend. I have two imperfect ideas: - produce some sort of signal when the system refuses to suspend (for whatever reason). But the screen is not visible and the sound might be muted (or undesirable) - make sure to put the laptop on suspend after the updates are done. That would be a neat solution for my case: closing the lead would mean: go to sleep as soon as possible, after finishing whatever task that needs to be finished before. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 450868] Don't play (un)plugged power cable sound after resume
https://bugs.kde.org/show_bug.cgi?id=450868 --- Comment #1 from Raphaël Jakse --- > I want to make sure my computer when waking it up. is quiet. (sorry) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 450868] New: Don't play (un)plugged power cable sound after resume
https://bugs.kde.org/show_bug.cgi?id=450868 Bug ID: 450868 Summary: Don't play (un)plugged power cable sound after resume Product: frameworks-knotifications Version: 5.90.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: raphael@jakse.fr CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY I want to make sure my computer when waking it up. When the power cable is removed or plugged in while the computer is on, a sound is played, which is especially useful to notice that one has removed the cable inadvertently, or to make sure that the cable is correctly connected. That's good. However, the sound is also played after resume if the cable has been (un)plugged during suspend. This is often undesirable if one wants to wake up the computer quietly without annoying surrounding people. This sound is potentially loud, depending on the sound volume before suspend. You might remember you left the volume level high, and now if you need to quietly wake up the computer, you have no solution short of plugging a jack cable if you happen to have one nearby. A workaround is to make sure the volume is muted before suspend, but now you need to remember to do it, and sometimes you don't have time for this when suspending the computer. Another workaround is to remove the sounds for power-cable related notifications, but they are valuable, especially if you have a somewhat faulty cable or can't help disconnecting it while using the laptop by being clumsy. I'd like either: - the power-related sounds not to be played right after resume. If one would like to make sure the cable is (un)plugged, they can look at the battery icon - have the option to disable the sounds after resume. If a parameter is added, I think that should be the default. Depending on how one uses the computer, a state change is likely to occur anyway and one is definitely getting a potentially undesirable sound each time the computer is woken up. As a result, these sounds really feel like they mean "you woke me up". Resuming the computer is not an external event that can happen any time, it is a deliberate action from the user and notifying this action back to the user does not make much sense. STEPS TO REPRODUCE On a laptop: 1. make sure sounds are enabled, and notifications about the power cable being (un)plugged 2. suspend the computer 3. (un)plug it 4. wake it up OBSERVED RESULT A sound is played on resume EXPECTED RESULT The computer is quiet on resume. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.24.1 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 X11 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 447818] New: Also zoom text in Dolphin
https://bugs.kde.org/show_bug.cgi?id=447818 Bug ID: 447818 Summary: Also zoom text in Dolphin Product: dolphin Version: 21.12.0 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: view-engine: general Assignee: dolphin-bugs-n...@kde.org Reporter: raphael@jakse.fr CC: kfm-de...@kde.org Target Milestone: --- SUMMARY Usually, when I want to zoom in Dolphin, that's for easier reading (because I'm using a screen further from me than usual for instance, like when connecting the computer to a TV screen). I expect the zoom to zoom icons and texts (actually text only would do for my use cases), though it currently only zooms icons while keeping the font size. Maybe this could be an option (enabled by default?) if some people would prefer the text not to be zoomed. STEPS TO REPRODUCE 1. Open a folder 2. Zoom using ctrl+wheel or the slider OBSERVED RESULT Icons are zoomed, texts are kept at the same font size. EXPECTED RESULT Icons are zoomed, texts are zoomed. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 X11 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 443213] Display Brightness change rate adjustment
https://bugs.kde.org/show_bug.cgi?id=443213 --- Comment #2 from Raphaël Jakse --- I meant in a dark room, not screen, sorry. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 443213] Display Brightness change rate adjustment
https://bugs.kde.org/show_bug.cgi?id=443213 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #1 from Raphaël Jakse --- Additionally, it would be nice if the lowest 5% were done by increments/decrements of 1%. In a dark screen, 5% is too high and 0% is turned off (actually, 1% is still a bit too high on this screen for my eyes, being able to set 0.5% would be perfect). My current workaround it to use the wheel on the battery icon (which does increments of 1%), or setting the /sys/class/backlight/*/brightness file. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 443759] File dialog hangs in Kate when the current working folder is on the network (sftp) and unreachable
https://bugs.kde.org/show_bug.cgi?id=443759 --- Comment #1 from Raphaël Jakse --- > If the remote host becomes unreachable while navigating in the file dialog, > it hangs too. Sorry, I forgot to remove this line, this is incorrect, this actually does what is expected and shows a loading view. Sorry for the mistake. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 443759] New: File dialog hangs in Kate when the current working folder is on the network (sftp) and unreachable
https://bugs.kde.org/show_bug.cgi?id=443759 Bug ID: 443759 Summary: File dialog hangs in Kate when the current working folder is on the network (sftp) and unreachable Product: kate Version: 21.08.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY When editing remote files in Kate, if the remote host is unavailable, the open/save file dialog hangs when trying to save a file or open a new file, rendering Kate unusable for a while. The file dialog finally appears after a timeout. If the remote host becomes unreachable while navigating in the file dialog, it hangs too. This may affect other apps too. I hesitated to file this bug under the frameworks-kio product. STEPS TO REPRODUCE 1. In Kate, open a file sitting on remote computer via SFTP 2. Suspend the remote computer 3. File > Open or File > Save As OBSERVED RESULT Kate hangs for a while. EXPECTED RESULT Kate should not hang, the file dialog should be shown right away, with a loading view, as it is the case when the remote computer becomes unreachable while navigating in its folders with the file dialog. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86 Qt Version: 5.15.2 ADDITIONAL INFORMATION None -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 435318] Allow using the "²" (square) key as the compose key
https://bugs.kde.org/show_bug.cgi?id=435318 --- Comment #8 from Raphaël Jakse --- You are right. Thank your for your help! -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 435318] Allow using the "²" (square) key as the compose key
https://bugs.kde.org/show_bug.cgi?id=435318 --- Comment #6 from Raphaël Jakse --- Actually, this makes me think the I could probably package something on my own, this is not specific to KDE after all. Even better if KDE ships it by default so if you are interested, let me know and I'll look into it when I find the time. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 435318] Allow using the "²" (square) key as the compose key
https://bugs.kde.org/show_bug.cgi?id=435318 --- Comment #5 from Raphaël Jakse --- No. I just read the blog article Peter linked, and then some more out of curiosity and interest. I could fix it for myself, but was aiming for a solution that would make easy-to-use for everyone. But a custom manual XML configuration won't cut it. I'm less motivated by a solution that works only for me. I'll apply it when I'll eventually reach a point when I'm fed up with my setup. This could happen tomorrow or in a month. But I don't want to have to tell people "Hey, there's this cool feature that allows you to write useful and fun characters easily, and you can take advantage of this key that you never used in your life for that, only you need to write this XML stuff, trust me it is easy". However, if me trying this could potentially lead to a solution for all users, or at least KDE users (if, for instance, the KDE project is willing to ship such custom configuration - even in an optional package), I'll gladly look into it before reaching the fed up point :-) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 435318] Allow using the "²" (square) key as the compose key
https://bugs.kde.org/show_bug.cgi?id=435318 --- Comment #3 from Raphaël Jakse --- My bug there has been closed with the suggestion to use a local custom configuration for this, so I guess we won't see "²" as a possible option for the compose key in the GUI by default anytime soon. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 435318] Allow using the "²" (square) key as the compose key
https://bugs.kde.org/show_bug.cgi?id=435318 --- Comment #2 from Raphaël Jakse --- Thanks for the directions. I didn't find a ticket about it there so I opened a new one: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/264 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 435318] Allow using the "²" (square) key as the compose key
https://bugs.kde.org/show_bug.cgi?id=435318 Raphaël Jakse changed: What|Removed |Added Severity|normal |wishlist -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 435318] New: Allow using the "²" (square) key as the compose key
https://bugs.kde.org/show_bug.cgi?id=435318 Bug ID: 435318 Summary: Allow using the "²" (square) key as the compose key Product: systemsettings Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_keyboard Assignee: plasma-b...@kde.org Reporter: raphael@jakse.fr CC: butir...@gmail.com Target Milestone: --- SUMMARY I never use the ² key. All the keys that can be configured as the Compose key are either awkward combinations like AltGr+Menu, or keys that are useful for shortcuts / used in default shortcuts (Meta) or for window actions (alt + move). Be able to configure from the "²" key as a Compose key from the GUI would be neat. I can afford to type Circonflex + 2 to type ², I have to do it for ¹ or ³ anyway. Let's make this key eventually useful! :-) SOFTWARE/OS VERSIONS Linux/KDE Plasma: on openSUSE Tumbleweed KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.12 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 434230] Kate crashed with ASSERT: "position.column() <= text.size()" in file src/buffer/katetextblock.cpp
https://bugs.kde.org/show_bug.cgi?id=434230 --- Comment #4 from Raphaël Jakse --- Ok, I'll look at it and come back to you if I ever get "so lucky" that I succeed in reproducing the bug and have a dump. I'll try to see if a trace was logged on the machine on which it happened. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 434230] Kate crashed with ASSERT: "position.column() <= text.size()" in file src/buffer/katetextblock.cpp
https://bugs.kde.org/show_bug.cgi?id=434230 --- Comment #2 from Raphaël Jakse --- Sure. Do you happen to know how to make the Flatpak version of Kate produce a core dump or make it drop to GDB when this assert is broken? It does not seem to happen frequently, I haven't been able to reproduce it yet. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 434230] New: Kate crashed with ASSERT: "position.column() <= text.size()" in file src/buffer/katetextblock.cpp
https://bugs.kde.org/show_bug.cgi?id=434230 Bug ID: 434230 Summary: Kate crashed with ASSERT: "position.column() <= text.size()" in file src/buffer/katetextblock.cpp Product: kate Version: Git Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY Kate (latest flatpak to this date) crashed with this assert: ASSERT: "position.column() <= text.size()" in file src/buffer/katetextblock.cpp, line 82 STEPS TO REPRODUCE Unfortunately, I haven't managed to reproduce. It happened while I was typing, presumably I was hitting the enter key. I was editing a JSX file with auto indentation on. Static wrapping / return is not enabled. OBSERVED RESULT Crash EXPECTED RESULT No crash SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Buster, using the Kate Flatpak so I'm going to give the versions given in the Kate about dialog Flatpak package version: 20.12.2, master, x86_64, kdeapps KDE Plasma Version: N/A KDE Frameworks Version: 5.78 Qt Version: 5.15.2, xcb Kate version: 21.03.70 ADDITIONAL INFORMATION Using the latest master Flapak from kdeapps -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 409774] Don't show "Network disconnected" notification after the disconnect button in the plasma-nm widget is clicked
https://bugs.kde.org/show_bug.cgi?id=409774 --- Comment #9 from Raphaël Jakse --- Sadly, I fully believe this. I don't know why, and this might be due to the recent improvements related to the notifications, this has been less an issue for me. Ah, yes, obviously after rereading my comment from last year: the notifications do not cover the network widget anymore! -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 416868] New: Offer to enable Bluetooth if disabled when trying to join a Bluetooth connection
https://bugs.kde.org/show_bug.cgi?id=416868 Bug ID: 416868 Summary: Offer to enable Bluetooth if disabled when trying to join a Bluetooth connection Product: plasma-nm Version: 5.17.5 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: jgrul...@redhat.com Reporter: raphael@jakse.fr Target Milestone: --- Hello, I tried to join a Bluetooth connection. The option to connect was not present. After some time, I realized this was because I disabled Bluetooth. It's okay, it's just me being dumb. For dumb people like me, though, the network editor / applet could instead offer to enable Bluetooth and then connect instead. In the network editor, it could be done by showing a "Enable Bluetooth and connect" action instead of the regular "Connect" option. In the applet, a dialog could be shown: "To join this network, Bluetooth needs to be enabled. Do you want to enable Bluetooth and join this network?", or something. What do you think? -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 413672] New: Autoscroll devices when drag and dropping a stream
https://bugs.kde.org/show_bug.cgi?id=413672 Bug ID: 413672 Summary: Autoscroll devices when drag and dropping a stream Product: plasma-pa Version: 5.17.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: applet Assignee: now...@gmail.com Reporter: raphael@jakse.fr CC: plasma-b...@kde.org Target Milestone: --- Created attachment 123620 --> https://bugs.kde.org/attachment.cgi?id=123620&action=edit Video of the drag and drop behavior with a long list of devices SUMMARY In the volume control applet, drag-and-dropping a stream on a device is a convenient feature. However, when there are many outputs, it seems impossible to drop a stream on the last outputs. See the attached video. STEPS TO REPRODUCE 1. left button on an audio stream 2. drag to tab "Devices" 3. try to put the stream on a device that is at the bottom of the long list of devices OBSERVED RESULT Cannot reach the device. EXPECTED RESULT Can reach the device, maybe by having the list auto scroll WORKAROUND Use hamburger icon on the stream (which is actually even more convenient - I just noticed it!) -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 409774] Don't show "Network disconnected" notification after the disconnect button in the plasma-nm widget is clicked
https://bugs.kde.org/show_bug.cgi?id=409774 Raphaël Jakse changed: What|Removed |Added CC||raphael@jakse.fr --- Comment #3 from Raphaël Jakse --- An additional element to assess this bug: a problem I found with this behavior is that at times, the notifications prevent the user from using plasma-nm to connect to another network until the user closes them, because they cover the widget. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 408527] Phone led keeps blinking after answering a text with KDE Connect
https://bugs.kde.org/show_bug.cgi?id=408527 Raphaël Jakse changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|RESOLVED --- Comment #8 from Raphaël Jakse --- I can't reproduce this bug anymore. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 411784] New: KDEConnect: send to device (from Dolphin): autoselect the only available device
https://bugs.kde.org/show_bug.cgi?id=411784 Bug ID: 411784 Summary: KDEConnect: send to device (from Dolphin): autoselect the only available device Product: kdeconnect Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: raphael@jakse.fr Target Milestone: --- In dolphin, when right-clicking on a file and clicking "Send to device" in the "Share" menu, a list of devices is shown. If only one device is listed (or multiple devices are listed, but only one is available), it seems pointless to have to "choose". So here are three suggestions: - The only available device may be auto selected. Then, the file can be sent by pressing "enter" (or clicking ok). If two devices are available, no device should be selected. - The dialog to choose the device might be skipped altogether, especially in the case where only one device is registered anyway. - In Dolpin, instead of one entry "Send to device", multiple entries "Send to X" might be shown instead. (OS: updated openSUSE Tumbleweed) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 410818] New: Generic icon displayed when typing the name of a file instead of using the list in KFileDialog
https://bugs.kde.org/show_bug.cgi?id=410818 Bug ID: 410818 Summary: Generic icon displayed when typing the name of a file instead of using the list in KFileDialog Product: frameworks-kio Version: unspecified Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Open/save dialogs Assignee: fa...@kde.org Reporter: raphael@jakse.fr CC: kdelibs-b...@kde.org Target Milestone: --- Created attachment 122064 --> https://bugs.kde.org/attachment.cgi?id=122064&action=edit A video of the bug SUMMARY When typing the name of a file in the Name field, the file is selected. However, the icon in the Name Field is generic. When selecting a file using the list, the icon is the actual icon of the file. STEPS TO REPRODUCE 1. In Kate, File > Open 2. Type the name of an existing file that should not have a generic file name OBSERVED RESULT A generic icon is displayed. If the name of a folder is typed, the icon of a generic file is displayed. EXPECTED RESULT A specific icon should be displayed. If the name of a folder is typed, the icon of a folder should be displayed. SOFTWARE/OS VERSIONS: Current Neon Docker -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 410817] New: Select files from the address (folder) bar in KFileDialog
https://bugs.kde.org/show_bug.cgi?id=410817 Bug ID: 410817 Summary: Select files from the address (folder) bar in KFileDialog Product: frameworks-kio Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Open/save dialogs Assignee: fa...@kde.org Reporter: raphael@jakse.fr CC: kdelibs-b...@kde.org Target Milestone: --- Hello, I find myself often trying to start typing a file name in the address bar of the open / save dialog. When doing this, nothing happens, and if the file name is completely typed and then the enter key is pressed, the dialog tries to open the file as a folder, and this obviously fails. Conversely, typing an address / a folder name in the "Name" field of the dialog works (which, by the way, has by far the best behavior I could notice across the different file dialogs I was (un)lucky to come across). I think the current behavior of trying to open a file entered in the address bar as a folder and fail is not intuitive. I have two (contradictory) suggestions: 1) Either make the address bar act like the name field, with the optional difference that folders should be selected / suggested before files. 2) Or keep the current behavior of suggesting folders as they are typed, and then files. When enter is pressed: 2.1) Either open the selected file 2.2) Or show a dialog telling the user that this is a file (and not a folder). "Would you like to open this file (or) replace the existing file?". In both cases, if (the prefix of) a file is entered / selected in the address bar, the file's icon should be shown instead of the folder icon in the address bar. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 410632] Scale Factor 1 is actually 2 on a HiDPI screen
https://bugs.kde.org/show_bug.cgi?id=410632 Raphaël Jakse changed: What|Removed |Added Resolution|NOT A BUG |FIXED --- Comment #3 from Raphaël Jakse --- This was fixed on today's update. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 410632] Scale Factor 1 is actually 2 on a HiDPI screen
https://bugs.kde.org/show_bug.cgi?id=410632 --- Comment #2 from Raphaël Jakse --- Hello Nate, Fractional scaling on Plasma and Wayland is very good news. I was holding off because of this and support for middle click paste. I actually tried the Wayland session after this bug report and saw that apps are run in XWayland by default, so I actually have a fully functional desktop there. I'll probably keep using it. And I fully understand that my X11 setup is not supported. It's more like a hack that I grown accustomed to. However, I still think that there is a bug in the UI in the case an X11 session is used that should be solved. Hack or not, I don't see why setting the scaling factor to exactly 1 should not be possible. If it says scaling factor=1 in the settings, the scaling factor should be 1, not 2. It seems that 1 currently means "auto", which seems wrong. It took me time to try to understand what was going on. On my computer, it is impossible to set scaling factor=1, though the UI is pretending I can. It does not make sense. It seems for me that an option should me added, "Auto", which is the current behavior of "1". I don't have this issue on the Wayland session, where scaling factor 1 is actually 1. I'm happy with the Wayland session now, which I discovered thanks to this issue, but I still think that this bug should be fixed as long as the Xorg session is used by default in most distros. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 410632] New: Scale Factor 1 is actually 2 on a HiDPI screen
https://bugs.kde.org/show_bug.cgi?id=410632 Bug ID: 410632 Summary: Scale Factor 1 is actually 2 on a HiDPI screen Product: KScreen Version: 5.16.3 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: se...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY I have been using Plasma on an Elitebook 840 G3 laptop with a WQHD (HiDPI) screen, with X11. I'm using this screen without scaling, and instead zooming the text everywhere I need to read things. I also adjusted the font sizes in the settings so the texts in the UI are not too small. I am doing that because I regularly use external screens with regular DPI. I connected a 4K TV screen, disabled the internal screen, and set the scaling factor to 1.3 (anyway, something else other than 1). So far so good. I then disconnected the TV screen and wanted to restore the scaling factor to 1. To my surprise, this has the same effect than setting the scaling factor to 2. This can be seen by invoking the disconnect screen (Ctrl+Alt+Del). I created a new user to test this behavior on a clean session. By default, the scaling factor is obviously set to something else than 1, probably 2. In the settings, the scaling factor is 1. setting to 1.1 makes things smaller. I am unable to actually obtain a screen factor of 1. in the ~/.config/kdeglobals file, I can see: [KScreen] ScaleFactor=1 ScreenScaleFactors=eDP-1=1;DP-1=1;HDMI-1=1;DP-2=1;HDMI-2=1; If I remove this section, the scaling factor is still 1 in the settings, 2 in reality. The system behaves as if 1 was some sort of unset value, and the default "detected" scaling factor is used instead of 1. STEPS TO REPRODUCE 1. On an Hi DPI laptop, set the scaling factor to 1.1. 2. Then, set it to 1. OBSERVED RESULT The real scaling factor is something else than 1. EXPECTED RESULT the real scaling factor should match the setting : 1. A default scaling factor different from 1 is fine. On my screen, 2 is picked, but this is a bit too much. 1.5 would be the perfect theoretical value if this was flawless. 2 is still probably better than 1 however. The current workaround is to set the scaling factor to 1.1, but I will need to be able to set it to 1 whenever I plug a non Hi DPI screen to the computer. Wayland would be the perfect solution to this problem, but bug #373907 is a deal breaker for me. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed KDE Plasma Version: 5.16.3 KDE Frameworks Version: 5.60 Qt Version: 5.13 -- You are receiving this mail because: You are watching all bug changes.
[kile] [Bug 274440] Kile: syntax highlighting failed to match aligned environment within equation
https://bugs.kde.org/show_bug.cgi?id=274440 Raphaël Jakse changed: What|Removed |Added Platform|Gentoo Packages |openSUSE RPMs Version|2.1b5 |2.9.92 --- Comment #15 from Raphaël Jakse --- Still current in Kile version 2.9.92. -- You are receiving this mail because: You are watching all bug changes.
[kile] [Bug 274440] Kile: syntax highlighting failed to match aligned environment within equation
https://bugs.kde.org/show_bug.cgi?id=274440
Raphaël Jakse changed:
What|Removed |Added
CC||raphael@jakse.fr
--- Comment #14 from Raphaël Jakse ---
I just ran into this issue in the latest Kate with the following text:
\begin{align}
\begin{aligned}
\end{aligned}
\end{align}
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 410477] New: Syntax Highlighting LaTeX: wrong color for \end{split} in environment equation
https://bugs.kde.org/show_bug.cgi?id=410477
Bug ID: 410477
Summary: Syntax Highlighting LaTeX: wrong color for \end{split}
in environment equation
Product: kate
Version: Git
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: syntax
Assignee: kwrite-bugs-n...@kde.org
Reporter: raphael@jakse.fr
Target Milestone: ---
Created attachment 121880
--> https://bugs.kde.org/attachment.cgi?id=121880&action=edit
Screenshot of the issue (wrong color for \end{split} is an equation
environment)
With the following text using LaTeX syntax highlighting:
\begin{equation}
\begin{split}
1+1
\end{split}
\end{equation}
OBSERVED
Both "equation" words and the first "split" word are in bold blue.
1+1 is in orange (as probably expected)
"split}" is in orange.
EXPECTED
The second "split" should be in bold blue, the closing brace right after should
be in black.
VERSION:
Updated openSUSE Tumbleweed and Neon docker image.
SEE ALSO
Related: https://bugs.kde.org/show_bug.cgi?id=274440
--
You are receiving this mail because:
You are watching all bug changes.
[plasma-pa] [Bug 410230] Make it easy to listen to a microphone / an input sink
https://bugs.kde.org/show_bug.cgi?id=410230 --- Comment #1 from Raphaël Jakse --- It just occurred to me that putting microphones in the Applications tab might be a bit confusing since they are not really applications. Solutions I see are: - renaming the Applications tab to "Audio sources", which seems clear and simple - adding a third tab, but I don't like this solution very much -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 410230] New: Make it easy to listen to a microphone / an input sink
https://bugs.kde.org/show_bug.cgi?id=410230 Bug ID: 410230 Summary: Make it easy to listen to a microphone / an input sink Product: plasma-pa Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: applet Assignee: now...@gmail.com Reporter: raphael@jakse.fr CC: plasma-b...@kde.org Target Milestone: --- I wanted to listen to my phone's output through Bluetooth. It took me a long time to understand how to do it: launch pavucontrol, go to the "Recording" tab, "show all stream" and unmute the relevant loopback sink. I just discovered that I can do this using KMix too. KMix is not installed by default, neither is pavucontrol, on a standard KDE/Plasma environment. Listening to one's microphone seems pretty common and is done in the same way. In the current situation, a regular user would probably be unable to do this on Plasma. I think it should be an easy thing to do. Maybe using a checkbox, or (better?) by showing the loopback devices in the "Applications" tab, so they can be unmuted and the sound volume can be set. The fact that two sliders at two different places need to be adjusted for the microphone might be confusing however. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 409400] The list of networks gets updated while the cursor is over it
https://bugs.kde.org/show_bug.cgi?id=409400 --- Comment #2 from Raphaël Jakse --- > Showing updates about the connections in a popup instead wouldn't be a good > experience in my opinion and forcing users to reload the list manually as > well. Right. > What we should do and there was another bug about it, is that we should stop > updating the UI when password dialog is shown in the applet, because it might > happen that while you are typing the password, you can get the dialog to > disappear, which is pretty annoying. Definitely. But that would not cover the case where the user has their cursor on a network, is about to click on it and the network has been replaced by another because of a list update. What about updating the list, but ensuring that the specific network under the cursor does not move e.g. by playing with the scroll position? This does not fix the issue when the user is moving toward the network and the network moves when the network is close but not under the cursor… -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 409932] New: Allow to open a link using text search
https://bugs.kde.org/show_bug.cgi?id=409932 Bug ID: 409932 Summary: Allow to open a link using text search Product: okular Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY I recently discovered a nice feature of Web browsers. One can select a link by searching for its text and hitting escape. Then, hitting Enter opens the link, Ctrl+Enter opens the link in a new tab and Shift+Enter opens the link in a new window. I find this is a nice usability feature and a nice to have for navigating inside PDFs in Okular without the mouse. STEPS TO REPRODUCE 1. Open a PDF with a table of contents. 2. Hit CTRL+F and type a part of a title. 3. The text in a link is highlighted. Hit escape. OBSERVED RESULT The search box is closed. EXPECTED RESULT 1) The search box is closed. 2) If such a thing is possible in Okular, the link is selected (if not, this would be another nice-to-have thing, so (shift+)tab can be used to navigate through links, let me know if I should report another whish here). 3) Hitting enter activates the link in which the highlighted text is. I don't know how text search and highlighting are implemented in Okular, but I suspect it could amount to: on Enter pressed, search for the first link in the active highlighted text. If such a link exists, activate it. It would also allow "clicking" on footnotes with the keyboard. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 409849] Wrong braces matching with macro \textcolor when syntax highlighting a LaTeX file
https://bugs.kde.org/show_bug.cgi?id=409849 Raphaël Jakse changed: What|Removed |Added Attachment #121541|\textcolor and unballanced |\textcolor and unbalanced description|braces |braces -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 409849] New: Wrong braces matching with macro \textcolor when syntax highlighting a LaTeX file
https://bugs.kde.org/show_bug.cgi?id=409849
Bug ID: 409849
Summary: Wrong braces matching with macro \textcolor when
syntax highlighting a LaTeX file
Product: kate
Version: Git
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: syntax
Assignee: kwrite-bugs-n...@kde.org
Reporter: raphael@jakse.fr
Target Milestone: ---
Created attachment 121541
--> https://bugs.kde.org/attachment.cgi?id=121541&action=edit
\textcolor and unballanced braces
SUMMARY
Braces are not matched correctly when using \textcolor
STEPS TO REPRODUCE
1. In kate, type \textcolor{h}{{}
2. Enable LaTeX syntax highlighting
3. put the cursor on the last brace.
OBSERVED RESULT
The last brace is matched with the second opening brace. If a closing brace is
added to balance braces, the last brace is not matched with any brace.
EXPECTED RESULT
The last brace should be matched with the third opening brace. If a closing
brace is added to balance braces, the last brace should be matched with the
second opening brace.
SOFTWARE/OS VERSIONS: latest Neon unstable docker image
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 409849] Wrong braces matching with macro \textcolor when syntax highlighting a LaTeX file
https://bugs.kde.org/show_bug.cgi?id=409849 --- Comment #1 from Raphaël Jakse --- Created attachment 121542 --> https://bugs.kde.org/attachment.cgi?id=121542&action=edit \textcolor and unbalanced braces -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 409849] Wrong braces matching with macro \textcolor when syntax highlighting a LaTeX file
https://bugs.kde.org/show_bug.cgi?id=409849 Raphaël Jakse changed: What|Removed |Added Attachment #121542|\textcolor and unbalanced |\textcolor and balanced description|braces |braces -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 409612] Disable shadows when windows are put side by side
https://bugs.kde.org/show_bug.cgi?id=409612 --- Comment #8 from Raphaël Jakse --- Fair enough. I still think this would be beneficial. I guess working on this idea would require thorough thinking if more people wanted this, to avoid breaking people's workflow (https://xkcd.com/1172/). Should someone be interested in this in the future, I'm willing to participate in the, don't hesitate to shout at me. Thanks for your time, and particularly Nate for kindly answering my wishes / ideas here every single time! Christoph Feck: Thanks for your suggestion. Kile is really nice, though this bug prevents me from really using it: https://bugs.kde.org/show_bug.cgi?id=406836 I can't write a patch for now, maybe later when I have more time if this is still an issue. I also use texstudio from time to time for grammar spelling, but it has a similar bug unfortunately (and it's not Kate, which I became somewhat dependent on…). -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 409813] Wrong label for focusing the terminal in the Tools menu when the terminal was closed from the command line
https://bugs.kde.org/show_bug.cgi?id=409813 --- Comment #1 from Raphaël Jakse --- Created attachment 121524 --> https://bugs.kde.org/attachment.cgi?id=121524&action=edit A video of the bug -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 409813] New: Wrong label for focusing the terminal in the Tools menu when the terminal was closed from the command line
https://bugs.kde.org/show_bug.cgi?id=409813 Bug ID: 409813 Summary: Wrong label for focusing the terminal in the Tools menu when the terminal was closed from the command line Product: kate Version: Git Platform: Neon Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY In the Tools menu, if the terminal was closed using CTRL+D or command "exit", the "Focus terminal" item is wrongly labeled "Defocus Terminal" STEPS TO REPRODUCE 1. Open kate. The terminal is initially closed. If open, close it. 2. Open the Tools menu. Click on the rightly labeled "Focus Terminal" 3. Type exit or ctrl+D in the terminal 4. Open the Tools menu. OBSERVED RESULT The terminal is not focused nor open, but item "Focus Terminal" is labeled "Defocus Terminal". Activating it actually focuses the terminal. EXPECTED RESULT The item is labelled "Focus Terminal", or "Toggle Terminal Focus" SOFTWARE/OS VERSIONS Latest Docker Neon Unstable image and openSUSE Tumbleweed. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 409612] Disable shadows when windows are put side by side
https://bugs.kde.org/show_bug.cgi?id=409612 --- Comment #5 from Raphaël Jakse --- Created attachment 121520 --> https://bugs.kde.org/attachment.cgi?id=121520&action=edit Okular and kate side by side - without shadows -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 409612] Disable shadows when windows are put side by side
https://bugs.kde.org/show_bug.cgi?id=409612 --- Comment #4 from Raphaël Jakse --- Created attachment 121519 --> https://bugs.kde.org/attachment.cgi?id=121519&action=edit Okular and kate side by side - with shadows -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 409612] Disable shadows when windows are put side by side
https://bugs.kde.org/show_bug.cgi?id=409612 --- Comment #3 from Raphaël Jakse --- To be completely clear, I agree that shadows in the general case should stay, and removing them would be problematic (unfortunately, I screwed up my previous message). Had I found them useless in the general case, I would have completely disabled them. I take note that this is considered intentional but for posterity, here are screenshots where I find shadows distracting rather than helpful, and focus enough shown thanks to the title bars. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 409657] Add buttons in the plasmoid to send keys (next, previous, pause, play, volume+, volume-)
https://bugs.kde.org/show_bug.cgi?id=409657 --- Comment #4 from Raphaël Jakse --- Indeed, I haven't found a way to interact with the VLC notification. I will open a new bug for that. Feel free to close this bug :-) -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 409657] Add buttons in the plasmoid to send keys (next, previous, pause, play, volume+, volume-)
https://bugs.kde.org/show_bug.cgi?id=409657 --- Comment #2 from Raphaël Jakse --- > You can already control the phone's music using the "kcapp" application (it's > experimental though, so it might not currently be packaged for your > distribution). Indeed it is not. But it is great to know! > In the future, we expect to enable MPRIS controls for it too, so it can be > controlled like other media players on your desktop. There's no timeline for > this though. Nice :-) Another idea I had when writing this bug report: music often can be controlled by touching buttons on a notification. More generally, some apps have buttons in their notifications. Would it be worth to be able to activate them from KDEConnect? > Regarding turning the screen on/off: what would you use it for? I'm not entirely sure this is even possible in Android. To scare my neighbors :-) I don't remember why I mentioned this. This would probably not be a killer feature. This is certainly possible since scrcpy does provide this feature. The screen is turned on when scrcpy is run, or when the screen is right-clicked on the computer. Turning the screen off is also possible by pressing a key on the keyboard. See https://github.com/Genymobile/scrcpy/#shortcuts It's probably done by sending KEYCODE_POWER, KEYCODE_WAKEUP or KEYCODE_SLEEP to the device (https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_WAKEUP). -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 409658] New: Stream sound through KDE-Connect
https://bugs.kde.org/show_bug.cgi?id=409658 Bug ID: 409658 Summary: Stream sound through KDE-Connect Product: kdeconnect Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: raphael@jakse.fr Target Milestone: --- Hello, I often want to stream music to the phone from the computer, or from the computer to the phone. Streaming sound from the phone to the computer is somewhat possible using Bluetooth, if the computer happens to be a laptop or a tablet or has a bluetooth adapter, by making the computer advertise itself as a sound device using PulseAudio. The biggest problems here is requiring Bluetooth support on the computer and having to fiddle with settings, and distance between the phone and the computer. The reverse is also possible, by using Simple Protocol Player (https://kaytat.com/blog/?page_id=301), but this is hard to setup, or by using the PulseAudio server built in XServer XSDL, but I found it does not work reliably and requires leaving the app at the foreground and the screen on. It also requires running apps using the PULSE_SERVER environment on the computer, since XServer XSDL does not advertise its PulseAudio Server using Avahi. It would be great if KDEConnect could add a PulseAudio sink that would stream audio to the phone. What do you think about this? The reverse (playing sound from the phone on the computer) is probably harder / impossible to do (I don't know if Android APIs allow to hijack sound playing on the device), but it would be a nice feature. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 409657] New: Add buttons in the plasmoid to send keys (next, previous, pause, play, volume+, volume-)
https://bugs.kde.org/show_bug.cgi?id=409657 Bug ID: 409657 Summary: Add buttons in the plasmoid to send keys (next, previous, pause, play, volume+, volume-) Product: kdeconnect Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: plasmoid Assignee: albertv...@gmail.com Reporter: raphael@jakse.fr Target Milestone: --- Hello, sometimes, I use the phone to play music, and I am using the computer. It would be nice to be able to skip, pause and resume the current song or go to the previous one, and control the volume from the plasmoid to the phone. Buttons could be added at the top of the phone item in the plasmoid for instance. If you find that this might bloat the UI, maybe it could be configurable and disabled by default? Other button that could be useful: power (so the screen can be turned on / off from the computer). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 409612] New: Disable shadows when windows are put side by side
https://bugs.kde.org/show_bug.cgi?id=409612 Bug ID: 409612 Summary: Disable shadows when windows are put side by side Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY I like to put windows side by side when I work with both / all them at the same time (maybe editing a document in a text editor and showing it with a PDF viewer), and KWin has support to make this easy. However, while I like shadows under windows, I find them distracting when they are put side by side. The easy workaround on X11 is to disable compositing (using Alt+Shift+F12) but this does not feel like a satisfying long-term solution. I'd argue that shadows are useless, and actu in this specific case and that KWin should not draw them (it could instead offer an option to merge the borders and allow resizing the two windows sharing the border at the same time, but this is an idea for another bug report). STEPS TO REPRODUCE 1. Put two windows side by side (e.g. by moving one window to the left of the screen and another to the right, or top/bottom), or 4 windows at the corners. OBSERVED RESULT In a setting with two windows, the shadow of the window having the focus partly covers the other window. In a setting with four windows, this is a mess. EXPECTED RESULT No shadow should be drawn when the whole workplace is filled with non-overlapping windows. This probably do not "cover" (pun intended) all cases, but it should work for most common ones. Additionally, it may be nicer if the corners are squared, like when windows are maximized. This may be seen as a generalization of the case when a window is maximized (but with resizable windows). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 352476] Keyboard navigation in systray and the popup
https://bugs.kde.org/show_bug.cgi?id=352476 Raphaël Jakse changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=409488 -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 409488] New: Ease keyboard navigation to select a network
https://bugs.kde.org/show_bug.cgi?id=409488 Bug ID: 409488 Summary: Ease keyboard navigation to select a network Product: plasma-nm Version: unspecified Platform: Other OS: Linux Status: REPORTED Keywords: usability Severity: wishlist Priority: NOR Component: applet Assignee: jgrul...@redhat.com Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY Typing in the network manager applet to get the networks filtered is a really nice feature. Keyboard navigation with up/down arrows and the enter key should be possible. STEPS TO REPRODUCE 1. Type the beginning of a network around you 2. Type on up and down arrows OBSERVED RESULT Nothing happens EXPECTED RESULT A KRunner-like behavior. Networks should be selected. Typing enter should allow joining / leaving the selected network. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 409417] New: When using Bluetooth for internet connection, the same icon is used for the network and the bluetooth manager
https://bugs.kde.org/show_bug.cgi?id=409417 Bug ID: 409417 Summary: When using Bluetooth for internet connection, the same icon is used for the network and the bluetooth manager Product: plasma-nm Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: applet Assignee: jgrul...@redhat.com Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY When using Bluetooth for internet connection, the same icon is used for the network and the bluetooth manager. This is a bit confusing STEPS TO REPRODUCE 1. Connect to Internet using Bluetooth (shared from a phone, for instance) OBSERVED RESULT The network and the Bluetooth manager both get the same icon, the Bluetooth logo with a dotted line in the middle. EXPECTED RESULT The two managers should use a different icon so they can be distinguished. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 409400] New: The list of networks gets updated while the cursor is over it
https://bugs.kde.org/show_bug.cgi?id=409400
Bug ID: 409400
Summary: The list of networks gets updated while the cursor is
over it
Product: plasma-nm
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: applet
Assignee: jgrul...@redhat.com
Reporter: raphael@jakse.fr
Target Milestone: ---
SUMMARY
Often, when trying to connect to a network, the list / order of networks is
updated just when I am about to click. This is annoying because it makes me try
to join the wrong network.
This annoyance probably affects many products outside of KDE. Just yesterday, I
noticed this issue on two Android phones twice. But KDE probably can do better
here (and Android phones usually don't have mice, which a regular Plasma
desktop has).
STEPS TO REPRODUCE
1. Go with your computer to an area with a lot of wireless networks
2. Place your cursor on the list of network
OBSERVED RESULT
The list gets updated at some point.
The network under your cursor is probably not the same as before
EXPECTED RESULT
The list does not move while the cursor is over it. A message warns the user
that the list is not updated while the cursor is over it. Networks that becomes
unavailable should be grayed out or shown in red, and if clicked, a message
should be shown: "This network became unavailable in the meantime", or
something. If new networks appeared, maybe some GUI element / a message ("new
networks available, please refresh if you want to see them") can suggest the
user to refresh the list themself (as long as this element does not move the
list, of course).
--
You are receiving this mail because:
You are watching all bug changes.
[plasma-nm] [Bug 409361] Notifications about disconnected networks should not be persistent
https://bugs.kde.org/show_bug.cgi?id=409361 Raphaël Jakse changed: What|Removed |Added Assignee|kdelibs-b...@kde.org|jgrul...@redhat.com Component|general |applet Product|frameworks-knotifications |plasma-nm -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 409361] New: Notifications about disconnected networks should not be persistent
https://bugs.kde.org/show_bug.cgi?id=409361 Bug ID: 409361 Summary: Notifications about disconnected networks should not be persistent Product: frameworks-knotifications Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: raphael@jakse.fr CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY Whenever the computer is disconnected from the network (for instance, a wired connection or a wireless network), a notification is shown (which, I guess, is good). However, if not dismissed, the notification is kept in the notification list and is shown as notification to be read. This is a very small annoyance but a network disconnection should not require the user to explicitly read and dismiss this kind of notifications. The user can see that they are not connected to this network by using the network manager icon. STEPS TO REPRODUCE 1. Disconnect from a network 2. Do not dismiss the notification about the disconnection. OBSERVED RESULT The notification goes into the list of notification, marked as unread. EXPECTED RESULT The notification should simply go away, like notifications about joining a network. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.13.0 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 408903] New: Allow asking for a receipt when sending a text
https://bugs.kde.org/show_bug.cgi?id=408903 Bug ID: 408903 Summary: Allow asking for a receipt when sending a text Product: kdeconnect Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: raphael@jakse.fr Target Milestone: --- Hello, I like to be sure that my recipients are receiving my texts, so I enable receipts on the SMS application I'm using. However, when sending a text from KDEConnect, I don't get receipts. Could it be possible to have an option for that in KDEConnect? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 408527] Phone led keeps blinking after answering a text with KDE Connect
https://bugs.kde.org/show_bug.cgi?id=408527 --- Comment #7 from Raphaël Jakse --- As a workaround, I just found that manually dismissing the notification from KDE Connect is possible and works well. Which is not perfect but convenient enough. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 408565] autocomplete
https://bugs.kde.org/show_bug.cgi?id=408565 Raphaël Jakse changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #1 from Raphaël Jakse --- Sorry, it seems I have trouble using my keyboard. Closing this useless bug. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 408565] autocomplete
https://bugs.kde.org/show_bug.cgi?id=408565 Raphaël Jakse changed: What|Removed |Added Priority|NOR |VLO Severity|normal |minor -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 408565] New: autocomplete
https://bugs.kde.org/show_bug.cgi?id=408565 Bug ID: 408565 Summary: autocomplete Product: frameworks-ktexteditor Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: multicursor Assignee: m...@svenbrauch.de Reporter: raphael@jakse.fr Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 408564] New: Autocompletion only completes the current word using block selection with several lines
https://bugs.kde.org/show_bug.cgi?id=408564 Bug ID: 408564 Summary: Autocompletion only completes the current word using block selection with several lines Product: frameworks-ktexteditor Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: multicursor Assignee: m...@svenbrauch.de Reporter: raphael@jakse.fr Target Milestone: --- Created attachment 120784 --> https://bugs.kde.org/attachment.cgi?id=120784&action=edit A video of the bug SUMMARY When trying to use autocompletion while editing several lines at once, only the current line is autocompleted. STEPS TO REPRODUCE 1. In Kate, type hello 2. Hit enter three times 3. enable block selection (Ctrl+Shift+B) 4. select the three empty lines (2×Shift+Up) 5. type "hel" 6. "hello" should be suggested in the autocompletion popup. If not, ctrl+space 7. Arrow down to the "hello", and then hit Enter OBSERVED RESULT Line 2 is autocompleted EXPECTED RESULT Line 2, 3 and 4 are autocompleted SOFTWARE/OS VERSIONS Linux/KDE Plasma: On openSUSE Tumbleweed, Debian, Ubuntu… KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.58.0 Qt Version: 5.13.3 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 408527] Phone led keeps blinking after answering a text with KDE Connect
https://bugs.kde.org/show_bug.cgi?id=408527 --- Comment #6 from Raphaël Jakse --- Well, I just sent a reply to a text from KDE connect and the led stopped blinking. Weird. However my last suggestion could still be worth it, so I let the bug open so you can decide what is best. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 408527] Phone led keeps blinking after answering a text with KDE Connect
https://bugs.kde.org/show_bug.cgi?id=408527 --- Comment #5 from Raphaël Jakse --- Would it be desirable to implement a "notification dismiss workaround" in KDE Connect that one could enable? Or, the notification could be dismissed as soon as the message is displayed on the computer, which QKSMS can't know. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 408527] Phone led keeps blinking after answering a text with KDE Connect
https://bugs.kde.org/show_bug.cgi?id=408527 --- Comment #4 from Raphaël Jakse --- Sure. Relevant bug: https://github.com/moezbhatti/qksms/issues/1445 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 408527] Phone led keeps blinking after answering a text with KDE Connect
https://bugs.kde.org/show_bug.cgi?id=408527 --- Comment #2 from Raphaël Jakse --- > The notification gets dismissed but the LED stays? No, the notification (produced by QKSMS, but I think I already had the issue with the regular SMS app - I cannot reproduce, because since I updated by phone to Android Pie, the Led does not blink anymore with the regular SMS app) is still there. Is it possible for KDE Connect to dismiss a notification from QKSMS? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 408527] New: Phone led keeps blinking after answering a text with KDE Connect
https://bugs.kde.org/show_bug.cgi?id=408527 Bug ID: 408527 Summary: Phone led keeps blinking after answering a text with KDE Connect Product: kdeconnect Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: raphael@jakse.fr Target Milestone: --- When I answer a text with the computer from KDE Connect, the phone's led notification keeps blinking. Though it is obvious that I read the very message that makes the phone blink in the first place. And I don't really want to unlock the phone to make it stop blinking. If it's not just me, I suspect it's not easy to fix (it seems to involve controlling the notification of the SMS app? Maybe it requires some kind of integration with this app?), but I did not find any bug report on this so here it is. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 408511] New: Night mode for Okular
https://bugs.kde.org/show_bug.cgi?id=408511 Bug ID: 408511 Summary: Night mode for Okular Product: okular Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: raphael@jakse.fr Target Milestone: --- Hello, Since this is becoming a popular everywhere, a night mode for Okular would be nice. It is actually possible to achieve that for many PDFs going to Settings, accessibility, check Modify colors, choose Invert color. I feel this might be a popular setting that could go in the "Show" menu. It would not really be night mode, but "Invert colors" is probably clear enough. I thing going all the way to the accessibility setting (and discovering it) is less than ideal. I also think many people do not see it as an accessibility feature but as a preference. What do you think? (See also this Ask Ubuntu post, second result for "Okular night mode" in DuckDuckGo https://askubuntu.com/questions/472540/is-there-a-pdf-reader-allowing-me-to-change-background-color-of-arxiv-pdfs) -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 380399] VPN login dialog too small
https://bugs.kde.org/show_bug.cgi?id=380399 --- Comment #9 from Raphaël Jakse --- Created attachment 120721 --> https://bugs.kde.org/attachment.cgi?id=120721&action=edit Kwin workaround so the window opens at the right size -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 380399] VPN login dialog too small
https://bugs.kde.org/show_bug.cgi?id=380399 --- Comment #8 from Raphaël Jakse --- Created attachment 120720 --> https://bugs.kde.org/attachment.cgi?id=120720&action=edit The right (expected) size -- You are receiving this mail because: You are watching all bug changes.
