Re: Koko in KDEReview
On Tuesday, 16 March 2021 20:10:46 CET Carl Schwan wrote: > > > - on the topic of licensing: since the code base is really close to > > > complete reuse coverage it might be nice to push it over the finishing > > > line and then `reuse lint` it to not have it fall behind again > > This will be a bit tricky since the remaining files were not written by any > current contributors. I could try to contact the old contributors. You don't need to contact them, you need to know what the license on the file is, and who contributed to it. Presumably you know the license (that was made clear to all contributors early in the lifetime of the project, I should hope) and git log will tell you who that was. Then you need one line SPDX-License-Identifier: for the file, and per contributor SPDX-FileCopyrightText: Person Name (On that last one, some folk insist on "(C)" or "Copyright" after the :, and perhaps a year as well; the jury is still out on that). [ade] signature.asc Description: This is a digitally signed message part.
KDE Gear promotion material
Hello everyone, The release of KDE Gear 21.04 is approaching and it would be nice if developers could help promo by adding the new features and bugfixes in the app they are maintaining in the following file: https://invent.kde.org/websites/kde-org/-/edit/work/gear-2104/content/announcements/gear/21.04.md?from_merge_request_iid=85 It doesn't needs to be elaborate and can just be a list of MR/commits/ bugreports closed/... Thanks, Carl
Re: Koko in KDEReview
Le dimanche, mars 14, 2021 1:03 AM, Carl Schwan a écrit : > Le dimanche, mars 14, 2021 12:22 AM, Albert Astals Cid aa...@kde.org a écrit : > > > El dissabte, 13 de març de 2021, a les 20:14:26 CET, Carl Schwan va > > escriure: > > > > > Hi, > > > I would like to move Koko to KDEReview. Koko is a convergent image > > > viewer that works on both Plasma Desktop and Plasma Mobile. It's the > > > second try of Koko in KDEReview, the first try failed1 because Koko > > > didn't really worked with traditional packaging and was too focused > > > on the mobile usecase. > > > Since the first attempt, a lot of things changed. There is now > > > packaging instructions in the readme, and a lot of features have > > > been added: > > > > > > - Simple image editor > > > - Metadata editing and viewing (contributed by Mikel) > > > - Slideshow (contributed by Mike) > > > - Allow to open images from Dolphin with Koko > > > - Better share dialog > > > - Better file browsing (contributed by Mikel and me) > > > - Remote folder browsing with KIO > > > - Better indexing with live updates (contributed by Mikel) > > > - Bookmark folders (contributed by Mikel) > > > - Support of animated images (contributed by Mikel and me) > > > - Make it possible to add pictures to favorites (contributed by Mikel) > > > > > > There are additionally two features that will hopefully be added soon: > > > > > > - File operation (copy, move, delete, ...) > > > - A better single image editor. Currently it is using simple QImage > > > manipulation with a command pattern but to make it a bit more powerful > > > and to support filters and other useful features this won't work. So > > > I have been experimenting with glsl shaders and then rendering the > > > image in an offscreen windows and another way and probably the safest > > > one > > > in term of maintenance and features of using the gegl library from > > > GIMP. > > > I would appreciate some opinions about that. > > > > > > > > > The repo: https://invent.kde.org/graphics/koko > > > The repo for the image editor: > > > https://invent.kde.org/libraries/kquickimageeditor/ > > > (required for koko to run) > > > > These two seem like should be fixable relatively easily > > QCommandLineParser: already having an option named "h" > > QCommandLineParser: already having an option named "help-all" > > QCommandLineParser: already having an option named "v" > > qrc:/qml/SelectionDelegateHighlight.qml:13: TypeError: Cannot read property > > 'z' of undefined > > done > > > While watching a photo in a folder, if i press Fullscreen i lose keyboard > > navigation with left/right arrows > > Fixedhttps://invent.kde.org/graphics/koko/commit/dfa608bd127e3108993edb7728e2d1954ed59cab > > > The "Select All" button does nothing? Or i don't understand what it does > > ^_^ Ahhh i see, it only selects images, not folders, that's a bit > > confusing. Maybe rename to Select All Images? Or it will be too long? > > Using "Select All Images" is a good idea I think. At least when no image is > selected and it's the only button in the toolbar. I will ask VDG for their > opinion tomorrow. > > > I would like to be able to move myself around in the "folder view" with the > > keyboard, but i understand that if this is mainly mobile oriented that's > > probably not so important. > > Keyboard navigation has been something Mikel and I have been focused on, but > the keyboard navigation in grid view has been more of a challenge I would > have hoped. For some reasons the focus chain never go to the grid view :( I > will try to investigate more. This should be almost fixed now. Koko should now be fully keyboard navigable, but there is still room for progress. > > > I would really like if we had a kxmlgui equivalent for QtQuick that gave me > > the "configure shortcuts" and stuff functionality, but that's unrelated to > > koko :) > > Same (and also editable toolbars) :) I might give it a try somedays > > > Cheers, > > Albert > > > > > Cheers, > > > Carl
Re: Koko in KDEReview
Le mardi, mars 16, 2021 12:55 PM, Harald Sitter a écrit :
> On Tue, Mar 16, 2021 at 12:49 PM Harald Sitter sit...@kde.org wrote:
>
> > Yay!
Thanks for the big review :)
> >
> > - please get a bugzilla produce created for it
Not a fan of that. This will ends up exactly like the www bugs, something
that I look into every 6 months. We already have many issues opened in
invent and it's working fine for us. Also we don't use KCrash.
> > - COPYING-CMAKE-SCRIPTS seems unused
removed
> > - the find_package calls on qt5 probably should be versioned on
> > whatever version you actually tested with, currently it's unversioned
> > which I doubt is correct
> >
> > - same for kquickimageeditor
Fixed
> > - kquickimageeditor is found with an empty COMPONENTS list. is that
> > intentional?
I think I fixed it. The CMake code is inspired by some random stuff I found in
the frameworks, this is probably why...
> > - unless you specifically target kf5.70 it might make sense to bump to
> > .79 and use KDEGitCommitHooks so clang-format is more consistently
> > applied
Done
> > - kdtree.{c,h} references BSD-3-Clause but that license isn't in the
> > source
Done
> > - on the topic of licensing: since the code base is really close to
> > complete reuse coverage it might be nice to push it over the finishing
> > line and then `reuse lint` it to not have it fall behind again
This will be a bit tricky since the remaining files were not written by any
current contributors. I could try to contact the old contributors.
> > - some classes have trivial constructors/destructors and could use
> > =default (e.g. roles.cpp, types.cpp, processor.cpp, openfilemodel.cpp,
> > probably others)
Fixed
> >
> > - some of those are further QObjects that have a parent signature but
> > don't delegate construction correctly (i.e. the parent arg is never
> > forwarded to QObject). since they are also trivial the constructors
> > could be removed and replaced by `using QObject::QObject;` to adopt
> > QObject's ctors (e.g. roles.cpp, types.cpp)
Fixed
> >
> > - some of the .h's have `parent = 0`, it'd be nice to have them use
> > nullptr instead
Done
> >
> > - some functions take references when they should take const refs
> > (e.g. `void setPath(QString )` or the ImageProcessorRunnable ctor)
> > this suggests they mutate the object, but really the mentioned
> > functions don't
Done
> >
> > - for future reference: .appdata.xml is a legacy suffix and
> > .metainfo.xml ought to be used instead. alas, no point changing this
> > now to avoid extra work for the i18n team
> >
> > - the appstream file must use the CDN not a wiki for screenshots
> > https://invent.kde.org/websites/product-screenshots
Done
> >
> > - also generally speaking please don't generate or use thumbs for
> > appstream files, appstream-generator will thumbnail the raw images
> > during assembling stage on the distro side of things
> >
> > - appstream data has a help link that goes nowhere
> >
> > While koko is running, if I copy a file with geodata to the pictures
> > dir it crashes on `kd_insert3 (tree=0x0,` supposedly because the
> > geocoder had been deinit()'d while it was still running. most notably
> > Processor (which is the gui thread) calls deinit on the geocoder
> > (which is used from various runner threads). in point of fact,
> > glancing over the code I'm not convinced this is actually correctly
> > threading
> > ImageProcessorRunnable is a runnable that is put into the thread pool.
> > Inside its run there's
> >
> > if (!m_geoCoder->initialized()) {
> > m_geoCoder->init();
> > }
> >
> >
> > This is racing code. In between the call to initialized() and the
> > init() another thread might have done init() already. At best that is
> > leaking kd_create instances, at worst that crashes on one of the many
> > asserts on members. On top of that Processor then also calls into
> > deinit() from its thread which might be at any point in time while the
> > Runnable's run() runs. The entire construct is lacking any sort of
> > appreciation for thread synchronization. This needs at least a mutex
> > to synchronize the init/deinit and possibly lookup if kd_* is not
> > thread safe.
> > I am not sure if the init-deinit dance is really adding much value
> > here. If it isn't I might just do away with the deinit TBH.
> > HS
This code is now using a ReadWriteLock. This should fix the racing code.
>
> Oh! Three follow ups:
>
> - is it intentional that this isn't a uniqueapp [1]? do multiple
> concurrent koko instances even work with the database?
It is intentional since users can open image from Dolphin while Koko is
already running. Maybe I could look into using KDSingleApplication for
this usecase. Also multiple koko instances seems to be working in my
experience but I didn't really test that in details.
>
> - the
Re: Plasma LeakGuard
That file is, without doubt, the best part of the project. On Tue, 16 Mar 2021 at 15:45, Aleix Pol wrote: > On Tue, Mar 16, 2021 at 3:40 PM Konstantin Kharlamov > wrote: > > > > I think the most interesting thing here is to know what plasmashell > developers > > think about it. Is it perhaps possible they don't have a reproducer for > memory > > leak, and you have it? In which case it seems more productive to fix the > bug. > > > > Please, get in touch with plasmashell devs, I'm sure they will be glad > to get > > any help in addressing that sort of issues. > > > > On Tue, 2021-03-16 at 15:34 +0100, Alberto Salvia Novella wrote: > > > The thing is that plasmashell isn't always started via its service, at > least > > > this is the case on my system. I shall look into that. > > > > > > On Tue, 16 Mar 2021 at 07:41, Konstantin Kharlamov > wrote: > > > > On Tue, 2021-03-16 at 01:29 +0100, Alberto Salvia Novella wrote: > > > > > I have created this tool for the Plasma desktop: > > > > > https://gitlab.com/es20490446e/plasma-leakguard > > > > > > > > > > Shall I announce it somewhere? > > > > > > > > > > (When replying please include my email address on the "to" field, > as I > > > > > have > > > > > mail delivery disabled for this list) > > > > > > > > (note: I'm just a random passer-by contributor) > > > > > > > > I think you better discuss this with plasmashell developers. > Clearly, memory > > > > leaks need to be fixed instead of working them around. Although if > they deem > > > > such tool as you suggest necessary, to me it seems easier to > implement by > > > > creating a plasmashell user-level service with `MemoryMax=` variable > set and > > > > being restartable (or, in case they wouldn't want to depend on > systemd, I > > > > imagine it should be available with bare cgroups too). > > > > > > I don't think this will ever be part of the solution. I've never seen > this problem myself, but in the end we just need to remove leaks > rather than just restarting plasma. I guess this is probably useful > for the original developer, so good for him. > > Note this app will make you lose whatever you're doing with the shell > at the time of the restart. > > The fact that there's this file in the project, makes me question the > intent of the project altogether: > https://gitlab.com/es20490446e/plasma-leakguard/-/blob/master/info/jokes.md > > Aleix >
Re: Plasma LeakGuard
On Tue, Mar 16, 2021 at 3:40 PM Konstantin Kharlamov wrote: > > I think the most interesting thing here is to know what plasmashell developers > think about it. Is it perhaps possible they don't have a reproducer for memory > leak, and you have it? In which case it seems more productive to fix the bug. > > Please, get in touch with plasmashell devs, I'm sure they will be glad to get > any help in addressing that sort of issues. > > On Tue, 2021-03-16 at 15:34 +0100, Alberto Salvia Novella wrote: > > The thing is that plasmashell isn't always started via its service, at least > > this is the case on my system. I shall look into that. > > > > On Tue, 16 Mar 2021 at 07:41, Konstantin Kharlamov > > wrote: > > > On Tue, 2021-03-16 at 01:29 +0100, Alberto Salvia Novella wrote: > > > > I have created this tool for the Plasma desktop: > > > > https://gitlab.com/es20490446e/plasma-leakguard > > > > > > > > Shall I announce it somewhere? > > > > > > > > (When replying please include my email address on the "to" field, as I > > > > have > > > > mail delivery disabled for this list) > > > > > > (note: I'm just a random passer-by contributor) > > > > > > I think you better discuss this with plasmashell developers. Clearly, > > > memory > > > leaks need to be fixed instead of working them around. Although if they > > > deem > > > such tool as you suggest necessary, to me it seems easier to implement by > > > creating a plasmashell user-level service with `MemoryMax=` variable set > > > and > > > being restartable (or, in case they wouldn't want to depend on systemd, I > > > imagine it should be available with bare cgroups too). > > > I don't think this will ever be part of the solution. I've never seen this problem myself, but in the end we just need to remove leaks rather than just restarting plasma. I guess this is probably useful for the original developer, so good for him. Note this app will make you lose whatever you're doing with the shell at the time of the restart. The fact that there's this file in the project, makes me question the intent of the project altogether: https://gitlab.com/es20490446e/plasma-leakguard/-/blob/master/info/jokes.md Aleix
Re: Plasma LeakGuard
Right now I don't have any memory leak, but any add-on can leak memory into the plasmashell process. So when there is going to be a leak cannot be controlled in reality. Even if you want to fix it, the consequences of not having a safeguard is a critical system failure. Anyway I will contact them. Thanks On Tue, 16 Mar 2021 at 15:39, Konstantin Kharlamov wrote: > I think the most interesting thing here is to know what plasmashell > developers > think about it. Is it perhaps possible they don't have a reproducer for > memory > leak, and you have it? In which case it seems more productive to fix the > bug. > > Please, get in touch with plasmashell devs, I'm sure they will be glad to > get > any help in addressing that sort of issues. > > On Tue, 2021-03-16 at 15:34 +0100, Alberto Salvia Novella wrote: > > The thing is that plasmashell isn't always started via its service, at > least > > this is the case on my system. I shall look into that. > > > > On Tue, 16 Mar 2021 at 07:41, Konstantin Kharlamov > wrote: > > > On Tue, 2021-03-16 at 01:29 +0100, Alberto Salvia Novella wrote: > > > > I have created this tool for the Plasma desktop: > > > > https://gitlab.com/es20490446e/plasma-leakguard > > > > > > > > Shall I announce it somewhere? > > > > > > > > (When replying please include my email address on the "to" field, as > I > > > > have > > > > mail delivery disabled for this list) > > > > > > (note: I'm just a random passer-by contributor) > > > > > > I think you better discuss this with plasmashell developers. Clearly, > memory > > > leaks need to be fixed instead of working them around. Although if > they deem > > > such tool as you suggest necessary, to me it seems easier to implement > by > > > creating a plasmashell user-level service with `MemoryMax=` variable > set and > > > being restartable (or, in case they wouldn't want to depend on > systemd, I > > > imagine it should be available with bare cgroups too). > > > > > >
Re: Plasma LeakGuard
I think the most interesting thing here is to know what plasmashell developers think about it. Is it perhaps possible they don't have a reproducer for memory leak, and you have it? In which case it seems more productive to fix the bug. Please, get in touch with plasmashell devs, I'm sure they will be glad to get any help in addressing that sort of issues. On Tue, 2021-03-16 at 15:34 +0100, Alberto Salvia Novella wrote: > The thing is that plasmashell isn't always started via its service, at least > this is the case on my system. I shall look into that. > > On Tue, 16 Mar 2021 at 07:41, Konstantin Kharlamov wrote: > > On Tue, 2021-03-16 at 01:29 +0100, Alberto Salvia Novella wrote: > > > I have created this tool for the Plasma desktop: > > > https://gitlab.com/es20490446e/plasma-leakguard > > > > > > Shall I announce it somewhere? > > > > > > (When replying please include my email address on the "to" field, as I > > > have > > > mail delivery disabled for this list) > > > > (note: I'm just a random passer-by contributor) > > > > I think you better discuss this with plasmashell developers. Clearly, memory > > leaks need to be fixed instead of working them around. Although if they deem > > such tool as you suggest necessary, to me it seems easier to implement by > > creating a plasmashell user-level service with `MemoryMax=` variable set and > > being restartable (or, in case they wouldn't want to depend on systemd, I > > imagine it should be available with bare cgroups too). > >
Re: Plasma LeakGuard
The thing is that plasmashell isn't always started via its service, at least this is the case on my system. I shall look into that. On Tue, 16 Mar 2021 at 07:41, Konstantin Kharlamov wrote: > On Tue, 2021-03-16 at 01:29 +0100, Alberto Salvia Novella wrote: > > I have created this tool for the Plasma desktop: > > https://gitlab.com/es20490446e/plasma-leakguard > > > > Shall I announce it somewhere? > > > > (When replying please include my email address on the "to" field, as I > have > > mail delivery disabled for this list) > > (note: I'm just a random passer-by contributor) > > I think you better discuss this with plasmashell developers. Clearly, > memory > leaks need to be fixed instead of working them around. Although if they > deem > such tool as you suggest necessary, to me it seems easier to implement by > creating a plasmashell user-level service with `MemoryMax=` variable set > and > being restartable (or, in case they wouldn't want to depend on systemd, I > imagine it should be available with bare cgroups too). > >
KDE CI: Frameworks » kwayland » kf5-qt5 SUSEQt5.14 - Build # 25 - Failure!
BUILD FAILURE Build URL https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20SUSEQt5.14/25/ Project: kf5-qt5 SUSEQt5.14 Date of build: Tue, 16 Mar 2021 13:52:46 + Build duration: 1 min 19 sec and counting CONSOLE OUTPUT [...truncated 851 lines...][2021-03-16T13:53:54.772Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/linuxdmabuf_v1_interface.cpp.o[2021-03-16T13:53:54.772Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/output_interface.cpp.o[2021-03-16T13:53:55.030Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/outputchangeset.cpp.o[2021-03-16T13:53:55.030Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/outputconfiguration_interface.cpp.o[2021-03-16T13:53:55.288Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/outputdevice_interface.cpp.o[2021-03-16T13:53:55.288Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/outputmanagement_interface.cpp.o[2021-03-16T13:53:55.853Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/plasmashell_interface.cpp.o[2021-03-16T13:53:56.110Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/plasmavirtualdesktop_interface.cpp.o[2021-03-16T13:53:56.368Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/plasmawindowmanagement_interface.cpp.o[2021-03-16T13:53:56.368Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointer_interface.cpp.o[2021-03-16T13:53:56.626Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointerconstraints_interface.cpp.o[2021-03-16T13:53:56.626Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointerconstraints_interface_v1.cpp.o[2021-03-16T13:53:56.893Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointergestures_interface.cpp.o[2021-03-16T13:53:57.158Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointergestures_interface_v1.cpp.o[2021-03-16T13:53:57.158Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/qtsurfaceextension_interface.cpp.o[2021-03-16T13:53:57.754Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/region_interface.cpp.o[2021-03-16T13:53:58.026Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/relativepointer_interface.cpp.o[2021-03-16T13:53:58.614Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/relativepointer_interface_v1.cpp.o[2021-03-16T13:53:58.614Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/remote_access_interface.cpp.o[2021-03-16T13:53:58.614Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/resource.cpp.o[2021-03-16T13:53:58.614Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/seat_interface.cpp.o[2021-03-16T13:53:58.614Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/server_decoration_interface.cpp.o[2021-03-16T13:53:59.200Z] /home/jenkins/workspace/Frameworks/kwayland/kf5-qt5 SUSEQt5.14/src/server/pointergestures_interface_v1.cpp:47:1: warning: missing initializer for member ���zwp_pointer_gestures_v1_interface::release��� [-Wmissing-field-initializers][2021-03-16T13:53:59.200Z]47 | };[2021-03-16T13:53:59.200Z] | ^[2021-03-16T13:53:59.200Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/server_decoration_palette_interface.cpp.o[2021-03-16T13:53:59.200Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/shadow_interface.cpp.o[2021-03-16T13:53:59.767Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/shell_interface.cpp.o[2021-03-16T13:53:59.767Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/slide_interface.cpp.o[2021-03-16T13:53:59.767Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/subcompositor_interface.cpp.o[2021-03-16T13:54:00.024Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/surface_interface.cpp.o[2021-03-16T13:54:00.024Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/surfacerole.cpp.o[2021-03-16T13:54:00.957Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/tablet_interface.cpp.o[2021-03-16T13:54:00.957Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/textinput_interface.cpp.o[2021-03-16T13:54:00.957Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/textinput_interface_v0.cpp.o[2021-03-16T13:54:01.214Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/textinput_interface_v2.cpp.o[2021-03-16T13:54:01.472Z] make[1]: *** [CMakeFiles/Makefile2:568: src/client/CMakeFiles/KF5WaylandClient.dir/all] Error 2[2021-03-16T13:54:01.472Z] make[1]: *** Waiting for unfinished jobs[2021-03-16T13:54:01.472Z] [ 43%]
KDE CI: Frameworks » kwayland » kf5-qt5 SUSEQt5.15 - Build # 58 - Failure!
BUILD FAILURE Build URL https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20SUSEQt5.15/58/ Project: kf5-qt5 SUSEQt5.15 Date of build: Tue, 16 Mar 2021 13:52:47 + Build duration: 1 min 19 sec and counting CONSOLE OUTPUT [...truncated 852 lines...][2021-03-16T13:53:54.515Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/linuxdmabuf_v1_interface.cpp.o[2021-03-16T13:53:54.773Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/output_interface.cpp.o[2021-03-16T13:53:55.031Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/outputchangeset.cpp.o[2021-03-16T13:53:55.297Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/outputconfiguration_interface.cpp.o[2021-03-16T13:53:55.297Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/outputdevice_interface.cpp.o[2021-03-16T13:53:55.553Z] [ 38%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/outputmanagement_interface.cpp.o[2021-03-16T13:53:55.817Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/plasmashell_interface.cpp.o[2021-03-16T13:53:55.817Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/plasmavirtualdesktop_interface.cpp.o[2021-03-16T13:53:55.817Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/plasmawindowmanagement_interface.cpp.o[2021-03-16T13:53:56.402Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointer_interface.cpp.o[2021-03-16T13:53:56.402Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointerconstraints_interface.cpp.o[2021-03-16T13:53:56.669Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointerconstraints_interface_v1.cpp.o[2021-03-16T13:53:56.938Z] [ 39%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointergestures_interface.cpp.o[2021-03-16T13:53:57.195Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointergestures_interface_v1.cpp.o[2021-03-16T13:53:57.456Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/qtsurfaceextension_interface.cpp.o[2021-03-16T13:53:57.714Z] make[1]: *** [CMakeFiles/Makefile2:568: src/client/CMakeFiles/KF5WaylandClient.dir/all] Error 2[2021-03-16T13:53:57.714Z] make[1]: *** Waiting for unfinished jobs[2021-03-16T13:53:57.714Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/region_interface.cpp.o[2021-03-16T13:53:57.714Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/relativepointer_interface.cpp.o[2021-03-16T13:53:57.714Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/relativepointer_interface_v1.cpp.o[2021-03-16T13:53:57.971Z] [ 40%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/remote_access_interface.cpp.o[2021-03-16T13:53:57.971Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/resource.cpp.o[2021-03-16T13:53:58.231Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/seat_interface.cpp.o[2021-03-16T13:53:58.489Z] /home/jenkins/workspace/Frameworks/kwayland/kf5-qt5 SUSEQt5.15/src/server/pointergestures_interface_v1.cpp:47:1: warning: missing initializer for member ���zwp_pointer_gestures_v1_interface::release��� [-Wmissing-field-initializers][2021-03-16T13:53:58.489Z]47 | };[2021-03-16T13:53:58.489Z] | ^[2021-03-16T13:53:58.750Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/server_decoration_interface.cpp.o[2021-03-16T13:53:59.009Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/server_decoration_palette_interface.cpp.o[2021-03-16T13:53:59.009Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/shadow_interface.cpp.o[2021-03-16T13:53:59.268Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/shell_interface.cpp.o[2021-03-16T13:53:59.268Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/slide_interface.cpp.o[2021-03-16T13:53:59.527Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/subcompositor_interface.cpp.o[2021-03-16T13:53:59.527Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/surface_interface.cpp.o[2021-03-16T13:53:59.786Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/surfacerole.cpp.o[2021-03-16T13:54:00.043Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/tablet_interface.cpp.o[2021-03-16T13:54:00.043Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/textinput_interface.cpp.o[2021-03-16T13:54:00.301Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/textinput_interface_v0.cpp.o[2021-03-16T13:54:00.558Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/textinput_interface_v2.cpp.o[2021-03-16T13:54:00.558Z] [ 43%]
KDE CI: Frameworks » kwayland » kf5-qt5 FreeBSDQt5.15 - Build # 53 - Failure!
BUILD FAILURE Build URL https://build.kde.org/job/Frameworks/job/kwayland/job/kf5-qt5%20FreeBSDQt5.15/53/ Project: kf5-qt5 FreeBSDQt5.15 Date of build: Tue, 16 Mar 2021 13:52:48 + Build duration: 44 sec and counting CONSOLE OUTPUT [...truncated 866 lines...][2021-03-16T13:53:26.707Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointerconstraints_interface.cpp.o[2021-03-16T13:53:26.707Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointerconstraints_interface_v1.cpp.o[2021-03-16T13:53:26.707Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointergestures_interface.cpp.o[2021-03-16T13:53:26.707Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/pointergestures_interface_v1.cpp.o[2021-03-16T13:53:26.980Z] [ 41%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/qtsurfaceextension_interface.cpp.o[2021-03-16T13:53:26.980Z] In file included from /usr/home/jenkins/workspace/Frameworks/kwayland/kf5-qt5 FreeBSDQt5.15/src/server/plasmawindowmanagement_interface.cpp:6:[2021-03-16T13:53:26.980Z] /usr/home/jenkins/workspace/Frameworks/kwayland/kf5-qt5 FreeBSDQt5.15/src/server/plasmawindowmanagement_interface.h:39:5: warning: explicitly defaulted default constructor is implicitly deleted [-Wdefaulted-function-deleted][2021-03-16T13:53:26.980Z] PlasmaWindowManagementInterface() = default;[2021-03-16T13:53:26.980Z] ^[2021-03-16T13:53:26.980Z] /usr/home/jenkins/workspace/Frameworks/kwayland/kf5-qt5 FreeBSDQt5.15/src/server/plasmawindowmanagement_interface.h:34:63: note: default constructor of 'PlasmaWindowManagementInterface' is implicitly deleted because base class 'KWayland::Server::Global' has no default constructor[2021-03-16T13:53:26.980Z] class KWAYLANDSERVER_EXPORT PlasmaWindowManagementInterface : public Global[2021-03-16T13:53:26.980Z] ^[2021-03-16T13:53:26.980Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/region_interface.cpp.o[2021-03-16T13:53:26.980Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/relativepointer_interface.cpp.o[2021-03-16T13:53:27.241Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/relativepointer_interface_v1.cpp.o[2021-03-16T13:53:27.241Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/remote_access_interface.cpp.o[2021-03-16T13:53:27.504Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/resource.cpp.o[2021-03-16T13:53:27.504Z] [ 42%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/seat_interface.cpp.o[2021-03-16T13:53:27.769Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/server_decoration_interface.cpp.o[2021-03-16T13:53:27.769Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/server_decoration_palette_interface.cpp.o[2021-03-16T13:53:28.044Z] /usr/home/jenkins/workspace/Frameworks/kwayland/kf5-qt5 FreeBSDQt5.15/src/server/pointergestures_interface_v1.cpp:47:1: warning: missing field 'release' initializer [-Wmissing-field-initializers][2021-03-16T13:53:28.044Z] };[2021-03-16T13:53:28.044Z] ^[2021-03-16T13:53:28.044Z] 1 warning generated.[2021-03-16T13:53:28.044Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/shadow_interface.cpp.o[2021-03-16T13:53:28.044Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/shell_interface.cpp.o[2021-03-16T13:53:28.044Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/slide_interface.cpp.o[2021-03-16T13:53:28.044Z] [ 43%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/subcompositor_interface.cpp.o[2021-03-16T13:53:28.318Z] 1 warning generated.[2021-03-16T13:53:28.318Z] [ 44%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/surface_interface.cpp.o[2021-03-16T13:53:28.318Z] [ 44%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/surfacerole.cpp.o[2021-03-16T13:53:28.318Z] [ 44%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/tablet_interface.cpp.o[2021-03-16T13:53:28.633Z] [ 44%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/textinput_interface.cpp.o[2021-03-16T13:53:28.633Z] [ 44%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/textinput_interface_v0.cpp.o[2021-03-16T13:53:28.897Z] /usr/home/jenkins/workspace/Frameworks/kwayland/kf5-qt5 FreeBSDQt5.15/src/server/seat_interface.cpp:791:50: warning: unused parameter 'button' [-Wunused-parameter][2021-03-16T13:53:28.897Z] static quint32 qtToWaylandButton(Qt::MouseButton button)[2021-03-16T13:53:28.897Z] ^[2021-03-16T13:53:29.170Z] [ 44%] Building CXX object src/server/CMakeFiles/KF5WaylandServer.dir/textinput_interface_v2.cpp.o[2021-03-16T13:53:29.170Z] [ 45%] Building CXX object
Re: “Application Launcher 2.0” - New (simple) Feature Request
On 3/16/21 5:34 AM, Marco Uguccioni wrote: Thanks for the information, unfortunately being a graphic designer I'm not able to implement this feature myself, also I'm very new to the community. In case, how do I file It into a bugtracker in order to allow for anyone interested to pick this feature up and implement it? Welcome to KDE, Marco! See https://community.kde.org/Get_Involved/Issue_Reporting Nate
Re: Koko in KDEReview
On Tue, Mar 16, 2021 at 12:49 PM Harald Sitter wrote:
>
> Yay!
>
> - please get a bugzilla produce created for it
> - COPYING-CMAKE-SCRIPTS seems unused
> - the find_package calls on qt5 probably should be versioned on
> whatever version you actually tested with, currently it's unversioned
> which I doubt is correct
> - same for kquickimageeditor
> - kquickimageeditor is found with an empty COMPONENTS list. is that
> intentional?
> - unless you specifically target kf5.70 it might make sense to bump to
> .79 and use KDEGitCommitHooks so clang-format is more consistently
> applied
> - kdtree.{c,h} references BSD-3-Clause but that license isn't in the source
> - on the topic of licensing: since the code base is really close to
> complete reuse coverage it might be nice to push it over the finishing
> line and then `reuse lint` it to not have it fall behind again
> - some classes have trivial constructors/destructors and could use
> =default (e.g. roles.cpp, types.cpp, processor.cpp, openfilemodel.cpp,
> probably others)
> - some of those are further QObjects that have a parent signature but
> don't delegate construction correctly (i.e. the parent arg is never
> forwarded to QObject). since they are also trivial the constructors
> could be removed and replaced by `using QObject::QObject;` to adopt
> QObject's ctors (e.g. roles.cpp, types.cpp)
> - some of the .h's have `parent = 0`, it'd be nice to have them use
> nullptr instead
> - some functions take references when they should take const refs
> (e.g. `void setPath(QString )` or the ImageProcessorRunnable ctor)
> this suggests they mutate the object, but really the mentioned
> functions don't
> - for future reference: .appdata.xml is a legacy suffix and
> .metainfo.xml ought to be used instead. alas, no point changing this
> now to avoid extra work for the i18n team
> - the appstream file must use the CDN not a wiki for screenshots
> https://invent.kde.org/websites/product-screenshots
> - also generally speaking please don't generate or use thumbs for
> appstream files, appstream-generator will thumbnail the raw images
> during assembling stage on the distro side of things
> - appstream data has a help link that goes nowhere
>
> While koko is running, if I copy a file with geodata to the pictures
> dir it crashes on `kd_insert3 (tree=0x0,` supposedly because the
> geocoder had been deinit()'d while it was still running. most notably
> Processor (which is the gui thread) calls deinit on the geocoder
> (which is used from various runner threads). in point of fact,
> glancing over the code I'm not convinced this is actually correctly
> threading
>
> ImageProcessorRunnable is a runnable that is put into the thread pool.
> Inside its run there's
>
> if (!m_geoCoder->initialized()) {
> m_geoCoder->init();
> }
>
>
> This is racing code. In between the call to initialized() and the
> init() another thread might have done init() already. At best that is
> leaking kd_create instances, at worst that crashes on one of the many
> asserts on members. On top of that Processor then also calls into
> deinit() from its thread which might be at any point in time while the
> Runnable's run() runs. The entire construct is lacking any sort of
> appreciation for thread synchronization. This needs at least a mutex
> to synchronize the init/deinit and possibly lookup if kd_* is not
> thread safe.
>
> I am not sure if the init-deinit dance is really adding much value
> here. If it isn't I might just do away with the deinit TBH.
>
> HS
Oh! Three follow ups:
- is it intentional that this isn't a uniqueapp [1]? do multiple
concurrent koko instances even work with the database?
- the geodata magic doesn't seem to be working for me. it correctly
maps the geodata in ReverseGeoCoder but in the UI nothing is displayed
under locations
- since it doesn't appear in the UI, I can't check: is the geodata
actually getting localized? at least the geocoder seems to spit out
non-localized values
[1] https://api.kde.org/frameworks/kdbusaddons/html/classKDBusService.html
Re: Koko in KDEReview
Yay!
- please get a bugzilla produce created for it
- COPYING-CMAKE-SCRIPTS seems unused
- the find_package calls on qt5 probably should be versioned on
whatever version you actually tested with, currently it's unversioned
which I doubt is correct
- same for kquickimageeditor
- kquickimageeditor is found with an empty COMPONENTS list. is that intentional?
- unless you specifically target kf5.70 it might make sense to bump to
.79 and use KDEGitCommitHooks so clang-format is more consistently
applied
- kdtree.{c,h} references BSD-3-Clause but that license isn't in the source
- on the topic of licensing: since the code base is really close to
complete reuse coverage it might be nice to push it over the finishing
line and then `reuse lint` it to not have it fall behind again
- some classes have trivial constructors/destructors and could use
=default (e.g. roles.cpp, types.cpp, processor.cpp, openfilemodel.cpp,
probably others)
- some of those are further QObjects that have a parent signature but
don't delegate construction correctly (i.e. the parent arg is never
forwarded to QObject). since they are also trivial the constructors
could be removed and replaced by `using QObject::QObject;` to adopt
QObject's ctors (e.g. roles.cpp, types.cpp)
- some of the .h's have `parent = 0`, it'd be nice to have them use
nullptr instead
- some functions take references when they should take const refs
(e.g. `void setPath(QString )` or the ImageProcessorRunnable ctor)
this suggests they mutate the object, but really the mentioned
functions don't
- for future reference: .appdata.xml is a legacy suffix and
.metainfo.xml ought to be used instead. alas, no point changing this
now to avoid extra work for the i18n team
- the appstream file must use the CDN not a wiki for screenshots
https://invent.kde.org/websites/product-screenshots
- also generally speaking please don't generate or use thumbs for
appstream files, appstream-generator will thumbnail the raw images
during assembling stage on the distro side of things
- appstream data has a help link that goes nowhere
While koko is running, if I copy a file with geodata to the pictures
dir it crashes on `kd_insert3 (tree=0x0,` supposedly because the
geocoder had been deinit()'d while it was still running. most notably
Processor (which is the gui thread) calls deinit on the geocoder
(which is used from various runner threads). in point of fact,
glancing over the code I'm not convinced this is actually correctly
threading
ImageProcessorRunnable is a runnable that is put into the thread pool.
Inside its run there's
if (!m_geoCoder->initialized()) {
m_geoCoder->init();
}
This is racing code. In between the call to initialized() and the
init() another thread might have done init() already. At best that is
leaking kd_create instances, at worst that crashes on one of the many
asserts on members. On top of that Processor then also calls into
deinit() from its thread which might be at any point in time while the
Runnable's run() runs. The entire construct is lacking any sort of
appreciation for thread synchronization. This needs at least a mutex
to synchronize the init/deinit and possibly lookup if kd_* is not
thread safe.
I am not sure if the init-deinit dance is really adding much value
here. If it isn't I might just do away with the deinit TBH.
HS
Re: “Application Launcher 2.0” - New (simple) Feature Request
Thanks for the information, unfortunately being a graphic designer I'm not able to implement this feature myself, also I'm very new to the community. In case, how do I file It into a bugtracker in order to allow for anyone interested to pick this feature up and implement it? Regards. Il mar 16 mar 2021, 11:23 Nate Graham ha scritto: > On 3/16/21 3:46 AM, Konstantin Kharlamov wrote: > > On Tue, 2021-03-16 at 10:35 +0100, Marco Uguccioni wrote: > >> Dear Mr. Martin Graesslin & Mr. Mikel Johnson, > >> > >> I am writing you to kindly request a new feature > >> in the new version of the Kickoff Menu which will be released > with Plasma 5.21 > >> Stable: > > > > Should this suggestion go to a bugtracker instead? This would allow for > anyone interested to pick this feature up and implement it. Who knows, it > could even be you ;) The people you referred to I'm sure also work on > something they deem important; and a priority is often a subjective thing. > So, often the best way to ensure a feature one considers important is > implemented is to try taking a stab at it. > > > ^^ words of wisdom. :) > > Nate > >
Re: “Application Launcher 2.0” - New (simple) Feature Request
On 3/16/21 3:46 AM, Konstantin Kharlamov wrote: On Tue, 2021-03-16 at 10:35 +0100, Marco Uguccioni wrote: Dear Mr. Martin Graesslin & Mr. Mikel Johnson, I am writing you to kindly request a new feature in the new version of the Kickoff Menu which will be released with Plasma 5.21 Stable: Should this suggestion go to a bugtracker instead? This would allow for anyone interested to pick this feature up and implement it. Who knows, it could even be you ;) The people you referred to I'm sure also work on something they deem important; and a priority is often a subjective thing. So, often the best way to ensure a feature one considers important is implemented is to try taking a stab at it. ^^ words of wisdom. :) Nate
Re: “Application Launcher 2.0” - New (simple) Feature Request
On Tue, 2021-03-16 at 10:35 +0100, Marco Uguccioni wrote: > Dear Mr. Martin Graesslin & Mr. Mikel Johnson, > > I am writing you to kindly request a new feature > in the new version of the Kickoff Menu which will be released with Plasma 5.21 > Stable: Should this suggestion go to a bugtracker instead? This would allow for anyone interested to pick this feature up and implement it. Who knows, it could even be you ;) The people you referred to I'm sure also work on something they deem important; and a priority is often a subjective thing. So, often the best way to ensure a feature one considers important is implemented is to try taking a stab at it.
“Application Launcher 2.0” - New (simple) Feature Request
Dear Mr. Martin Graesslin & Mr. Mikel Johnson, I am writing you to kindly request a new feature in the new version of the *Kickoff Menu *which will be released with *Plasma 5.21 Stable**:* I would like to ask you to please *add the possibility* to also show the *applications* *categories* (Graphics, Internet, Multimedia, Office, etc...) both* in a grid* and *in a list*, the same way we can already set for the category “*favorites:*” inside the “Configure Application Launcher...” tab. *This would be so helpful for visual thinkers, it's the only* *thing the new stock menu is still missing, otherwise it* *will be finally perfect.* (Obviously I think this cannot be done for the *All Application *category too, or can it?) Please consider adding this new feature... It would be really nice to see this happening for the Plasma 5.21 release Thank you for your good work, Best regards Marco Uguccioni
Re: Plasma LeakGuard
On Tue, 2021-03-16 at 01:29 +0100, Alberto Salvia Novella wrote: > I have created this tool for the Plasma desktop: > https://gitlab.com/es20490446e/plasma-leakguard > > Shall I announce it somewhere? > > (When replying please include my email address on the "to" field, as I have > mail delivery disabled for this list) (note: I'm just a random passer-by contributor) I think you better discuss this with plasmashell developers. Clearly, memory leaks need to be fixed instead of working them around. Although if they deem such tool as you suggest necessary, to me it seems easier to implement by creating a plasmashell user-level service with `MemoryMax=` variable set and being restartable (or, in case they wouldn't want to depend on systemd, I imagine it should be available with bare cgroups too).
