KDE Frameworks 5.64.0 released
10th November 2019. KDE today announces the release of KDE Frameworks 5.64.0. KDE Frameworks are 81 addon libraries to Qt which provide a wide variety of commonly needed functionality in mature, peer reviewed and well tested libraries with friendly licensing terms. For an introduction see https://kde.org/products/frameworks/ Attica Add some std::move in setter functions Baloo Make it compile against qt5.15 Use propertymap to store properties in Baloo::Result Add standalone conversion functions for PropertyMap to Json and vice versa [Database] Rework handling environment flags Replace recursion in FilteredDirIterator with loop iteration Breeze Icons Center-align the non-square 64px audio mimetype icons (bug 393550) Delete remnants of nepomuk icon Move colorful 32px help-about icon into actions (bug 396626) Improve draw icons (bug 399665) Delete nepomuk icon Fill middle mouse button area Add folder-recent, extend hand of clock in folder-temp Use a more correct and appropriate visual metaphor for "get hot new stuff" icon (bug 400500) Update elisa icon Use css instead of scss as output format Fix incorrect rendering of 22px edit-opacity icon Add edit-opacity icons (bug 408283) Icons for windy weather (bug 412718) Fix incorrect margins in 16/22px media icons Use the text rather than highlight color for rating/star emblem Add draw-arrow icons (bug 408283) Add draw-highlight action icons (bug 408283) Add PATH/LD_LIBRARY_PATH to qrcAlias invocation Add applications-network icon for renaming Internet category to Network Add edit-line-width icons (bug 408283) Extra CMake Modules Don't set C/C++ standards if already set Use modern way to set the C/CXX standad Raise CMake requirements to 3.5 ECMAddQch: support PREDEFINED_MACROS/BLANK_MACROS with blanks & quotes Framework Integration Add standard icons to support to all entries in QDialogButtonBox (bug 398973) ensure winId() not called on non-native widgets (bug 412675) KActivitiesStats tests: fix macos build failure Windows MSVC compile fix Add a utility accessor to get a QUrl from a ResultSet::Result KArchive Fix memory leak in KXzFilter::init Fix null pointer reference when extraction fails decodeBCJ2: Fix assert with broken files KXzFilter::Private: remove unused props K7Zip: Fix memory use in readAndDecodePackedStreams KCalendarCore # Add libical version too Explicitly define the Journal copy ctor KCMUtils Conditionally show navigation buttons in the header for multi-page KCMs don't use a custom header height (bug 404396) add extra include Fix memory leak of KQuickAddons::ConfigModule objects (bug 412998) [KCModuleLoader] Show error when QML fails to load KConfig kconfig_compiler: Move the KSharedConfig::Ptr when using them Make it compile against qt5.15 without deprecated method Expose isImmutable to introspection (e.g. QML) Add convenience for defaults/dirty states to KCoreConfigSkeleton Make kconfig_compiler generate ctors with the optional parent arg Make preferences() a public function KConfigWidgets Avoid overloading KCModule::changed KContacts Install translations KCoreAddons KProcessInfoList -- add proclist backend for FreeBSD KDeclarative Use compile time checked connect Make the settingChanged() slot protected Get KQuickAddons::ConfigModule to expose if we're in the defaults state Grab the keyboard when KeySequenceItem is recording Add ManagedConfigModule Remove outdated comment about [$e] expansion [ConfigModule] Expose mainUi component status and error string KDELibs 4 Support KLocale api docs: make it easier to find how to port code away from it KDocTools man: use instead of KFileMetaData Fix crash in writer collection and cleanup KHTML Extend KHtmlView::print() to use a predefined QPrinter instance (bug 405011) KI18n Add KLocalizedString::untranslatedText Replace all qWarning and related calls with categorised logging KIconThemes Fix usage of the new deprecation macros for assignIconsToContextMenu Deprecate KIconTheme::assignIconsToContextMenu KIO Const & signature of new introduced SlaveBase::configValue Port to the QSslError variant of KSslInfoDialog Port KSSLD internals from KSslError to QSslError Make non-ignorable SSL errors explicit auto-enable KIO_ASSERT_SLAVE_STATES also for from-git builds Port (most of) KSslInfoDialog from KSslError to QSslError kio_http: avoid double Content-Type and Depth when used by KDAV Port the KSSLD D-Bus interface from KSslError to QSslError Replace usage of SlaveBase::config()->readEntry by SlaveBase::configValue Remove two unused member variables using KSslError Avoid sending KDirNotify::emitFilesAdded when the emptytrashjob finishes Deprecate the KTcpSocket-based variant of SslUi::askIgnoreSslErrors Treat "application/x-ms-dos-executable" as executable on all platforms (bug 412694) Replace usage of
Re: plasma-nano and plasma-phone-components are now in kdereview
El divendres, 8 de novembre de 2019, a les 8:09:33 CET, Bhushan Shah va escriure: > Hello! > > plasma-phone-components: https://invent.kde.org/kde/plasma-phone-components clazy found a crasher const char* country = countrycode.toUtf8().constData(); other minor clazy stuff in http://paste.debian.net/1115558/ And other minor clang-tidy stuff in http://paste.debian.net/1115559/ Cheers, Albert
Re: plasma-nano and plasma-phone-components are now in kdereview
El divendres, 8 de novembre de 2019, a les 8:09:33 CET, Bhushan Shah va escriure: > Hello! > > plasma-nano: https://invent.kde.org/kde/plasma-nano Please mark PlasmaMiniShellPrivatePlugin::registerTypes as override What's the point of this? connect(this, ::activeChanged, this, ::activeChanged); You're double sending the signal? Cheers, Albert
Re: plasma-nano and plasma-phone-components are now in kdereview
El divendres, 8 de novembre de 2019, a les 8:09:33 CET, Bhushan Shah va escriure: > Hello! > > plasma-nano: https://invent.kde.org/kde/plasma-nano > plasma-phone-components: https://invent.kde.org/kde/plasma-phone-components > > Two repos have been moved to kdereview, with final intended destinition > being kde/workspace. > > plasma-nano is a minimal shell package which other shell package can > extend, while plasma-phone-components is a shell package, look and feel > and several other components which makes Plasma Mobile. In the future, can we please have one email per component so it gets easier to track what has been said about what? Cheers, Albert > > Thanks >
Re: Quick Charts in KDE Review
Am Samstag, 9. November 2019, 14:16:08 CET schrieb David Edmundson: > > If one restricts oneself to use only libraries part of KDE Frameworks, but > > not from the "Extragear" domain, one should reconsider it, this does not > > make much sense as long one also uses non-KDE-party libraries (which also > > do not follow KF rules). > > Plasma effectively has such a rule. > > Treating this as a more meta discussion about libs, sure, with KDE > rules in extragear you can change ABI/API but the consequences still > mean in reality you can't. > Release an incompatible lib, things explode until recompiled. I am confused this is assuming one releases an incompatible library not using respective versioning schemes and not allowing parallel install? But people do that properly, no? > If we use a lib in plasma and in an application and then change the > lib API we always have a window where either applications latest > release or plasma latest release won't compile against the released > lib. Even if you bump the .so version Why the "even"? One should. That's what the purpose of the so version is. > the headers aren't > co-installable. Some projects do proper version namespaces also for include path on changed ABI. If projects do not, they should start to do IMHO. Even without, normally developers only work against one version of the library, so just having one variant of headers installed works good enough. > Due to this release problem Plasma has previously made any use of > extragear (or unstable 3rd party) #ifdef'd and always not in core > functionality. Given Plasma requires recent versions of KF on .0 releases, the same can be done also for newer versions of non-KF libraries, where one then switches to the new API series. No need for #ifdef. > >But I recommend to do as others and not bind to > > current first ABI for some time to come > > Note this is all somewhat moot for this specific case. There is only a > QML import. It can change ABI all it wants. Changing API is also > doable as long as QML import bumps and the old version still works. That is no different to normal compiled library symbols, no? One also cannot break "ABI" (not sure what the respective name would be in dynamic languages), i.e. change names of symbols or their types at QML layer. Think QQC 1 and QQC 2. Of course this comes at cost. But personally I am willing to pay that price over having to stick with API which proved to be not good enough and thus makes my own code worse. Thus my 2 cent recommendation to stay flexible for now :) But everyone has different priorities, just wanted to make you consider this. Cheers Friedrich
Re: Quick Charts in KDE Review
> If one restricts oneself to use only libraries part of KDE Frameworks, but not > from the "Extragear" domain, one should reconsider it, this does not make much > sense as long one also uses non-KDE-party libraries (which also do not follow > KF rules). Plasma effectively has such a rule. Treating this as a more meta discussion about libs, sure, with KDE rules in extragear you can change ABI/API but the consequences still mean in reality you can't. Release an incompatible lib, things explode until recompiled. If we use a lib in plasma and in an application and then change the lib API we always have a window where either applications latest release or plasma latest release won't compile against the released lib. Even if you bump the .so version the headers aren't co-installable. Being in this situation where we break ourselves means every packager would murder you on sight. Due to this release problem Plasma has previously made any use of extragear (or unstable 3rd party) #ifdef'd and always not in core functionality. >But I recommend to do as others and not bind to current first ABI for some time to come Note this is all somewhat moot for this specific case. There is only a QML import. It can change ABI all it wants. Changing API is also doable as long as QML import bumps and the old version still works.
Re: Quick Charts in KDE Review
Am Donnerstag, 7. November 2019, 16:21:40 CET schrieb Nate Graham: > On 11/7/19 7:34 AM, Friedrich W. H. Kossebau wrote: > > Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra: > >> Quick Charts is a QML module that implements a set of high-performance, > >> GPU accelerated > >> charts. Currently the main user of it is a new KSysGuard UI I have been > >> working on, but > >> once it is part of Frameworks I also hope to convert several bits of > >> Plasma to using it. > > > > If there is only one user currently, might it perhaps be a better idea to > > do some independent releases for a while to get more feedback on the API, > > before settling to the API freeze by being part of KDE Frameworks? It > > will be at least a year until KF6 is there to properly fix up any > > potential API inconveniences which users might find. > > I would at least recommend to first get some API shaping by real-world > > exposure. > > Seems like a chicken-egg problem: more exposure would be provided by > getting it through the review process, no? I can see us porting the > graphs in KInfoCenter to use this, for example. But since that's > shipping code, we might not want to do that until it's formally a framework. If one restricts oneself to use only libraries part of KDE Frameworks, but not from the "Extragear" domain, one should reconsider it, this does not make much sense as long one also uses non-KDE-party libraries (which also do not follow KF rules). Review process is about passing something from playground into the set of no- longer-playground repos. Which for libs can be KDE Frameworks domain, but also the "Extragear" domain. Both are equally post-review. And "Extragear" gives the flexibility to do another product version with different ABI, once there has been more feedback from more users. An approach e.g. taken by KUserFeedback. But also compare the concept of Qt labs modules. Having an API mainly done for one user only right now runs a good chance to miss the API needs of other potential candidates. Everyone needs a different 20 % of the API concepts, they say when throwing with numbers ;) Np chicken-egg problem here. Release-often-and-early should be simply applied to KChickCharts as well. But I recommend to do as others and not bind to current first ABI for some time to come, like begin of KF6, instead plan for some optional ABI-breaking releases in the near future. So be under the rules of Extragear, not yet Frameworks. But people learn best from own mistakes, so feel free to ignore some old person's comment-from-experience. ;) If the API proves to be not perfect and one knows how it would be better, ~12 months (to KF6) can be very long :P Cheers Friedrich
