[extra-cmake-modules] [Bug 489827] New: Spurious automatic dependency on Poppler "Core" requires rebuild each time Poppler breaks ABI
https://bugs.kde.org/show_bug.cgi?id=489827 Bug ID: 489827 Summary: Spurious automatic dependency on Poppler "Core" requires rebuild each time Poppler breaks ABI Classification: Frameworks and Libraries Product: extra-cmake-modules Version: unspecified Platform: Compiled Sources OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: ecm-bugs-n...@kde.org Reporter: rjvber...@gmail.com Target Milestone: --- *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY Poppler has a habit of breaking ABI in its core library even for minor version updates like 24.01.0 to 24.04.0 . In my experience code that only uses the Qt4 or Qt5 interface libraries is not affected by such breakage as the interface API and ABI have proven to be as stable as the `SOVERSION` of libpoppler-qt? promises. ECM's FindPoppler module adds a dependency on Poppler's "Core" module however, which is still unnecessary as of Poppler 24.04.0 but causes binaries to have a hard dependency on the presence of a specific libpoppler version in addition to the actually required libpoppler-qt? file. As a result, these binaries often fail to load after a Poppler upgrade and need to be rebuilt. This puts an unnecessary burden on package maintainers and users like me who build everything themselves. STEPS TO REPRODUCE 1. Build and install the KFileMetadata and/or Okular from source (also tested with Kile and Tellico) 2. Upgrade Poppler to a version with a different libpoppler.so SOVERSION (e.g. 24.01.0 to 24.04.0) 3. Try to use the KFMD framework or opening a PDF file in Okular OBSERVED RESULT Failure at step 3 because of a missing libpoppler.x.so file (with x=133 in the example above) EXPECTED RESULT The dependent software should continue to function. SOFTWARE/OS VERSIONS Observed on Mac and Linux with various Qt5 versions (this is not a new phenomenon for me). ADDITIONAL INFORMATION Using `patchelf --remove-needed` to remove the spurious dependency on libpoppler.133.so fixes the problem. After rebuilding I can still remove the dependency on libpoppler.136.so without breaking functionality. I tried modifying the Kile and Tellico build systems to they only link to libpoppler-qt5.so and this breaks neither the build nor the functionality of the applications. I long had comments in my build scripts for some poppler dependents ago that rebuilding isn't required after a Poppler upgrade because the code only links to the stable libpoppler-qt5 library. Submitting this as a wishlist item because the FindPoppler module was introduced with this "feature" and dropping the automatic dependency may require some work for applications that do depend on Poppler's main library. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #271 from RJVB --- (In reply to Erec from comment #270) > Either roll a klocale or something that allows a user to select > their own date time settings or honor a custom locale. I think it must be clear to everyone by now that this is just not going to happen? This has become comparable to the breakage of (properly functioning of) KDE applications on Macintosh after the 4->5 transition where the old `KStandardDirs` (or some such name) was integrated as `QStandardPaths` in Qt5 but imposed "native" locations on Macintosh (and MS Windows). Qt refused to consider any way to make them compatible with XDG locations, and KDE never bothered to update the build system to use non-XDG locations on "non-XDG platforms". Qt's argument there was "we have to respect the Apple and Microsoft app store rules"; that's probably moot for platforms that can run full KDE desktops so it might be possible to pay Qt to fix the bug. Or someone can implement the necessary changes and try to jump through the loops of getting it accepted via Gerrit. In the meantime there's always the option to find another DE that works acceptably and figure out how to use KWin as the window manager (or compositor under Wayland). Exactly what I'm doing on this (older) system that still has KDE Plasma4 installed. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]
https://bugs.kde.org/show_bug.cgi?id=379669 --- Comment #51 from RJVB --- I too only seem to be getting this crash only sporadically nowadays, and AFAICT there's (almost) always a prematurely unloaded language plugin involved. But I'm pretty certain it does not only occur after working with a duchain (or whatever) cache left corrupted by a crash. In fact, the last case I had was after that entire cache had been discarded because created by a previous KDevelop version. Then again, I still use my own patch that removes the most obvious assumptions that can lead to nullptr dereference or dead loops as above, AND I install a timer that raises (IIRC) a SIGHUP after it expires (60s). -- You are receiving this mail because: You are watching all bug changes.
[Phonon] [Bug 486210] New: Missing future-proofing "fix" for clang >= 16
https://bugs.kde.org/show_bug.cgi?id=486210 Bug ID: 486210 Summary: Missing future-proofing "fix" for clang >= 16 Classification: Frameworks and Libraries Product: Phonon Version: unspecified Platform: Compiled Sources OS: All Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: rjvber...@gmail.com CC: myr...@kde.org, romain.per...@gmail.com, sit...@kde.org Target Milestone: --- SUMMARY Commit #069d5a3eb81bcbc730e44c27a0d060a85cf9213d introduced a fix for the default `-Werror=enum-constexpr-conversion` flag clang-16 introduced. Somehow it was missed that the same fix is needed in `phonon/backendinterface.h`, enum `BackendInterface::Class` (currently line 176) STEPS TO REPRODUCE 1. Build phonon with clang >=16, or with GCC with the `-Wconversion` flag OBSERVED RESULT Clang-16+ will give errors and GCC warnings that can be traced back to the aforementioned class. EXPECTED RESULT No errors/warnings. SOFTWARE/OS VERSIONS Any new enough to run clang-16+ and at least phonon 4.11.1 and its dependencies. ADDITIONAL INFORMATION Both GCC (12.3.0) and clang (17.0.6) will generate exactly the same library with and without the fix (using `-Wno-error=enum-constexpr-conversion` for clang) (phonon 4.11.1 built in `gnu++11` mode). -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 274170] sftp kio slave does not support new openssh known_hosts key format
https://bugs.kde.org/show_bug.cgi?id=274170 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #21 from RJVB --- (In reply to Roland Pallai from comment #20) > As it turned out it was a problem with my known_hosts file: key type > `ed25519` was present but correct syntax is `ssh-ed25519` for this type. In that case you were lucky, as my `known_hosts` file only has `ssh-ed25519` entries, and I still get this error: ``` An ssh-ed25519 host key for this server was not found, but another type of key exists. An attacker might change the default server key to confuse your client into thinking the key does not exist. Please contact your system administrator. ``` Annoyingly `sftp` itself connects just fine using the same URI (with the required additional slash after the hostname). (And I'm feeling stupid; I moved the ed25519 files out of the ~/.ssh directory on both hosts but the corresponding entry keeps getting added right back to my known_hosts file.) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #260 from RJVB --- (In reply to Nate Graham from comment #259) > Is there such an option for GTK and/or other toolkits? How is that relevant if KDE already has a sync service that apparently does what I'm suggesting? I have no idea what parameter GTk (or Gnome) uses for this particular setting but I can guess that it's the same one KDE is currently setting without the expected effect in Qt-based applications. As far as I can oversee at this point, all that seems to be needed is to define an additional parameter that defines the behaviour for KDE/Qt applications; this would be the parameter controlled by the KCM. The KDE platform plugin would translate this to the actual parameter used in Qt's internals. That's assuming it gets the chance to do that early enough, of course, but I suppose there must also be a programmatic way to change these settings directly instead of via env. variables. The KCM can predefine certain mappings from Qt locale definitions to glib ones but since it's probably impossible to foresee every single combination users might require the KCM could provide an optional second locale configuration widget or screen for GTk/Gnome apps. The only drawback would be that this mechanism doesn't work when running KDE apps under a non-KDE desktop session. It could, if the user sets KDE_FULL_SESSION and KDE_SESSION_VERSION himself, but barring that the proposed mechanism shouldn't change anything for users who are in that situation. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #258 from RJVB --- (In reply to brenbarn from comment #257) > (In reply to Nate Graham from comment #253) > > "ALERT! Changing this only affects KDE apps! It will not affect the way > > dates are expressed in any non-KDE app such as Thunderbird, Firefox, Chrome, > > LibreOffice, and Blender" > > > > ...then I can 100% guarantee you that we would *still* get bug reports from > > confused users complaining that Thunderbird, Firefox, Chrome, LibreOffice, > To put it bluntly, so what? Just create a FAQ about it and close those bug Remind me why it is again that KDE's systemsettings KCM can't set something that only affects KDE apps and give the user the option to configure the known corresponding setting for non-Qt/KDE applications? KDE4 had something of the sort for the GTk(2) colour profile. I can see how that would appear impossible if both glib and ICU locales are set from the same environmental variable but every Qt-based application running under `KDE_FULL_SESSION=true` will normally load the platform theme plugin. Would it be too late to change the value of the corresponding env. variable(s) from there and get the intended behaviour? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 330356] Panel auto-hide stops working after using desktop for a while.
https://bugs.kde.org/show_bug.cgi?id=330356 --- Comment #42 from RJVB --- On Thursday January 05 2023 09:23:08 Filipe Azevedo wrote: >My issue is not that the panel remain visible as per say, but that a ghost of >it remain on the desktop, so clicking this ghost does nothing. >From what I can see the reject / close animation is not operating and ghost >appear. Are you using KWin and does the ghost disappear when you restart it (`kwin_x11 --replace` for X11 or kwin_wayland for Wayland; personally I add `--no-kactivities`). I had plenty of glitches of (parts of) windows or the desktop not being redrawn properly, which turned out to be related to compositing. That all went away when I selected the XRender rendering backend. I'm not certain what kind of compositing that does, but the few effects I like to see (including windows turning semitransparent when moving) are supported. As a bonus I seem to be getting less tearing when watching videos. R -- You are receiving this mail because: You are watching all bug changes.
[kwalletmanager] [Bug 141267] wallet password dialog should stay in front
https://bugs.kde.org/show_bug.cgi?id=141267 --- Comment #25 from RJVB --- Created attachment 153715 --> https://bugs.kde.org/attachment.cgi?id=153715&action=edit kwalletd "make foreground" patch (for 5.60.0) Ensures that the pw dialog always opens in front. -- You are receiving this mail because: You are watching all bug changes.
[kwalletmanager] [Bug 141267] wallet password dialog should stay in front
https://bugs.kde.org/show_bug.cgi?id=141267 --- Comment #24 from RJVB --- Password dialogs aren't FS modal on MSWin nor the Mac OS (except the ones unlocking the screensaver). I run self-built frameworks, patched for my convenience (convictions, etc). I'll attach the one I use to ensure kwalletd always pushes its pw dialog to the front. kwalletd doesn't run with RT priorities so occasionally it takes a while to respond on a swamped system. Thus, it does happen that I enter something unforeseen into the dialog. Preventing that is going to be very hard, but it could be an option to require a modifier to accept the entered text via the Enter/Return key. That should reduce the chances of validating an invalid PW, while still not be as invasive as requiring the mouse to be used. Alternatively, disable the Enter/Return key but support using keyboard-based navigation to activate the accept button. -- You are receiving this mail because: You are watching all bug changes.
[kwalletmanager] [Bug 141267] wallet password dialog should stay in front
https://bugs.kde.org/show_bug.cgi?id=141267 --- Comment #21 from RJVB --- I can see how that could be an advantage to some people, but it'd be a no-go for me. If something wants me to enter a password 1) I want to be able to let that pend while I finish something else (could be watching a movie) 2) I want to be able to move the dialog, for instance to see who is requesting my password -- You are receiving this mail because: You are watching all bug changes.
[frameworks-purpose] [Bug 401600] Incompatible style (colours, fonts) in git/master (v1.1.90-182-gf338282)
https://bugs.kde.org/show_bug.cgi?id=401600 RJVB changed: What|Removed |Added Resolution|WAITINGFORINFO |UNMAINTAINED --- Comment #3 from RJVB --- I have no idea, I haven't updated my frameworks in ages, and KDevelop's patch review plugin has become pointless so even if the style errors haven't been fixed they're no longer an issue AFAIC. -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 337356] better integration: native file dialogs and unified title/toolbar
https://bugs.kde.org/show_bug.cgi?id=337356 RJVB changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |UNMAINTAINED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 413876] [KDevelop]: occasional hang on exit
https://bugs.kde.org/show_bug.cgi?id=413876 RJVB changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED Ever confirmed|0 |1 --- Comment #3 from RJVB --- KDevelop continues to hang on exit, occasionally. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 408725] KDevelop: impossible DUChain crash on exit?
https://bugs.kde.org/show_bug.cgi?id=408725 RJVB changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |UNMAINTAINED --- Comment #3 from RJVB --- I hate setting tickets to "resolved" status (instead of a much more neutral "closed") but this appears to have been a freak event. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 419831] KDevelop sometimes hangs on exit
https://bugs.kde.org/show_bug.cgi?id=419831 RJVB changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED --- Comment #3 from RJVB --- This still happens (and AFAIK there has been very little development on KDevelop since). My workaround has been to implement a timer that is started late in the cleanup procedure and which will send a SIGHUP to the process after 1 minute. This can't be a QTimer because the hang occurs after Qt's shut down code. I see this feature trigger with some regularity, esp. after longer and/or more complex sessions. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 412469] [KDevelop/Meson] : crash on re-importing a project repeatedly
https://bugs.kde.org/show_bug.cgi?id=412469 RJVB changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #3 from RJVB --- Haven't seen this one for a while. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kinit] [Bug 405227] kinit: kdeinit crashes with EXC_GUARD on Mac
https://bugs.kde.org/show_bug.cgi?id=405227 --- Comment #7 from RJVB --- Because my system doesn't run anything newer than Qt 5.9 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kinit] [Bug 405227] kinit: kdeinit crashes with EXC_GUARD on Mac
https://bugs.kde.org/show_bug.cgi?id=405227 --- Comment #5 from RJVB --- Besides being in the MacPorts camp HB still wouldn't allow me to run Qt 5.15 . -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kinit] [Bug 405227] kinit: kdeinit crashes with EXC_GUARD on Mac
https://bugs.kde.org/show_bug.cgi?id=405227 --- Comment #3 from RJVB --- That's going to be tricky because KInit is a tier-3 fw and I am still blocked on 5.60.0 on my Mac. I'll see if any relevant changes have been made to the code paths involved here, to what extent I can backport them and what difference that makes... -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #222 from RJVB --- Doesn't Qt have to be configured to use ICU, or is that only on non-linux/unix platforms (Mac included)? ICU uses hardcoded locale definitions? FWIW, the specialty library approach I mentioned could of course provide suitably amended forks of the ICU and/or libc/POSIX locale functions, which would override those in ICU and/or libc. Doing this carefully enough it should be possible to avoid risk of ODR/ABI issues - I suppose. Heck, the new behaviour could even be conditional on something like an env. variable that "deviant" users like us would have to set. I agree that ICU nor POSIX are likely to change their implementations without a sufficient body of evidence that an alternative implementation is backwards compatible in ABI, API *and* behavioural terms. With enough evidence of demand for an optional different behaviour, however, they could not reject a merge request as introducing unjustified code complexification... -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #219 from RJVB --- And what happened to the "there are no [more] KDE apps" (certainly not as opposed to "mere" Qt apps) I got whacked with only a few years back, when the KF5 frameworks were nothing more and nothing less than a set of extensions from which any Qt application could make a pick? > People want to set their personal combination of date format, time format, > first day of the week, etc., totally independent of any location in the > physical world or the jurisdiction of any country. I plead guilty. A reintroduction of the old KLocale class would have my vote, altering POSIX and/or libc not. If that means changing how the current locale functions work such an overhaul will probably take years before it starts to trickle down to the most adventurous distros and from there into Qt, GTk, KDE etc. I see more promise in developing the updated functionality in a dedicated library. -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 439639] kio-gdrive (built against qtkeychain!) should no longer use "Akonadi Resources for Google Services" and needs regular re-authentication with a private ID,secret pair
https://bugs.kde.org/show_bug.cgi?id=439639 --- Comment #7 from RJVB --- Not broken, just not updated. At least, that was the case in July 2021. I've had it working for some time since but it seems something may have changed yet again. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]
https://bugs.kde.org/show_bug.cgi?id=379669 --- Comment #47 from RJVB --- > The problem is that currentIndex is 0 and it never bails out. This is with > the very latest release. IIRC this is one of the things my patch addresses. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 451832] New: KDevelop crash on exit: in QHash::constBegin()
https://bugs.kde.org/show_bug.cgi?id=451832 Bug ID: 451832 Summary: KDevelop crash on exit: in QHash::constBegin() Product: kdevelop Version: unspecified Platform: Compiled Sources OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: rjvber...@gmail.com Target Milestone: --- Application: kdevelop (5.6.1-11-gf02541572b) (Compiled from sources) Qt Version: 5.9.8 Frameworks Version: 5.60.0 Operating System: Linux 4.14.23-ck1-mainline-core2-rjvb x86_64 Windowing system: X11 Distribution: Ubuntu 14.04.6 LTS -- Information about the crash: - What I was doing when the application crashed: I quit KDevelop. I have my personal patch that helps prevent most ?DUContext-related crashes on exit (presented on a different ticket) but I've seen this one a few times now. The reason for filing this as an issue is that I hope to get some feedback on how a crash could occur when accessing `m_referenceCounts.constBegin()`, i.e. `QHash::constBegin()`. The backtrace shows a this pointer that's not null in qhash.h so I assume that this is a case of a stale KDevelop::DUChainPrivate instance, for instance because it was freed while `doMoreCleanup()` was still executing? Shouldn't there be more extensive checking of DUChain::m_deleted in the DUChain class methods? Post-mortem debugging of this crashed instance (with lldb) suggests DUChain::m_deleted is false, but also doesn't give me a slightly different backtrace, claiming that the crash occured trying to lock `m_referenceCountsMutex` 2 lines earlier. The crash can be reproduced sometimes. -- Backtrace: Application: KDevelop (kdevelop), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f04771854c0 (LWP 24651))] Thread 18 (Thread 0x7f0418cfb700 (LWP 25963)): #0 0x7f046d541404 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f046e4ef93b in QWaitConditionPrivate::wait (this=0x7f0446fa8a80, time=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.9.8/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:143 #2 0x7f046e4ef6e5 in QWaitCondition::wait (this=0x7f04468c0868, mutex=0x7f0449101ee0, time=18446744073709551615) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.9.8/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:215 #3 0x7f047537a1fd in ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned_locked (this=0x7f0446fbe0e0, th=0x7f041ea14220) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.60.0/src/weaver.cpp:594 #4 ThreadWeaver::Weaver::blockThreadUntilJobsAreBeingAssigned (this=0x7f0446fbe0e0, th=0x7f041ea14220) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.60.0/src/weaver.cpp:581 #5 0x7f047537e3d4 in non-virtual thunk to ThreadWeaver::SuspendedState::applyForWork(ThreadWeaver::Thread*, bool) () at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.60.0/src/suspendedstate.cpp:56 #6 0x7f047537a0fe in ThreadWeaver::Weaver::applyForWork (this=, th=0xa7, wasBusy=false) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.60.0/src/weaver.cpp:568 #7 0x7f047537e003 in ThreadWeaver::WorkingHardState::applyForWork (this=0x7f04490e8520, th=0x7f041ea14220, wasBusy=) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.60.0/src/workinghardstate.cpp:73 #8 0x7f047537e0a0 in non-virtual thunk to ThreadWeaver::WorkingHardState::applyForWork(ThreadWeaver::Thread*, bool) () from /opt/local/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #9 0x7f047537a0fe in ThreadWeaver::Weaver::applyForWork (this=, th=0xa7, wasBusy=false) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.60.0/src/weaver.cpp:568 #10 0x7f047537e003 in ThreadWeaver::WorkingHardState::applyForWork (this=0x7f04490e8520, th=0x7f041ea14220, wasBusy=) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_KF5-Frameworks/kf5-threadweaver/work/threadweaver-5.60.0/src/workinghardstate.cpp:73 #11 0x7f047537e0a0 in non-virtual thunk to ThreadWeaver::WorkingHardState::applyForWork(ThreadWeaver::Thread*, bool) () from /opt/local/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #12 0x7f047537a0fe in ThreadWeaver::Weaver::applyForWork (this=, th=0xa7, wasBusy=true) at /opt/local/var/
[digikam] [Bug 450529] After a MacOS update all collections settings are lost and have to be remade.
https://bugs.kde.org/show_bug.cgi?id=450529 --- Comment #5 from RJVB --- Erm, if the digiKam version is too old to run on 12.x it probably shouldn't run at all, not simply lose all settings and then work again after resetting them. And if an update of digiKam itself causes this kind of factory reset, well, I'd call that a bug! One that I'd get very pissed about ;) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 450529] After a MacOS update all collections settings are lost and have to be remade.
https://bugs.kde.org/show_bug.cgi?id=450529 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #3 from RJVB --- (In reply to Maik Qualmann from comment #2) > The collection settings are in the database and are not changed during an > update. Unless the OP is talking about a major upgrade, done via a clean install? ;) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 353935] Kate's editor component in various apps shares the same settings.
https://bugs.kde.org/show_bug.cgi?id=353935 --- Comment #5 from RJVB --- (In reply to Christoph Cullmann from comment #4) > This got fixed long ago. Any idea when (roughly)? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 448092] Clicking G'mic reset button crashes Krita 5.0.2 on macOS 12.1
https://bugs.kde.org/show_bug.cgi?id=448092 --- Comment #21 from RJVB --- Given how I remember having experienced this issue but cannot find any trace of having found a fix, I'd say it's still there and just doesn't express itself (like any self-respecting Heisenbug ;) ) -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 412529] [xdg-desktop-portal-kde] : sporadic crash on exitting a KDE application.
https://bugs.kde.org/show_bug.cgi?id=412529 RJVB changed: What|Removed |Added Resolution|WAITINGFORINFO |MOVED Status|NEEDSINFO |RESOLVED --- Comment #2 from RJVB --- Well, I reported it alsmost 1.5 years ago ... O:-) Haven't been seeing it for a while though, at least not since updating the KDE portal plugin a while back. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]
https://bugs.kde.org/show_bug.cgi?id=379669 --- Comment #43 from RJVB --- I also am continuing to get hangs on exit, but a while back I implemented a failsafe, a simple timer that raises a SIGHUP if the application doesn't exit normally within 1 minute after starting the final cleanup. Nowadays that is safer than it ever was (with the rest of my patch), as far as I can tell the application is really waiting to exit when the timer fires. NB: not a Qt timer of course, those wouldn't work anymore. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 448092] Clicking G'mic reset button crashes Krita 5.0.2 on macOS 12.1
https://bugs.kde.org/show_bug.cgi?id=448092 --- Comment #14 from RJVB --- Is it possible that not all debug information is included in the app bundle? This ticket has been ringing a bell for me, I seem to recall getting a crash under similar conditions long ago, on my Intel Mac. Sadly (or maybe not so much :)) that's all I can remember. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 372638] "the file was created by another program"
https://bugs.kde.org/show_bug.cgi?id=372638 --- Comment #6 from RJVB --- Ah, the diplomatic approach ... and now we wait for someone to complain that s/he doesn't know what a disk is? ;) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 375548] context menu not opened every other click (Mac)
https://bugs.kde.org/show_bug.cgi?id=375548 --- Comment #3 from RJVB --- Sorry, no idea, I'm stuck at 5.60.0 for now. That version does still have issues with the context menu in KTextEditor views, especially in KDevelop. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 448092] Clicking G'mic reset button crashes Krita 5.0.2 on macOS 12.1
https://bugs.kde.org/show_bug.cgi?id=448092 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #5 from RJVB --- (In reply to Tiar from comment #1) > Hi, we can't really help without a crash log. On MacOS, there is this > problem that you need to start Krita in a special way before you get a crash > log, so if you can't repeat the crash, we won't really be able to help. DrKonqi works just fine on Mac, and could easily be embedded in the app bundle. The Mac's OS also has its own crash reporter that can be activated to get a post-mortem backtrace which can then be copied to a report on here. Running an application under the debugger will cause certain bugs not to express themselves (the infamous Heisenbugs ;)). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 413025] Dolphin: titlebar close button and Alt-F4 disabled
https://bugs.kde.org/show_bug.cgi?id=413025 RJVB changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from RJVB --- I don't use Dolphin a lot, even less so on MSWin but I'm pretty certain that I haven't been bothered by this anymore since a while. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #203 from RJVB --- Since blaming all of this on Qt is the default: you can actually hire them to implement or change something in Qt. Personally I think that the fact that KDE is built on Qt doesn't change the fact that Qt =/= KDE, and that KDE would do well to keep thin wrappers for most if not all of its classes that were/are merged into Qt or (will be) replaced by an appropriate Qt class. The present issue is annoying, but not to the same extent as the equally old QStandardPaths issue on MSWin and Mac, which could also have been avoided much more easily if the old KStandardSomething had been kept around to tweak! -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 340982] No way to change just the date format but not its actual translated text
https://bugs.kde.org/show_bug.cgi?id=340982 --- Comment #187 from RJVB --- (In reply to Nate Graham from comment #182) > To my knowledge, fixing this requires one of the following: > 1. Change the Qt locale system to support the feature > 2. Abandon the-in Qt locale system for this and implement a completely > custom system, like the KLocale system we had in the KDE 4 days but moved > away from in favor of QLocale > > Either one would be a huge amount of work. Isn't this exactly where OOC should make things straightforward if not easy? Just how much work would it be to clone (inherit) QLocale, merge/port the required functionality from KLocale (which I presume is or was in kdelibs4support at some point) and then (once properly debugged) do a search/replace on all the code in the frameworks, plasma and applications repositories to use the new class instead of QLocale? The amount of change could be huge, but maybe even that would be less than one might think if code using QLocale always imports qlocal.h . In that case, only that header has to be replaced with the new header, and the appropriate `using` expression. [OT] WHT happened to BKO? All of a sudden it looks as if designed for someone with a visuomotor handicap and a huge screen?! [/OT] -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382013] Crash during or after adding a new remote collection
https://bugs.kde.org/show_bug.cgi?id=382013 RJVB changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |WORKSFORME --- Comment #12 from RJVB --- I haven't seen this happen for a while now. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 446721] New: Figuring out "The file or folder \"\" does not exist" popup
https://bugs.kde.org/show_bug.cgi?id=446721
Bug ID: 446721
Summary: Figuring out "The file or folder \"\" does not exist"
popup
Product: frameworks-kio
Version: 5.60.0
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: task
Priority: NOR
Component: Open/save dialogs
Assignee: kio-bugs-n...@kde.org
Reporter: rjvber...@gmail.com
CC: kdelibs-b...@kde.org
Target Milestone: ---
SUMMARY
I'm running a utility against 5.60.0 on a machine where I'm blocked on that KF5
version. Everything works fine, but I'm getting a spurious error popup telling
me that "File or folder \"\" does not exist" whenever a custom save dialog is
opened.
I know this is probably considered an ancient version, so I'd just like to get
some suggestions helping me find the source of the problem, i.e. where the code
tries to access a file without name. Or a link to the KIO ticket where this
issue was fixed, if this is indeed a known problem in earlier KIO version(s).
I've tried setting a breakpoint on SlaveBase::error() which seemed like it
should be the place where the corresponding error code is set, but that never
got triggered.
As far as I have been able to determine:
STEPS TO REPRODUCE
1. Open the file save dialog with
```
FileDialog::FileDialog(QDialog *parent, Qt::WindowFlags flags)
: QDialog(parent, flags)
, m_fileWidget(new KFileWidget(QUrl(QStringLiteral("kfiledialog:///foo")),
this))
{
setLayout(new QVBoxLayout);
layout()->addWidget(m_fileWidget);
```
OBSERVED RESULT
The aforementioned error message pops up; after clicking it away I get the
expected file dialog without any signs of trouble.
EXPECTED RESULT
No popup
KDE Frameworks Version: 5.60.0
Qt Version: 5.9.8
ADDITIONAL INFORMATION
I introduce the `kfiledialog:///` QUrl, the original code passed an empty QUrl
which seemed like it could be the source of the problem. It didn't make a
difference.
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 361958] outline dropdown widget jumps to function implementation in another file
https://bugs.kde.org/show_bug.cgi?id=361958 --- Comment #9 from RJVB --- Sure, and if you run it on different machines you remove a few other potential possibilities for unexpected or at least unwanted interaction. IOW, it (partly) defeats the purpose of being able to open several projects in a single session, esp. if you have the habit like I do to "bundle" related projects in dedicated sessions. The Quick Open widget is aware of similarly named files in different projects; would it be so difficult to graft the underlying implementation onto the implementation of the outline widget? -- You are receiving this mail because: You are watching all bug changes.
[qca] [Bug 446319] [Proposal] legacy Qt5 branch
https://bugs.kde.org/show_bug.cgi?id=446319 --- Comment #2 from RJVB --- This doesn't just apply to "super old Qt" of course,but whatever :) -- You are receiving this mail because: You are watching all bug changes.
[qca] [Bug 446319] New: [Proposal] legacy Qt5 branch
https://bugs.kde.org/show_bug.cgi?id=446319 Bug ID: 446319 Summary: [Proposal] legacy Qt5 branch Product: qca Version: Git Platform: Other OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: dr...@land.ru Reporter: rjvber...@gmail.com CC: aa...@kde.org, br...@frogmouth.net, jus...@karneges.com Target Milestone: --- SUMMARY I am the maintainer of the MacPorts packaging (port) for QCA. We recently moved to using OpenSSL3 as the default in MacPorts, which required updating QCA. We have a policy of providing each port for the oldest OS version that can be supported with a reasonable effort, since Macs are valuable and long-lived computers. Contrary to Linux, older Macs are often locked in on older OS versions, and thus do not have access to more recent Qt5 versions (again, contrary to Linux). A similar situation exists for MS Windows, AFAIK. I thus had to spent a few hours introducing conditional code that falls back to the equivalent from QCA v2.2.1 when being built against a "too old" Qt5 version, thus making it possible again to build against as "ancient" a version as Qt 5.3.2 (thus allowing users locked in to Mac OS X 10.6.8 to use the latest crypto/security related features provided by QCA and OpenSSL3). I do not want to suggest to burden the release and development QCA versions with this conditional code, but I think the interest is high enough to consider adding a legacy branch for my patched code or simply to include the patchfile in whatever way (directory) KDE would provide such a file. A priori that branch or patchfile would be updated at every QCA release (by me, presumably). The patchfile in question is hosted on github and could also be downloaded from there if you prefer not to incorporate it in either version but instead mention its existence in a note in the README or INSTALL file. -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 442674] New: Extension side-effects on unsupported platforms
https://bugs.kde.org/show_bug.cgi?id=442674 Bug ID: 442674 Summary: Extension side-effects on unsupported platforms Product: plasma-browser-integration Version: unspecified Platform: Other OS: macOS Status: REPORTED Severity: major Priority: NOR Component: Firefox Assignee: k...@privat.broulik.de Reporter: rjvber...@gmail.com Target Milestone: --- SUMMARY Certain browsers, Firefox and Waterfox included have an option to sync installed extensions across hosts and platforms. One an thus end up with the Plasma Integration extension installed on, say, Macintosh. STEPS TO REPRODUCE 1. Launch the browser (Firefox or Waterfox, possibly any other supported browser) on Mac *from a terminal* 2. Install the extension (directly or indirectly by installing it on a Linux host where the browser syncs with the Mac in question) 3. Play a video (e.g. on YouTube) OBSERVED RESULT The terminal fills with ``` JavaScript error: moz-extension://2651658f-3b08-9242-8969-bbac66dafd06/extension-utils.js, line 0: Error: can't access property "postMessage", port is undefined JavaScript error: moz-extension://2651658f-3b08-9242-8969-bbac66dafd06/extension-utils.js, line 0: Error: can't access property "postMessage", port is undefined JavaScript error: moz-extension://2651658f-3b08-9242-8969-bbac66dafd06/extension-utils.js, line 0: Error: can't access property "postMessage", port is undefined ``` It seems 1 such line is printed for every frame in the video. EXPECTED RESULT No such pollution, which must have a performance impact on video playback SOFTWARE/OS VERSIONS macOS: 10.9.5 ADDITIONAL INFORMATION I have hardware acceleration disabled in my browser (Waterfox) on Mac but don't think that changes anything for this issue. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 403913] Bad default look in Dolphin/macOS (Dark Mojave Theme)
https://bugs.kde.org/show_bug.cgi?id=403913 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #8 from RJVB --- Isn't there a wiki or something similar that lists the current "issues" on Mac, like for instance "sorry, following the system look automatically is not currently possible"? FWIW, it *must* be possible, but the app will need to be packaged with a custom-written platform theme plugin (akin to the plasma-integration plugin). I've written one that's a tailored version of plasma-integration but it's designed to make KDE apps behave like they do on other Unix workstations, just with defaults that are appropriate for Mac (fonts, in particular). It could easily be extended with hardcoded colour palettes that are appropriate for the various modes on the different Mac OS versions ... by someone with access to OS versions where this is relevant. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 440580] Language interface cannot be converted
https://bugs.kde.org/show_bug.cgi?id=440580 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #2 from RJVB --- They're probably embedded in the app bundle (not the binary ;) ) but it seems not unlikely that they runtime (the ki18n framework?) looks for them in a different place (at least that could be the issue if the framework uses QStandardPaths instead of Qt's own translation files mechanism). -- You are receiving this mail because: You are watching all bug changes.
[kid3] [Bug 440466] Dark Mode for Kid3 on MacOS
https://bugs.kde.org/show_bug.cgi?id=440466 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #2 from RJVB --- The alternative would be to use a platform theme plugin (aka integration plugin) like mine (github:RJVB/osx-integration) that will give the same control over style, colour palette, fonts etc. as also exists on other Unix platforms. OR, just add a palette (theme) switcher menu (I think digiKam has one) though you may need the integration plugin for full palette support (can't remember). Personally I just turn down my monitor's luminosity (using an extension for my external which doesn't have hardware buttons for that) and keep enough light in my study to prevent myself from falling asleep... -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 405556] Rename 'OS X'=>'macOS'
https://bugs.kde.org/show_bug.cgi?id=405556 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #3 from RJVB --- This is actually not entirely correct. Mac OS versions after the given date have the fugly (fugally FUGLY) new name, but all older versions are still called what they were called. IMHO it would have been more appropriate to put a more generically descriptive term, like indeed "Mac OS" or (better yet?), Darwin. (Darwin is the term with which the OS refers to itself and to the kernel. It is thus the equivalent to Linux.) PS: no idea why I only see this now... -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 439091] Not able to open
https://bugs.kde.org/show_bug.cgi?id=439091 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com Resolution|WORKSFORME |UPSTREAM --- Comment #5 from RJVB --- This is literally an upstream issue, IMHO. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 438201] app just won't open on macos 11
https://bugs.kde.org/show_bug.cgi?id=438201 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #11 from RJVB --- Proper Mac behaviour dictates that app bundles should be location-independent, and this isn't hard to achieve by using LaunchServices to launch helpers. At the very least, helper apps should go into /Applications/Utilities, IMVHO. -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 439639] kio-gdrive (built against qtkeychain!) should no longer use "Akonadi Resources for Google Services" and needs regular re-authentication with a private ID,secret pair
https://bugs.kde.org/show_bug.cgi?id=439639 --- Comment #4 from RJVB --- Also, kaccnt-providers-git/providers/google.provider.in has the following: ``` o/oauth2/auth?access_type=offline&approval_prompt=force o/oauth2/token http://localhost/oauth2callback ``` Shouldn't libkgapi be updated to include the access_type and approval_prompt query items in its authentication request? -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 439639] kio-gdrive (built against qtkeychain!) should no longer use "Akonadi Resources for Google Services" and needs regular re-authentication with a private ID,secret pair
https://bugs.kde.org/show_bug.cgi?id=439639 RJVB changed: What|Removed |Added Summary|kio-gdrive (built against |kio-gdrive (built against |qtkeychain!) not allowed to |qtkeychain!) should no |connect via "Akonadi|longer use "Akonadi |Resources for Google|Resources for Google |Services" and needs regular |Services" and needs regular |re-authentication with a|re-authentication with a |private ID,secret pair |private ID,secret pair --- Comment #3 from RJVB --- So Turns out that keychainaccountmanager.cpp wasn't updated to use the proper Google credentials for KDE! -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 439639] kio-gdrive (built against qtkeychain!) not allowed to connect via "Akonadi Resources for Google Services" and needs regular re-authentication with a private ID,secret pair
https://bugs.kde.org/show_bug.cgi?id=439639 --- Comment #2 from RJVB --- Restarting kdeinit5 from a terminal gives me some useful output (finally). I'm seeing org.kde.kgapi: Unauthorized. Access token has expired or is invalid. but also kf5.kio.core: error() called twice! Please fix the "kio_gdrive" KIO slave kf5.kio.core: UDSEntry for '.' not found, creating a default one. Please fix the "kio_gdrive" KIO slave -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 439639] kio-gdrive (built against qtkeychain!) not allowed to connect via "Akonadi Resources for Google Services" and needs regular re-authentication with a private ID,secret pair
https://bugs.kde.org/show_bug.cgi?id=439639 --- Comment #1 from RJVB --- Actually, it would seem that I need to re-authenticate each time the kwallet has been closed. Does that mean some crucial information is not being stored there?! -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 439639] New: kio-gdrive (built against qtkeychain!) not allowed to connect via "Akonadi Resources for Google Services" and needs regular re-authentication with a private ID,secret pa
https://bugs.kde.org/show_bug.cgi?id=439639 Bug ID: 439639 Summary: kio-gdrive (built against qtkeychain!) not allowed to connect via "Akonadi Resources for Google Services" and needs regular re-authentication with a private ID,secret pair Product: kio-gdrive Version: unspecified Platform: Compiled Sources OS: All Status: REPORTED Severity: critical Priority: NOR Component: general Assignee: elvis.angelac...@kde.org Reporter: rjvber...@gmail.com Target Milestone: --- Created attachment 139947 --> https://bugs.kde.org/attachment.cgi?id=139947&action=edit resource forbidden error in "drives-example" SUMMARY I am no longer able to access my GDrive via kio-gdrive and libkgapi using the built-in credentials (client ID 554041944266). When I go through kio-gdrive and try to add a new account, I'm taken to the "App blocked" page (using qtkeychain, but even with libkgapi 20.11.80 which already opens the auth page in my webbrowser). STEPS TO REPRODUCE 1. Build kio-gdrive against qtkeychain, install (and libkgapi 20.11.80 or *presumably* newer) 2. run `dolphin gdrive:` 3. click "New account" 4. Find the auth. page in your browser, pick an account or authenticate to give access to "Akonadi Resources for Google Services" OBSERVED RESULT "This app is blocked This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access." EXPECTED RESULT The next step in the auth. process I CAN get beyond that step using my own Google Cloud client ID,secret pair to a project in which I configured Google Drive API access. Afterwards, I can quit dolphin and restart it again and still have direct access to my Google Drive, but when I try again some time later I have to jump through the authentication again, pretending to create a new account. ADDITIONAL INFORMATION Using the drives-example test from libkgapi's examples I do get past the authentication, but the app window shows no content. Clicking "Get Drive List" then gives me the attached "resource forbidden" message that suggests that the Google Drive APIs haven't been configured or sanctioned yet. It also suggests a subtle difference in the authentication procedures used by kio-gdrive's keychainaccountmanage. -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 438981] kio-gdrive no longer works
https://bugs.kde.org/show_bug.cgi?id=438981 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #3 from RJVB --- I think you'll need to restart kdeinit5. > pkill -f kdeinit5 should be enough, but after an update that involves the KF5 frameworks and/or Plasma components, or just a kioslave it is not a bad idea to log off and back in again (or even reboot the machine). Did you do that? I'm more curious to know if you were still allowed access to your gdrive before the update!? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 419967] Updating KIO libs requires executing kdeinit5 to pick up the new libs
https://bugs.kde.org/show_bug.cgi?id=419967 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #7 from RJVB --- Something already restarts kdeinit5 after a crash (or abort in a kioslave). Or is that just This isn't just a KIO problem: it's bound to happen to any project that installs a kioslave. The strange this is that I've just been tinkering with kio-gdrive, and I haven't had to kill any kdeinit5 instance myself in order for it to use the updated gdrive.so . I wrote that off to the fact that no `gdrive.so [kdeinit5]` process remained after quitting Dolphin, but that can't be it if the parent kdeinit5 process keeps the kioslave cached... BTW, hadn't the idea been dropped to use a single, central "speed loader" that keeps all shared libraries it has even seen loaded to speed up subsequent launches? I seem to recall a discussion that this wasn't relevant anymore with the modern fast storage? -- You are receiving this mail because: You are watching all bug changes.
[libkdcraw] [Bug 439611] New: libkdcraw should propagate the ${LIBS} from libraw.pc
https://bugs.kde.org/show_bug.cgi?id=439611
Bug ID: 439611
Summary: libkdcraw should propagate the ${LIBS} from libraw.pc
Product: libkdcraw
Version: unspecified
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: critical
Priority: NOR
Component: General
Assignee: imaging-bugs-n...@kde.org
Reporter: rjvber...@gmail.com
Target Milestone: ---
SUMMARY
libraw can be built with OpenMP support, which, at least when building with
Clang, adds a dependency to a corresponding shared library. As a result, my
libraw.pc (for v0.20.2) has
```
Libs: -L${libdir} -lraw -fopenmp
```
STEPS TO REPRODUCE
1. build and install libraw with OpenMP support (`configure [...]
--enable-openmp [...]`)
2. build and install libkdcraw
3. try to build a dependent like gwenview
OBSERVED RESULT
The build will fail with the error message that libraw.so.20 has an undefined
reference to a range of __kmpc_XXX symbols.
EXPECTED RESULT
No build failure. Adding `-fopenmp` to the linker flags fixes the issue.
ADDITIONAL INFORMATION
I've observed this on Linux but I presume it will be the case on any Unix
version where private dependencies of shared libraries aren't pulled in
automatically and/or where libraw itself isn't linked to the openmp library (=
all Unices except Darwin?).
--
You are receiving this mail because:
You are watching all bug changes.
[kio-extras] [Bug 439492] TextCreator::create() crashes in QSyntaxHighligher.
https://bugs.kde.org/show_bug.cgi?id=439492 RJVB changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |UPSTREAM --- Comment #2 from RJVB --- (You could have "unprivatised" the argument-less ctor or added a default null value in the fix ;) ) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-syntax-highlighting] [Bug 439491] SyntaxHighlighter::SyntaxHighlighter(QObject*) should NOT use a default nullptr
https://bugs.kde.org/show_bug.cgi?id=439491 RJVB changed: What|Removed |Added Resolution|WORKSFORME |UPSTREAM --- Comment #3 from RJVB --- my bad, I must have looked at the sources of an older Qt version (and didn't see any change in Qt's API documentation). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-syntax-highlighting] [Bug 439491] SyntaxHighlighter::SyntaxHighlighter(QObject*) should NOT use a default nullptr
https://bugs.kde.org/show_bug.cgi?id=439491 RJVB changed: What|Removed |Added Blocks||439492 See Also||https://bugs.kde.org/show_b ||ug.cgi?id=439492 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=439492 [Bug 439492] TextCreator::create() crashes in QSyntaxHighligher. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 439492] New: TextCreator::create() crashes in QSyntaxHighligher.
https://bugs.kde.org/show_bug.cgi?id=439492 Bug ID: 439492 Summary: TextCreator::create() crashes in QSyntaxHighligher. Product: kio-extras Version: unspecified Platform: Compiled Sources OS: All Status: REPORTED Severity: crash Priority: NOR Component: Thumbnails and previews Assignee: plasma-b...@kde.org Reporter: rjvber...@gmail.com Depends on: 439491 Target Milestone: --- SUMMARY TextCreator::create() creates a locate instance using `KSyntaxHighlighting::SyntaxHighlighter syntaxHighlighter;` which leads to a nullptr dereference in `QSyntaxHighlighter::QSyntaxHighlighter(QObject*)`. STEPS TO REPRODUCE 1. Open a directory in Dolphin, activate hover-on previews 2. Hover the cursor over a .txt file OBSERVED RESULT kdeinit5 crashes because of the nullptr dereference. EXPECTED RESULT No crash. SOFTWARE/OS VERSIONS Happens on Mac & Linux; as far as I can tell this should happen with the current Qt5 release and the most recent versions of kio-extras and KSyntaxHighlighting. ADDITIONAL INFORMATION The function should call `KSyntaxHighlighting::SyntaxHighlighter syntaxHighlighter(&textDocument);` which makes the later call to `setDocument()` unnecessary. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=439491 [Bug 439491] SyntaxHighlighter::SyntaxHighlighter(QObject*) should NOT use a default nullptr -- You are receiving this mail because: You are watching all bug changes.
[frameworks-syntax-highlighting] [Bug 439491] New: SyntaxHighlighter::SyntaxHighlighter(QObject*) should NOT use a default nullptr
https://bugs.kde.org/show_bug.cgi?id=439491 Bug ID: 439491 Summary: SyntaxHighlighter::SyntaxHighlighter(QObject*) should NOT use a default nullptr Product: frameworks-syntax-highlighting Version: unspecified Platform: Compiled Sources OS: All Status: REPORTED Severity: crash Priority: NOR Component: framework Assignee: kwrite-bugs-n...@kde.org Reporter: rjvber...@gmail.com Target Milestone: --- SUMMARY SyntaxHighlighter::SyntaxHighlighter(QObject*) hands off its argument to QSyntaxHighlighter; this function does NOT check if the parent it receives that way is a valid pointer. Code should thus be obliged to pass a parent pointer explicitly - QSyntaxHighlighter does this too (no default value). STEPS TO REPRODUCE 1. Create a KSyntaxHighlighting instance by, for instance, `KSyntaxHighlighting::SyntaxHighlighter syntaxHighlighter;` OBSERVED RESULT A crash will result in QSyntaxHighlighter::QSyntaxHighligher(). 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.
[okular] [Bug 439216] [Okular] : Closing the Print Preview still/again causes a crash
https://bugs.kde.org/show_bug.cgi?id=439216 --- Comment #4 from RJVB --- Well, this is strange, I'm convinced that DrKonqi showed me a backtrace of the same bug, but I must have gotten confused. I am positive though that it didn't suggest bug 415340 - evidently I would not have filed another ticket if I had found that one. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 439216] [Okular] : Closing the Print Preview still/again causes a crash
https://bugs.kde.org/show_bug.cgi?id=439216 --- Comment #1 from RJVB --- And FWIW, PageView::capability() needs to check every one of the QActions in the d-ptr before accessing them, because aViewContinuous, aViewMode and aTrimMargins can all turn out to be a nullptr. Add a qDebug if you want to be able to avoid this from happening upstream, but please don't just "protect" the actual dereferencing with an assert. The user should NOT experience crashes if the developer(s) missed something and they shouldn't have to be the ones detecting such ommissions! -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 439216] New: [Okular] : Closing the Print Preview still/again causes a crash
https://bugs.kde.org/show_bug.cgi?id=439216 Bug ID: 439216 Summary: [Okular] : Closing the Print Preview still/again causes a crash Product: okular Version: unspecified Platform: Compiled Sources OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: rjvber...@gmail.com Target Milestone: --- Application: okular (1.9.70) (Compiled from sources) Qt Version: 5.9.8 Frameworks Version: 5.60.0 Operating System: Linux 4.14.23-ck1-mainline-core2-rjvb x86_64 Windowing system: X11 Distribution: Ubuntu 14.04.6 LTS -- Information about the crash: - What I was doing when the application crashed: I had checked the Print Preview and closed it by hitting Escape. The crash was immediate. This is the exact same crash as the Okular4 one in the linked report which I reported years ago and that was supposed to be fixed. Seeing that I didn't even hold off on reporting this until I had time to check if maybe it had been fixed in the current code. Whatever fix had been done back in the day, either it was removed or a different code path was added to triggering this nullptr dereference. Why not add a proper nullptr check at the problem location?! -- Backtrace: Application: Okular (okular), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7efc28f43840 (LWP 28083))] Thread 7 (Thread 0x7efbf5b79700 (LWP 31518)): #0 0x7efc21771404 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7efc23b7a93b in QWaitConditionPrivate::wait (this=0x2316a50, time=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.9.8/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:143 #2 0x7efc23b7a6e5 in QWaitCondition::wait (this=0x2316a38, mutex=0x2316a30, time=18446744073709551615) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.9.8/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:215 #3 0x7efc23b74d23 in QSemaphore::acquire (this=0x23168d0, n=1) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.9.8/qtbase/src/corelib/thread/qsemaphore.cpp:143 #4 0x7efbf4ee25d6 in GSRendererThread::run (this=0x23168c0) at /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-okular/kf5-okular-devel/work/okular-5/generators/spectre/rendererthread.cpp:50 #5 0x7efc23b79423 in QThreadPrivate::start (arg=0x23168c0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.9.8/qtbase/src/corelib/thread/qthread_unix.cpp:368 #6 0x7efc2176d184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x7efc22e9103d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 6 (Thread 0x7efc06ffd700 (LWP 28089)): #0 0x7efc21771404 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7efc0e68136b in util_queue_thread_func () from /opt/local/lib/dri/i965_dri.so #2 0x7efc0e681736 in impl_thrd_routine () from /opt/local/lib/dri/i965_dri.so #3 0x7efc2176d184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x7efc22e9103d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 5 (Thread 0x7efc077fe700 (LWP 28088)): #0 0x7efc21771404 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7efc0e68136b in util_queue_thread_func () from /opt/local/lib/dri/i965_dri.so #2 0x7efc0e681736 in impl_thrd_routine () from /opt/local/lib/dri/i965_dri.so #3 0x7efc2176d184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x7efc22e9103d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 4 (Thread 0x7efc07fff700 (LWP 28087)): #0 0x7efc21771404 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7efc0e68136b in util_queue_thread_func () from /opt/local/lib/dri/i965_dri.so #2 0x7efc0e681736 in impl_thrd_routine () from /opt/local/lib/dri/i965_dri.so #3 0x7efc2176d184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x7efc22e9103d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 3 (Thread 0x7efc0cf12700 (LWP 28086)): #0 0x7efc21771404 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7efc0e68136b in util_queue_thread_func () from /opt/local/lib/dri/i965_dri.so #2 0x7efc0e681736 in impl_thrd_routine () from /opt/local/lib/dri/i965_dri.so #3 0x7efc2176d184 in start_thread () from /lib/x86_64-linux-gnu/lib
[digikam] [Bug 430949] digiKam-7.2.0-beta2 (macOS (DMG)) breaks existing local MySQL/MariaDB instances on upgrade
https://bugs.kde.org/show_bug.cgi?id=430949 RJVB changed: What|Removed |Added CC||rjvber...@gmail.com --- Comment #53 from RJVB --- FWIW, the fix for this assumes (hardcodes) a fixed install location (/Applications/digiKam.org/digikam.app) and breaks my MacPorts build, and indeed any other build that aims to be as "Unixy" as possible (i.e. not making a self-sufficient relocatable app bundle but one that uses libraries and helpers from shared location such as /opt/local). The former issue can be fixed with QCoreApplication::applicationFilePath() and QDir::cdUp() (twice), the latter can only be fixed by patching. Might I suggest that instead of adding the mysql --basedir argument `#ifdef Q_OS_MACOS`, you define a token for your own dist builds and check for that here? Fixing this particular regression (for me) was easy but how many remain hidden? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ki18n] [Bug 434430] New: useless warning messages about markup
https://bugs.kde.org/show_bug.cgi?id=434430 Bug ID: 434430 Summary: useless warning messages about markup Product: frameworks-ki18n Version: unspecified Platform: Compiled Sources OS: All Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: caslav.i...@gmx.net Reporter: rjvber...@gmail.com CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY Most warnings generated in the kuitmarkup.cpp file should IMHO be debug messages instead. I think that users should be able to have Qt warnings activated without too much pollution of irrelevant messages. The fact that someone's code uses an unknown markup tag that doesn't otherwise lead to a functional regression is irrelevant for anyone except the developer of that code. For example, the patch proposed in https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/45 causes 2 of such messages to be printed each time a tooltip is triggered. The tooltip actually appears to be formated just fine, so the long and hard-to-read messages only help to make other more important messages harder to notice. (I happen to know they also haven't helped the author of the patch to figure out what he's doing wrong...) I think that all qCWarning() output that is followed by an early or empty return should be qCDebug() output instead. -- You are receiving this mail because: You are watching all bug changes.
[kimap] [Bug 352883] remote changes to message read/important state on gmail imap account aren't synced
https://bugs.kde.org/show_bug.cgi?id=352883 RJVB changed: What|Removed |Added Resolution|--- |UNMAINTAINED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 349475] liboxygen-gtk engine gets wrong extension on OS X
https://bugs.kde.org/show_bug.cgi?id=349475 RJVB changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 356585] adding menu as submenu (too?) leads to repeated "InsertNative: item is already in menu" errors
https://bugs.kde.org/show_bug.cgi?id=356585 RJVB changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kdeclarative] [Bug 342962] kdeclarative plugins should be built as a bundle plugin and not a shared library
https://bugs.kde.org/show_bug.cgi?id=342962 RJVB changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |UNMAINTAINED -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 355452] menubar background colour does not correspond to the preview shown in the attached preview window
https://bugs.kde.org/show_bug.cgi?id=355452 RJVB changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |UNMAINTAINED -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 355432] QXcbWindow: Unhandled client message: "_QTCURVE_ACTIVE_WINDOW_"
https://bugs.kde.org/show_bug.cgi?id=355432 RJVB changed: What|Removed |Added Resolution|--- |UNMAINTAINED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 343778] GTK Font settings not respected
https://bugs.kde.org/show_bug.cgi?id=343778 RJVB changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[QtCurve] [Bug 347112] GTk2: "icons in buttons" setting is not respected
https://bugs.kde.org/show_bug.cgi?id=347112 RJVB changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 371489] Breeze style elements are looking too big
https://bugs.kde.org/show_bug.cgi?id=371489 --- Comment #16 from RJVB --- And I said create two ADDITIONAL styles, one smaller, one larger, so that all 3 camps (assuming there are indeed 3) have a choice. But it should be possible to make the padding (as well as the size of elements) scalable with a single slider, even if inside there are multiple mappings being made from that single scale value. Or maybe it'd be better to have 2 sliders, one for the padding, one for element size. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 371489] Breeze style elements are looking too big
https://bugs.kde.org/show_bug.cgi?id=371489 --- Comment #14 from RJVB --- (In reply to Nate Graham from comment #12) > I don't think this is an actionable issue, sorry. :( There is a vocal > contingent of users on both sides of this issue: right now, we get bug > reports and complaints from people who think everything is too big, as well > as from people who think everything is too small! So we don't really have > any freedom of movement here without annoying one group even more. Oh yes you have. I'd say there are at least 2 possibilities: - create additional breeze-xs (lull?) and breeze-xl (gale?) styles. My guess is that you can generate them from the same code with appropriately chosen constant scale factors that are applied at compile time. - make the airyness a user-controllable parameter so that users can fine-tune this aspect themselves. It stands to reason that monitor size, resolution, visual acuity and last but not least personal taste are all at play here, meaning that the members of both the "too large" and the "too small" contingents probably disagree over just how much things are too large or small. The latter solution would thus be the preferable one - and undoutedly also the most interesting (challenging) to get right. > Accordingly, I think we have to stay with how things are right now, and be > content with small tweaks on a case-by-case basis, as needed. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #45 from RJVB --- (In reply to Wolfgang Bauer from comment #44) > I do use QtWebKit with konqueror, and opening large OBS logs (which are just > text files) do take a while. TBH, Konqueror is such a multipurpose tool that I have no idea what backend/engine/kpart it uses for rendering pure text. Actually, when I open /var/log/syslog I get a view that suggest very strongly that the Kate text editor kpart is used. That is, if I open the file from within Konqueror. If I try to start konqueror with a file it will start but open the file in the system handler (Kate for text files), very funny. > That's what I meant with a "large rewrite" amongst other things. > Please note that I'm not a kmail developer though. Neither am I, and you're right in assuming it could be more work than you'd expect. > I'm not sure though, nor if it frees the resources when you switch to a > different mail (I think it does). In my experience that doesn't always mean the resources are available immediately, for RAM at least. But I digress... -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #43 from RJVB --- (In reply to Wolfgang Bauer from comment #42) > Have you tried in Chromium though? (which is what QtWebEngine is based upon) Current versions of Firefox tend to consume more memory than Chromium - in fact,I understand that the Firefox Quantum engine uses bits and pieces from all 3 open source web engines and picks the fastest one. > TBH, I think even QtWebKit would struggle with these large mails That would be simple to test in konqueror with the webkit backend, or Otter-Browser, and the rebooted QtWebKit. Or in epiphany. 1 caveat emptor: we don't actually know what clever tricks the web email interface pulls. > Anyway, this is kind of a different problem than comment#35 (or comment#0). > I don't see how it could be fixed from the kmail side, except for not trying > to display mails larger than a certain size at all. (or maybe just display > it as plain text instead then, but that probably means a large rewrite of > the code, and I'm not sure it's possible at all) - Don't dump the entire message into the rendering widget but use a paged approach - wrapper code can be written that connects to different backends. If you don't want to support QtWebkit, fine, but there's also QTextBrowser which should be sufficient even for simple HTML emails (it's what Qt's assistant uses by default since whatever Qt version that obsoleted QtWebkit). I've done a compile-time version of such wrapper code for KDevelop's help browser (which supports both QWE and QWK). I think it should be possible at least to chose between backends as a startup option. Out of curiosity: does that humongous QWE process exit when you close the message view, or do you have to quit KMail to recuperate all that RAM? -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 387061] REGRESSION: Large messages don't display in the viewer pane (eg. New Tumbleweed snapshot 20171117 released!)
https://bugs.kde.org/show_bug.cgi?id=387061 --- Comment #39 from RJVB --- A pure text email of 35Mb is massive too, but eating around 4Gb of RAM for that isn't just massive. That's what you meant, right, not 4Mb for displaying just the part that fits in your window (which would seem reasonable)? 4Gb, that's about 120 times the size of the email. I knew KMail would become a powerkids' tool with the design decision to use a full-fledged-browser-in-a-widget (QtWebEngine) for rendering everything including pure text emails but I wasn't expecting this. Then again, I don't usually get this kind of long letters by email so I have no idea how any other MUA would handle them. If the account you got this email on has a web/browser interface it would be interesting to estimate the resources an actual browser (GChrome or Chromium) would use to display it, for comparison. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 393416] Can't import pictures on MacOS High Sierra from SD card or camera
https://bugs.kde.org/show_bug.cgi?id=393416 --- Comment #59 from RJVB --- I indeed did not implement any kind of event handling, if memory serves me well the backend just queries the current state. My argument was that there was little reason to implement event handling (or indeed support for many of the other things Solid does on Linux) because that is mostly interesting for the desktop shell and possibly "system utilities" that are tightly integrated with that shell. On Mac (and MSWin), there are a priori only KDE applications, and the consensus among the KDE team is that this is how it should be - they don't even approve of the idea to make the system-settings app available, some even object to providing DrKonqi. This suited me because I hardly know IOKit myself, and I didn't really see the added value to dive in and become an expert on it. I'm pretty certain I tested if SD cards were detected; IIRC they show up as any other volume does. FWIW, you must have noticed that IOKit doesn't use the same abstraction for disks and volumes; this is quite clear in the Dolphin sidebar. I can't remember the exact difference right now, but I do remember that there wasn't really a way around it, not if I wanted to support the different categories Solid supports. Digikam shouldn't have a need to be informed immediately and with minimal overhead when a device becomes available, I think. You should be able to work around the missing events by using "aboutToXX" signals to get current information about available devices for populating menus or lists. And possibly by setting a KDirWatch on album directories on removable devices (if memory serves me well you can set a watch on a non-existent directory and get a creation event when it is created). I guess I could take a look at how complicated it would be to add support for device events to the Mac backend. I'm handicapped here by the fact that my sole Mac still runs 10.9.5 which I don't really plan to upgrade enough to be able to run the Qt version that is required by the latest KF5 frameworks. I'm a bit tired of spending lots of time upgrading every few weeks. Maybe Solid still builds against Qt 5.9; if not I'd be developing for KF5 5.60 and someone else would need to incorporate it in git/master. I'm not in touch with the Solid team (if such a team exists). The bugtracker is managed by a separate team as far as I know, it would have been up to them to notice that there should be a libsolid-mac section. Re: iPhone: doesn't accessing those require a different library which probably has its own event hooks?! iDevices do not appear as disks/volumes on Mac, so my Solid backend does not have support for them. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 393416] Can't import pictures on MacOS High Sierra from SD card or camera
https://bugs.kde.org/show_bug.cgi?id=393416 --- Comment #55 from RJVB --- Hi Gilles, Better new year to you too (I'm calling it 2020bis for the time being...) ;) No, I haven't contined work on the Mac backend for Solid. I was under the impression that I mapped just about all the relevant information IOKit provides. Someone else is currently working on support for encrypted disks but I'd guess that that isn't really relevant for digiKam. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 430714] New: KDevelop: QML icon load failure in Welcome plugin messes up icon loading elsewhere
https://bugs.kde.org/show_bug.cgi?id=430714 Bug ID: 430714 Summary: KDevelop: QML icon load failure in Welcome plugin messes up icon loading elsewhere Product: kdevelop Version: git master Platform: Compiled Sources OS: macOS Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: rjvber...@gmail.com Target Milestone: --- SUMMARY Loading the Welcome plugin generates a warning message about an image not being found, and interferes with proper display of icons elsewhere, notably in the project explorer. STEPS TO REPRODUCE 0. Make certain to build Qt and KF5 such that icons are loaded normally 1. Load KDevelop from a terminal window, with the Welcome plugin enabled 2. Notice "qrc:///qml/area_code.qml:37:13: QML Image: Failed to get image from provider: image://icon/kdevelop" OBSERVED RESULT Icons are missing in the project explorer (but not all icons). EXPECTED RESULT Icons shown as they are when the Welcome plugin isn't loaded. SOFTWARE/OS VERSIONS macOS: 10.9.5 KDE Frameworks Version: 5.60.0 Qt Version: 5.9.8 ADDITIONAL INFORMATION Maybe sc-apps-kdevelop.svg can be included in the welcomepage.qrc resource, and then referenced from area_code.qml as it should? I've dealt with the missing icons since a few major 5.x releases, but made the link to the warning above and the Welcome plugin only recently. -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 429962] KDevelop/quickopen : QMetaMethod::invoke prints error message
https://bugs.kde.org/show_bug.cgi?id=429962 --- Comment #2 from RJVB --- Any idea why adding a slot in the ExpandingTree class didn't work? I didn't expect that you'd be doing some additional code maintenance, or I would have suggested that it would be nice if one could close the drop-down menu by clicking a 2nd click in the outline line edit widget (like with regular menus). -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 429962] New: KDevelop/quickopen : QMetaMethod::invoke prints error message
https://bugs.kde.org/show_bug.cgi?id=429962 Bug ID: 429962 Summary: KDevelop/quickopen : QMetaMethod::invoke prints error message Product: kdevplatform Version: git master Platform: Compiled Sources OS: All Status: REPORTED Severity: minor Priority: NOR Component: quickopen Assignee: kdevelop-bugs-n...@kde.org Reporter: rjvber...@gmail.com Target Milestone: --- SUMMARY Clicking in the "Outline" drop-down widget causes QMetaMethod::invoke to print an error on the calling terminal, apparently without any ill effects. STEPS TO REPRODUCE 1. Open a project and at least 1 source file in KDevelop 2. Click in the Outline widget to get the outline of the code in the file OBSERVED RESULT The terminal shows QMetaObject::invokeMethod: No such method ExpandingTree::scrollTo(const QModelIndex,QAbstractItemView::ScrollHint) and the outline opens (presumably in that order); the widget is as functinonal as I'd expect it to be. The responsible queued invocation of scrollTo() in quickopenplugin.cpp:872 is 12 years old (commit 6ee7126a) and apparently already didn't do the trick back then. EXPECTED RESULT No error messages, and if possible a widget that does show the current function. SOFTWARE/OS VERSIONS Qt Version: 5.9.8 ADDITIONAL INFORMATION After adding an explicit ExpandingTree::scrollTo(const QModelIndex, QAbstractItemView::ScrollHint) (yes, NOT a reference for the 1st argument, to add the supposedly missing method) the error becomes: QMetaMethod::invoke: Unable to handle unregistered datatype 'QAbstractItemView::ScrollHint' I have no idea what to do about that. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 429815] #8831937ffe4 broke compatiblity with older Qt5 versions
https://bugs.kde.org/show_bug.cgi?id=429815 RJVB changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED Latest Commit||https://invent.kde.org/kdev ||elop/kdevelop/commit/87979a ||cc1a6c9f401d3c19ab516fa38b1 ||d053233 --- Comment #6 from RJVB --- Git commit 87979acc1a6c9f401d3c19ab516fa38b1d053233 by René Bertin. Committed on 30/11/2020 at 18:54. Pushed by rjvbb into branch '5.6'. Restore compatibility with Qt < 5.10 M +1-1plugins/gdb/debugsession.cpp https://invent.kde.org/kdevelop/kdevelop/commit/87979acc1a6c9f401d3c19ab516fa38b1d053233 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 429815] #8831937ffe4 broke compatiblity with older Qt5 versions
https://bugs.kde.org/show_bug.cgi?id=429815 --- Comment #5 from RJVB --- Apologies, my bad. The failure is in DebugSession::handleVersion() in plugins/gdb/debugsession.cpp (line 288 to be precise). -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 429815] #8831937ffe4 broke compatiblity with older Qt5 versions
https://bugs.kde.org/show_bug.cgi?id=429815 --- Comment #3 from RJVB --- > it's a bit of a mystery to me why the code builds as is. Got that: newer versions of QVersionNumber::fromString() can take a QStringView, which has a ctor taking a QStringRef. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 429815] #8831937ffe4 broke compatiblity with older Qt5 versions
https://bugs.kde.org/show_bug.cgi?id=429815 --- Comment #2 from RJVB --- I don't think we have to be concerned with the potential additional overhead of creating a copy of the string as `toString()` appears to do? I don't see anything about a new cast operator in the Qt 5.15 documentation for QStringRef nor any new overloads of QVersionNumber::fromString() that would be used here so it's a bit of a mystery to me why the code builds as is. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 429815] #8831937ffe4 broke compatiblity with older Qt5 versions
https://bugs.kde.org/show_bug.cgi?id=429815 RJVB changed: What|Removed |Added Version|unspecified |git master -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 429815] New: #8831937ffe4 broke compatiblity with older Qt5 versions
https://bugs.kde.org/show_bug.cgi?id=429815 Bug ID: 429815 Summary: #8831937ffe4 broke compatiblity with older Qt5 versions Product: kdevelop Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: CPP Debugger Assignee: kdevelop-bugs-n...@kde.org Reporter: rjvber...@gmail.com CC: niko.s...@gmail.com Target Milestone: --- The commit mentioned in the title assumes that a QStringRef instance can be cast to a const Qstring automatically. I don't know what Qt version introduced that compatibility but it's not in Qt 5.9 . Adding an explicit .toString() fixes the build failure. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 374722] [Mac] kate crash on exit after using the "Show Active" action
https://bugs.kde.org/show_bug.cgi?id=374722 RJVB changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 370257] [OS X] weird window "dissociation" glitch
https://bugs.kde.org/show_bug.cgi?id=370257 RJVB changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #4 from RJVB --- I don't understand how I could ever manage to move the window before the document opened. At least in the current version of the app and frameworks there is no more delay. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 369207] Mode & Highlighting menus remain empty on Mac OS X
https://bugs.kde.org/show_bug.cgi?id=369207 RJVB changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |MOVED -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 381544] kcm_keyboard needs exceptions to build
https://bugs.kde.org/show_bug.cgi?id=381544 RJVB changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #2 from RJVB --- I no longer have that compiler nor that Boost version, but I can confirm that the combination clang 5.0.2 + Boost 1.71.0 no longer requires C++ exceptions to be enabled. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 398750] [Konsole] text selection impossible when output is being generated
https://bugs.kde.org/show_bug.cgi?id=398750 RJVB changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |FIXED --- Comment #2 from RJVB --- I've been running #ac8799ba587e50cd68e4c676f990274c22e41280 for a while now, and can confirm that it appears the issue has been solved. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcoreaddons] [Bug 384866] KDirWatch::addDir should pump the eventloop (call QCoreApplication::processEvents())
https://bugs.kde.org/show_bug.cgi?id=384866 --- Comment #2 from RJVB --- I don't think it's a good idea to handle GUI events anywhere but on the main thread - on Mac at least. Unless you meant to call KDirWatch::addDir() on its own thread? This ticket is 2 years old. It's not impossible that I filed it before realising that Darwin, being a BSD variant, only has native support for watching directories for changes. I do remember that the 85s figure above comes from opening the GCC source tree in KDevelop, which will be default add every file and directory to its dirwatcher. I've worked around the issue by overhauling KDevelop's monitoring implementation to watch only directories (in a local patch but by now one more or less of those doesn't make a lot of difference anymore...) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 378523] Regular/Normal Fonts are saved with the styleName string appended to the config entry, preventing e.g. setBold(true) from working correctly
https://bugs.kde.org/show_bug.cgi?id=378523 --- Comment #78 from RJVB --- I should have seen the Phab PR above or at least the previous comment, but somehow didn't. Why only strip the Regular styleName? The property is redundant at best and I think that the synthetic font argument applies to other styles as well. As an example: I use a Semi-Bold typeface in many cases (including as GUI font) because the corresponding regular is too light. Software emboldening of a semi-bold will )probably) not give an inferior quality bold typeface but something heavier (semi-extra-bold?). I would argue that code shouldn't have to strip redundant properties but should rather have to make some extra calls in order to obtain them - QFontInfo::styleName() in this case. I know that QFontDialog() will return fonts that have the styleName set ... but the goal of the KFont* APIs is to improve on what Qt has to offer, no? On a related note: wouldn't it be possible to obtain a QFont that has never had the styleName property set internally, and then add it, rather than depend on being able to strip it? -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 426190] New: [KDevelop] : C++ code highlighter glitch
https://bugs.kde.org/show_bug.cgi?id=426190 Bug ID: 426190 Summary: [KDevelop] : C++ code highlighter glitch Product: kdevelop Version: 5.5.80 Platform: Compiled Sources OS: All Status: REPORTED Severity: normal Priority: NOR Component: Language Support: CPP (Clang-based) Assignee: kdevelop-bugs-n...@kde.org Reporter: rjvber...@gmail.com Target Milestone: --- SUMMARY The C++ code highlighter derails in KDMGeneralWidget::loadGuiStyles() STEPS TO REPRODUCE 1. Fetch my KDM5 project from github:RJVB/kdm5.git and import it into KDevelop 2. open kdm/kcm/kdm-gen.cpp and navigate to `KDMGeneralWidget::loadGuiStyles()` OBSERVED RESULT The highlighting and auto-indenting are off from the #else in that function if code is forced to use the #else branch. EXPECTED RESULT It should make no difference if the code has `#if 0` or `#if 1`. SOFTWARE/OS VERSIONS KDE Frameworks Version: 5.60.0 Qt Version: 5.9.8 -- You are receiving this mail because: You are watching all bug changes.
