Re: Move some out-of-date bindings to unmaintained
On Friday, April 24, 2020 9:27:46 PM PDT Bhushan Shah wrote: > There's some out-of-date bindings in the kdebindings, > > - kimono > - qyoto > - qtruby > - korundum > - perlqt > - perlkde > - smokeqt > - smokegen > - smokekde > - pykde4 > > Most of this are still based on Qt4, and does not have commits in say > last 4 years, there's also pykde5 but I don't know if is maintained? > > Anyway, any objections to me moving following to unmaintained? > > Thanks Very much in favor of this. Always a bit confusing when I attempt to use this and I see bugs hanging for so long. Bet, *Jacky Alcine*[1] [1] https://jacky.wtf/?utm_medium=email signature.asc Description: This is a digitally signed message part.
Re: General information for KDE Frameworks developers
Amazing news all around! Hoping this will lead to my first contribution! On Wed, Sep 9, 2020, at 06:31, David Faure wrote: > Here are some notes from the KF6 BoF at Akademy, as well as general > information that I realized might not be known to all the relevant developers. > > * There's a nice board with many tasks related to preparing KDE Frameworks > for > KF6. https://phabricator.kde.org/project/board/310/ > All the tasks in the "Backlog" column, are tasks that can be done TODAY > already, they don't depend on Qt6 or the possibility to break API/ABI in KDE > Frameworks. Help is very much needed and welcome! > > * We'll have an online meeting at some point to go through the board and add > tags for priorities and "junior jobs". > > * I strongly recommend subscribing to kde-frameworks-devel. If you got scared > in the past by the amount of "merge requests" emails coming in, this is no > longer the case with gitlab. > > * Instead, I recommend subscribing in gitlab to the projects you care about. > For instance you go to https://invent.kde.org/frameworks/kio and click on the > bell icon on the right of the large "KIO" header. > > * If you want to keep an eye on *all* Frameworks merge requests, as used to > happen on k-f-d, you can visit > https://invent.kde.org/groups/frameworks/-/merge_requests (however I don't > see > a way to get notified by email). > > * We decided on a two months deadline for the unittests that have always > failed on FreeBSD and Windows to be whitelisted with QEXPECT_FAIL macros, > and turned into bug reports. This way we can start from a clean state in CI, > react on regressions more easily, and even set up gitlab to check that MRs > don't introduce regressions on any platform. It'll also help reducing the > noise on k-f-d. > If you use either of those platforms, please give a hand with fixing those > issues for real. > Reminder: to see failing tests, go to > https://build.kde.org/job/Frameworks/view/Everything/ > then click on the platform you're interesting in, and then click on the "S" > column twice. The yellow will propagate to the top. > > Happy hacking! > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 > > > >
Re: KCGroups in KDEreview
This is exciting! Is it needed to explicitly put "cgroups" in the name? (What I'm really asking is if there's a way to have this work in a cross-platform way) On Fri, Nov 20, 2020, at 05:55, Henri Chain wrote: > Hello everyone, > > KCgroups has been moved to KDEReview ! > What is that, you ask ? It's a library that wraps the systemd dbus API to > expose a higher-level concept of desktop application and allow control of its > system resource usage (CPU, RAM, IO, etc). > > It relies on the recent ability of plasma to launch applications in their own > systemd scopes, with correspond to cgroups and provides a more robust > definition for an application (more details at > https://lwn.net/Articles/834329/ > ) . > > The main use of the library is to expose related resource control settings > for > those applications, at a user space level that other KDE applications and > frameworks can use, including consumption straight from QML as demonstrated > in > the test application. > > KCgroups is intended to become a (Tier 1) framework. A first user of this > library might be the foreground window CPU booster daemon that is available > here: https://invent.kde.org/libraries/kcgroups/-/tree/work/foreground-booster > > Packages are already available for both Neon and Arch Linux. > > Looking forward to your feedback and ideas for using this, > Henri > > >
Re: KDE review for KWeatherCore
Would it be possible for KweatherCore to lean on location services like Geoclue? (And/if should we be working on a KDE GUI for Geoclue to help with this? That way Kweather could only be dealing with resolving weather info) On Sunday, December 20, 2020 10:16:09 PM PST hanyoung wrote: > KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for > querying weather forecast data. During the development of KWeather, we > found the need to have a weather library. KWeatherCore is the result of > extracting weather data fetching code from KWeather. I think having a > dedicated weather library can serve the following propose: - simplify the > KWeather code > - easier to develop a weather daemon > - potentially less code duplication across KDE > > Many of you may have already seen my previous email to kde-devel mailing > list. > Thank you for your constructive suggestions. Here are something I want to clarify: > > I would also propose to consider doing a demon instead, so different > > programs/processes all interested in weather forecast data could share the > > data > > The end goal is a daemon indeed, but we want to build the daemon upon the > library. This would give us flexibility in the future if we don't want a > daemon. At least KWeather and other projects can still benefit from the > code. > > but we want to make sure we don't end up with two things. > > I admit there are some overlapped functionalities. But KWeatherCore isn't > designed as a weather data provider as Weather DataEngine. Instead, it's > trying to be the building block of weather related applications. > KWeatherCore saves you the hassle of dealing with APIs, getting locations > and converting timezone. You can build a daemon with it, or you can use it > in your applications. For example, KItinerary and KWeather use the same > weather API, but don't share code. That means two code base to maintain. > Regarding the dynamic nature of online APIs, it's better to have one > library, so other applications don't need to be worried about their APIs > being depraved, and they aren't able to update it in time. > > Though not currently implemented, KWeatherCore does intend to have weather > alerts added. We hope it can be done in this Sok > https://community.kde.org/SoK/Ideas/2021#KWeather > With this bit added, then the work on weather daemon can be started. > > Regards, > Han Young signature.asc Description: This is a digitally signed message part.
