Re: Glaxnimate KDE Review
On Wednesday, May 1, 2024 2:43:55 PM Central European Summer Time Mattia Basaglia wrote: > Hello, > > I'd like to have Glaxnimate enter KDE review. Really great app! I will put in my todo list to feature it more prominently in https://kde.org/for/creators/ and you might see a merge request from my for your website soon :) Cheers, Carl signature.asc Description: This is a digitally signed message part.
KDE Review OptiImage
Hi, After writing the initial commit back in 2021 and several rewrite (hello Rust, goodbye Rust ), I finally finished working on a new app: OptiImage. It's a GUI wrapper for a few tools: oxipng, jpegoptin, scour, cwebp to compress images. It's relatively basic and inspired by the following GNOME app: https://apps.gnome.org/Curtail/ Here is the issue to track the kde review https://invent.kde.org/graphics/optiimage/-/issues/2 I already fill all the trivial checkbox: e.g. CI running and reuse conformance. Clazy is unfortunately not working due to the lack of compiler support for coroutines in clazy. Cheers, Carl
Re: FileCopyrightText...
On Monday, January 29, 2024 10:43:04 AM CET Harald Sitter wrote: > do we really need it? > > systemd for example only has a spdx license header, resulting in much > tidier file headers. > > I entirely fail to understand why we need to slap a FileCopyrightText > on files. The copyright surely applies whether or not I put the > FileCopyrightText there. The list is also just about always > incomplete, further calling its use into question. Not to mention that > it is annoying book keeping of information that is already available > in git. > > Can someone shed some light on this? The reuse FAQ has an entry about why only keeping the copyright information in git is a bad idea: https://reuse.software/faq/#vcs-copyright Also when copying file between repo, the git history for that file is often lost. Cheers, Carl > > HS
Re: Kandalf: request for review
On Fri, Dec 8, 2023, at 12:10 AM, Albert Astals Cid wrote: > El dijous, 7 de desembre de 2023, a les 16:28:48 (CET), Loren Burkholder va > escriure: > > Hi all! > > > > I've been working towards getting Kandalf ready for integration into KDE > > (and I'd like to thank everyone who has pitched in to help me, mainly > > Laurent and redstrate). At this point, while the app is not necessarily > > feature-complete or fully polished, it's getting close to that point. > > Therefore, I'd like to officially request a review of Kandalf for inclusion > > in the KDE apps. > > Where is the thing we're supposed to review? In the wrong place: https://invent.kde.org/lorendb/kandalf/-/issues/1 I asked Loren to create a sysadmin ticket to get it moved to an offical namespace. Cheers, Carl
Move Accessibility Inspector to KDE Review
Hello, Yesterday night, I moved the accessibility inspector for libqaccessibilityclient to a new repo. Goal for that is to make this helpful tool more visible by making it a standalone app instead of a tool hidden in the build folder of libqaccessibilityclient. The repo is now live at: https://invent.kde.org/accessibility/accessibility-inspector Thanks Ben for taking care of that quickly. Aside from moving the repo, I made the UI translatable and started modernizing a bit the codebase and fixing bugs. The tracking issue for KDE Review is here: https://invent.kde.org/accessibility/accessibility-inspector/-/issues/1 Feel free to reply to this mail or on the issue. Cheers, Carl
Incubator and KDE Review checklist review
Hi, I came to my attention that there is a merge request to move the incubator and kde review checklist to develop.kde.org. As it contains some additional changes instead of a simple move, I think it would make sense to ask for additional reviews on this mailing list. See https://invent.kde.org/documentation/develop-kde-org/-/merge_requests/308 Cheers, Carl
Re: KDE Review: Hash-o-Matic
On Tuesday, 3 October 2023 08:33:02 CEST Benson Muite wrote: > On 10/2/23 09:52, Sune Vuorela wrote: > > On 2023-10-01, Carl Schwan wrote: > >> Hello, > >> > >> I started writting a small application to generate and compare files with > >> their checksum two years. I piked it up again recently and I think this > >> is now ready for a kde review. > > > > Even two years ago, checking stuff with md5 was not a good idea, unless > > just for checking for transfer errors. > > > > But maybe add a sha3 variant instead? > > It may be helpful to include sha3 and blake2 > https://doc.qt.io/qt-6/qcryptographichash.html > Can make a pull request with these if of interest. Merge requests are always welcome ;) > > /Sune
Re: KDE Review: Hash-o-Matic
On Tuesday, 3 October 2023 03:31:26 CEST Justin Zobel wrote: > I think it's clear we need some sort of process documentation for KDE > Review, who is expected to do what, and in which order. > > I've cc'd Thiago on this as they are KDE's documentation writer, let's > see if we can get something together. Before documenting a process, we first need to decide on the process itself, which seems to be the point of confussion here. We actually already have documentation on the process, but it doesn't make it clear who is responsible to fill the checklist: https://community.kde.org/Policies/Application_Lifecycle#kdereview
Re: KDE Review: Hash-o-Matic
On Monday, 2 October 2023 21:53:06 CEST Albert Astals Cid wrote: > > This method of review is really sub-optiomal. > > Who checked all those marks? There's no way to know. > > Was it someone expert in the area? > > Was it someone that knows has no idea what the checks mean? > > Or was it the submitter of review? If it's the submitter for review it's > worthless (nothing against Carl, you're great) but one doesn't review their > own MRs, so one shouldn't probably review this kind of checks either. I now unchecked all the checkmarks. For me I see these checkmarks as stuff I need to do before sending a mail to kde-core-devel, as it is just the basic stuff and it doesn't make sense to request a review if this is not done. Cheers, Carl
KDE Review: Hash-o-Matic
Hello, I started writting a small application to generate and compare files with their checksum two years. I piked it up again recently and I think this is now ready for a kde review. Features includes: - Generate checksum from a file - Compare two files - Verify a file with a given checksum - Verify a file with a given .sig file with GPG and show the signature info Here is the kde review checklist: https://invent.kde.org/utilities/hash-o-matic/-/issues/1 It would be great if someone could create a product on bugs.kde.org and assign myself to the product. Cheers, Carl
Re: Review of Codevis (ie - Making Codevis a KDE Project)
On Thursday, August 17, 2023 11:18:24 AM CEST Tomaz Canabrava wrote: > Hello Fellow KDE Devs, > > I'm here, formally asking for a review of the Codevis project, to move > forward and make it a part of kdesdk. Very cool project, I was amazed by the presentation of it from tarcisio at Akademy. > Currently we are using parts of KWdigetsAddons as a submodule > Most things that are related to buildsystems will be moved to craft / > kdesrc-build as soon as possible, right now we rely in conan for windows > and mac, plus a hand-written build script that downloads and builds llvm > for those platforms. > > Things that I know that are out of KDE Accordance: > - Translation System (uses Qt's tr() system) This isn't an issue and we have other KDE projects using the tr() system. But if you want to port to ki18n, it's best to do it now since you don't seems to have any translations yet. > - Settings System (it uses my own configuration parser that resembles QML) Yeah probably best to use kconfigxt or make your configuration parser part of kconfigxt next gen ;) > - Folder naming specification (follows the lakosian naming specification) I don't think we have any folder (and file) naming specification in kde, or at least if we have one, it varies a lot between projects. > - CI used is based on Gitlab, but fails on KDE When trying to build it on my laptop it failed, due to the requirement of clang 16. This might also be an issue with the kde ci on tumbleweed. > The current repository of Codevis is: > https://invent.kde.org/tcanabrava/codevis > > The KDE developers on this project are me, tarcisio fischer (that presented > Codevis on Akademy), and Richard Dale. > > Best regards, > Tomaz signature.asc Description: This is a digitally signed message part.
KDE Review: Francis
Hi, I would like to move Francies to KDE Review. Francis is a pomodoro app. Pomodoro is a well know technique to help you get more productive. The app itself is quite simple and was developed by Felipe, which not longer contribute to KDE. Since the app was basically finished, I found it sad to let it languish, so I polished it a bit, merged the pending merge requests and added support for more platforms to bring it up to our standards. It is a ncie showcase of Kirigami and how easy it is to build simple apps with it. If you have some comments, please leave then here: https://invent.kde.org/utilities/francis/-/issues/1 If someone could create a bug entry in bugzilla and add myself as default assigne, this would be great. Cheers, Carl signature.asc Description: This is a digitally signed message part.
KDE Review: mimetreeparser
Hello,
I would like to move MimeTreeParser to KDE Review. I created an issue for
tracking this here: https://invent.kde.org/pim/mimetreeparser/-/issues/1
The code is a fork of the mimetreeparser from Merkuro, which is in itself a
fork of the internal library from Sink/Kube, which is in itself a fork of the
mimetreeparser from KMail/Messagelib.
MimeTreeParser is split in a Core/Widgets/Quick component making possible to
use it various KDE apps. My immediate uses is in Merkuro Mail (QtQuick) and
Kleopatra (QtWidgets) to view encrypted emails, but in the future it would be
great if more of our mail related projects would use it, as the MimeTreeParser
contains a lot of complex code that we should try to avoid duplicating.
The code only rely on KMime, so it can be used with Akonadi, Sink or any other
technology.
There is two examples built with the app, so you can play with it by running
them:
./build/bin/mimetreeparser-widgets mail.{mbox,asc}
./build/bin/mimetreeparser-qml mail.{mbox,asc}
Just note that it doesn't support everything yet, in particular html email
which is relies on QtWebEngine is not enabled in the demo and the
mimetreeparser will prefer displaying the plain text alternative.
Cheers,
Carl
Re: KDE Review: Arianna
Le dimanche 26 février 2023 à 4:53 AM, Kevin Kofler a écrit : > Carl Schwan wrote: > > > I want to move Arianna to KDE review. Arianna is an ebook reader > > currently only supporting epubs. This is based on top of epub.js > > and QtWebEngine for the actualy rendering of ebooks as doing that > > from scratch in Qt would be too much work. > > > Okular has an EPub backend using libepub and QTextDocument. How does > Arianna compare to that? I would expect native code to be more efficient > than JavaScript especially on mobile devices, which are apparently > Arianna's main target. But I do not know whether there are, e.g., EPub > documents that Arianna can render and Okular cannot, so that is why I am > asking how they compare. Okular QTextDocument is quite inefficient see for example this long standing bug: https://bugs.kde.org/show_bug.cgi?id=359932 Aside from being quite inefficient, QTextDocument has only some basic HTML support and to have a good support of Epubs you basically need a much better HTML/CSS support which only a web engine can provide. If someone wants to try to optimize the native code of Okular, they should probably replace the old C and unmaintained based libepub library and replace it with [1] and [2] which should provide a better starting point. (and nope, I'm not gonna do it, I'm already too busy with other things). Carl [1]: https://invent.kde.org/graphics/arianna/-/blob/master/src/epubcontainer.cpp [2]: https://github.com/sandsmark/epubreader/blob/master/epubdocument.cpp
KDE Review: Arianna
Hi folks, I want to move Arianna to KDE review. Arianna is an ebook reader currently only supporting epubs. This is based on top of epub.js and QtWebEngine for the actualy rendering of ebooks as doing that from scratch in Qt would be too much work. The repo can be found here: https://invent.kde.org/graphics/arianna/ I create a gitlab issue to track the progress of this: https://invent.kde.org/graphics/arianna/-/issues/1 Please free to add your comments as recently suggested in this mailing list. Cheers, Carl
Re : New repo in kdereview: PlasmaTube
Le samedi 4 février 2023 à 7:14 PM, Devin a écrit : > Hi everyone, > > I would like to put PlasmaTube through kdereview: > > https://invent.kde.org/multimedia/plasmatube > > PlasmaTube is a YouTube client for both mobile and desktop. It has already been almost 3 weeks since Devin put plasmatube in kdereview. Does anyone have more feedback for Plasmatube? Any last objections before moving it out of kde review? :p Cheers, Carl > > Thanks, > Devin
Re: Tokodon in KDE Review
On mardi 29 novembre 2022 à 12:28 AM, Albert Astals Cid wrote:
> El dijous, 24 de novembre de 2022, a les 15:00:44 (CET), Carl Schwan va
> escriure:
>
> > Hello everyone,
> >
> > I would like to put Tokodon in KDE Review. Tokodon is mastodon client, I
> > have been working for some time already. I already did some unstable
> > release and I would like to soon release the first stable release. The
> > source code is available here: https://invent.kde.org/network/tokodon/
> >
> > It is still missing a lot of Mastodon features (lists, support for custom
> > emojies, displaying and sending polls, ...) but the current feature sets
> > make it usable already. And I am slowly adding more features.
> >
> > Cheers,
> > Carl
> >
> > PS: if someone has insight about this crash deep in the QML engine, I would
> > be welcome some help https://bugs.kde.org/show_bug.cgi?id=461882
>
>
> Crashes
>
> $ tokodon
> Loading any accounts from settings.
> qrc:/content/ui/main.qml:74: TypeError: Cannot read property 'instanceName' of
> null
> Violació de segment (s'ha bolcat la memòria)
>
> Backtrace https://pst.klgrth.io/paste/s87zy
>
> You can see that if you add
> onCheckedChanged: console.log("BLO", checked);
> to notificationAction it will switch infinitely from true to false and and
> crash.
Thanks for the very helpful pointer and to Antonio for testing the fix,
this has now been fixed with
https://invent.kde.org/network/tokodon/-/merge_requests/69
Cheers,
Carl
>
> Cheers,
> Albert
Re: Tokodon in KDE Review
On mardi 29 novembre 2022 à 9:23 AM, Christophe Giboudeaux
wrote:
> Hello,
>
> On jeudi 24 novembre 2022 15:00:44 CET Carl Schwan wrote:
>
> > Hello everyone,
> >
> > I would like to put Tokodon in KDE Review. Tokodon is mastodon client, I
> > have been working for some time already. I already did some unstable
> > release and I would like to soon release the first stable release. The
> > source code is available here: https://invent.kde.org/network/tokodon/
>
>
> The access token is leaked (along with a qdebug leftover):
> 8:53:15 - tokodon(11616) - unknown: XXX
> 8:53:15 - tokodon(11616) - unknown: [WEBSOCKET] Connecting to QUrl("wss://
> framapiaf.org/api/v1/streaming?access_token=p9M... [redacted] =user
Fixed and I also added a qdebug message handler in
src/messagefiltercontainer.cpp
to filter any secret token from the logs.
>
> tokodon currently crashes on startup, but the last time I tried, the
> spellchecking settings were not saved.
Spellchecking seems to be saved for me but I probably fixed it accidentally
a few weeks ago when porting to the MobileForm components.
Regarding the crash on startup, this might fix it:
https://invent.kde.org/network/tokodon/-/merge_requests/69
Unfortunately I still can't reproduce the bug, so I if you could test the MR
and tell me if this still crashes, I would be grateful.
Cheers,
Carl
>
> Christophe
>
Re: Tokodon in KDE Review
On jeudi 24 novembre 2022 à 4:19 PM, Tobias Fella wrote: > Hi, > > - Reuse lint is almost happy, would be nice to complete that and have it in > the CI > > - As reported in 461846, some icons aren't visible Should be fixed now too :) > - The "Global" view doesn't open for me and complains > > qrc:/content/ui/main.qml:162: ReferenceError: TimelineType is not defined > > Other than that it works well :) > > Cheers, > > Tobias > > On 11/24/22 15:00, Carl Schwan wrote: > >> Hello everyone, >> >> I would like to put Tokodon in KDE Review. Tokodon is mastodon client, I have >> been working for some time already. I already did some unstable release and I >> would like to soon release the first stable release. The source code >> is available here: >> https://invent.kde.org/network/tokodon/ >> It is still missing a lot of Mastodon features (lists, support for custom >> emojies, >> displaying and sending polls, ...) but the current feature sets make it >> usable >> already. And I am slowly adding more features. >> >> Cheers, >> Carl >> >> PS: if someone has insight about this crash deep in the QML engine, I would >> be >> welcome some help >> https://bugs.kde.org/show_bug.cgi?id=461882
Re: Tokodon in KDE Review
Le jeudi 24 novembre 2022 à 4:19 PM, Tobias Fella a écrit : > Hi, > > - Reuse lint is almost happy, would be nice to complete that and have it in > the CI Done :) > > - As reported in 461846, some icons aren't visible I can't reproduce :( the missing icons are in the qrc file, could you check with gammaray if you can find them in the resources tab? > - The "Global" view doesn't open for me and complains > > qrc:/content/ui/main.qml:162: ReferenceError: TimelineType is not defined Done :) This was caused by a recent refactor > > Other than that it works well :) Thanks :) Cheers, Carl > > Cheers, > > Tobias > > > > On 11/24/22 15:00, Carl Schwan wrote: > > > Hello everyone, > > > > I would like to put Tokodon in KDE Review. Tokodon is mastodon client, I > > have > > been working for some time already. I already did some unstable release and > > I > > would like to soon release the first stable release. The source code > > is available here: https://invent.kde.org/network/tokodon/ > > > > It is still missing a lot of Mastodon features (lists, support for custom > > emojies, > > displaying and sending polls, ...) but the current feature sets make it > > usable > > already. And I am slowly adding more features. > > > > Cheers, > > Carl > > > > PS: if someone has insight about this crash deep in the QML engine, I would > > be > > welcome some help https://bugs.kde.org/show_bug.cgi?id=461882
Tokodon in KDE Review
Hello everyone, I would like to put Tokodon in KDE Review. Tokodon is mastodon client, I have been working for some time already. I already did some unstable release and I would like to soon release the first stable release. The source code is available here: https://invent.kde.org/network/tokodon/ It is still missing a lot of Mastodon features (lists, support for custom emojies, displaying and sending polls, ...) but the current feature sets make it usable already. And I am slowly adding more features. Cheers, Carl PS: if someone has insight about this crash deep in the QML engine, I would be welcome some help https://bugs.kde.org/show_bug.cgi?id=461882
Re: New repo in kdereview: KWeather
Hi, You are missing kirigami-addons and yes this should be marked in the cmakelists.txt file. Cheers, Carl Original Message On Nov 12, 2022, 20:14, Jeremy Whiting wrote: > Looks like it's got a runtime dependency on kirigami (Maybe that's expected > for plasma-mobile, not sure) > > Built it on laptop and got this from cmake: > > cmake .. > -- The C compiler identification is GNU 12.2.0 > -- The CXX compiler identification is GNU 12.2.0 > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working C compiler: /usr/bin/cc - skipped > -- Detecting C compile features > -- Detecting C compile features - done > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/c++ - skipped > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Found Python3: /usr/bin/python3.10 (found version "3.10.8") found > components: Interpreter > -- Could NOT find ReuseTool (missing: REUSETOOL_EXECUTABLE) > CMake Warning at /usr/share/ECM/modules/ECMCheckOutboundLicense.cmake:86 > (message): > Reuse tool not found, skipping test generation > Call Stack (most recent call first): > CMakeLists.txt:30 (include) > > -- Skipping execution of outbound license tests. > -- Installing in the same prefix as Qt, adopting their path scheme. > -- Setting build type to 'Debug' as none was specified. > -- Looking for __GLIBC__ > -- Looking for __GLIBC__ - found > -- Performing Test _OFFT_IS_64BIT > -- Performing Test _OFFT_IS_64BIT - Success > -- Performing Test HAVE_DATE_TIME > -- Performing Test HAVE_DATE_TIME - Success > -- Found KF5Config: /usr/lib64/cmake/KF5Config/KF5ConfigConfig.cmake (found > version "5.99.0") > -- Found KF5Kirigami2: /usr/lib64/cmake/KF5Kirigami2/KF5Kirigami2Config.cmake > (found version "5.99.0") > -- Found Gettext: /usr/bin/msgmerge (found version "0.21.1") > -- Found KF5I18n: /usr/lib64/cmake/KF5I18n/KF5I18nConfig.cmake (found version > "5.99.0") > -- Found KF5CoreAddons: > /usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake (found version > "5.99.0") > -- Found KF5Notifications: > /usr/lib64/cmake/KF5Notifications/KF5NotificationsConfig.cmake (found version > "5.99.0") > -- Found KF5: success (found suitable version "5.99.0", minimum required is > "5.90.0") found components: Config Kirigami2 I18n CoreAddons Notifications > -- Found X11: /usr/include > -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so > -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - found > -- Looking for gethostbyname > -- Looking for gethostbyname - found > -- Looking for connect > -- Looking for connect - found > -- Looking for remove > -- Looking for remove - found > -- Looking for shmat > -- Looking for shmat - found > -- Looking for IceConnectionNumber in ICE > -- Looking for IceConnectionNumber in ICE - found > -- Found KF5Plasma: /usr/lib64/cmake/KF5Plasma/KF5PlasmaConfig.cmake (found > version "5.99.0") > -- Found KF5: success (found suitable version "5.99.0", minimum required is > "5.90.0") found components: Plasma > -- Found org.kde.kholidays-QMLModule: TRUE (found version "") > -- The following RUNTIME packages have been found: > > * org.kde.kholidays-QMLModule, QML module 'org.kde.kholidays' is a runtime > dependency. > > -- The following OPTIONAL packages have been found: > > * Python3 > Required to run tests of module ECMCheckOutboundLicense > * Qt5QuickCompiler > * KF5Package (required version >= 5.99.0) > * KF5Service (required version >= 5.99.0) > * Freetype > * PkgConfig > * Fontconfig > > -- The following REQUIRED packages have been found: > > * ECM (required version >= 5.90.0) > * Qt5Network (required version >= 5.15.7) > * Qt5QmlModels (required version >= 5.15.7) > * Qt5Quick > * Qt5Test > * Qt5Svg > * Qt5QuickControls2 > * Qt5Charts > * KF5Kirigami2 (required version >= 5.90.0) > * Gettext > * KF5I18n (required version >= 5.90.0) > * KF5Notifications (required version >= 5.90.0) > * KF5KWeatherCore (required version >= 0.6.0) > * KF5CoreAddons (required version >= 5.99.0) > * Qt5Gui (required version >= 5.15.2) > * Qt5Widgets (required version >= 5.15.2) > * KF5Plasma (required version >= 5.90.0) > * KF5 (required version >= 5.90.0) > * Qt5Qml > * Qt5Core > * Qt5 > > -- The following features have been disabled: > > * SPDX_LICENSE_TESTING, Automatic license testing based on SPDX definitions > (requires reuse tool) > > -- The following OPTIONAL packages have not been found: > > * ReuseTool > Required to run tests of module ECMCheckOutboundLicense > > -- Configuring done > -- Generating done > -- Build files have been written to: > /home/jeremy/data/devel/kde/src/kde/plasma-mobile/kweather/build > > then it built and installed fine, but trying to run failed with this: > > kweather > QQmlApplicationEngine failed to load component > qrc:/qml/main.qml:163:26: Type SettingsDialog unavailable >
Re: ghostwriter is ready for your review
Le mardi 1 novembre 2022 à 11:27 AM, Albert Astals Cid a écrit : > El dijous, 13 d’octubre de 2022, a les 8:52:26 (CET), Megan va escriure: > > > Hello everyone, > > > > The /ghostwriter/ Markdown editor has finally hatched from its > > incubation and is ready for you to review at your convenience. > > > > Project repo: https://invent.kde.org/office/ghostwriter > > > > Project website: https://ghostwriter.kde.org > > > > Note: ghostwriter currently uses QtLinguist for translations. However, I > > plan to transition it to ki18n as soon as I can. Any help you can > > provide would be appreciated, of course! > > > I've just realized the man page is not translatable. > > See https://invent.kde.org/multimedia/dragon/-/tree/master/doc how to make a > manpage using docbook so its translatable. Done with https://invent.kde.org/office/ghostwriter/-/merge_requests/14/diffs Cheers, Carl > > Cheers, > Albert > > > Thanks so much! > > > > Megan > > > >
Re : Re: Kirigami Addons in KDEReview
Le samedi 28 mai 2022 à 4:56 PM, Sandro Knauß a écrit : > Hey, Hi, Sorry about dropping the ball on this KDE review request. I was more interested at that time mostly the treeview luging and not so much about the time and date module and my interest in fixing the issues there was not great. Like you said the time picker improved a bit since the issue was brought up, so let's move this project back to KDE Review and wait 2 weeks. It would help us in Kalendar, since we are currently vendoring the tree view plugin and have a duplication of the date picker. Additionally to the two MRs pointed out, there were also a few more improvements: - The TreeView is not working with RTL layouts and has better keyboard navigation - The project is now fully 'reuse' compliant Cheers, Carl > any news for kirigami-addons getting out of review? I strongly vote for > getting it out of review or at least release a new 0.3. > > So far I can tell master has a lot improved Date picker, that at least for my > usage ( laptop with mouse) I could now use ktrip to select a date and time > yeah. > > It is a bit of a pitty, that there is software based on kirigami-addons > release ( ktrip and initarary). That currently has no useful time/date picker, > when you don't build from master branch. I tested that on my librem 5 with > postmasker OS, as they ship kirigami-addons v0.2 and I wanted to use ktrip and > had no possibility to change the time... > > > I would like to see > > https://invent.kde.org/libraries/kirigami-addons/-/issues/2 fixed first > > as the date picker is sort of almost unusable right now. > > > I can understand, that releasing a not really useful timepicker is not nice - > but than at least to regular unstable releases. And there is a lot of > improvments since 0.2. Some highlights: > > https://invent.kde.org/libraries/kirigami-addons/-/merge_requests/20 > https://invent.kde.org/libraries/kirigami-addons/-/merge_requests/27 > > regards, > > hefee > > -- > Mein öffentlicher Schlüssel / My public key: E68031D299A6527C > Fingerabdruck / Fingerprint: > D256 4951 1272 8840 BB5E 99F2 E680 31D2 99A6 527C > runterladen/download: > https://keys.openpgp.org/vks/v1/by-fingerprint/ > D256495112728840BB5E99F2E68031D299A6527C
Re: New repo in kdereview: kclock
Le lundi 18 octobre 2021 à 2:29 PM, Jonathan Riddell a écrit : > I still don't see any attempt to get kirigami-addons through kdereview and > make a stable release (making a tag in invent isn't the same as making a > stable release). Does anyone feel able to take enough ownership of it to do > that? Else kclock and others will be forever stuck. It's also a problem for KDE Itineray, Plasma System Monitor and Kalendar since the three projects vendors some parts of kirigami addons. There was an attempt by me some time ago to move it through kdereview. This has been a bit stalled due to some lack of time and motivation from my side, sorry :/ Fortunately with Kalendar also depending on Kirigami Addons too, there was a bit of work that was done recently. * Missing is REUSE compliance: https://invent.kde.org/libraries/kirigami-addons/-/merge_requests/13 I pinged David Ed in the issues and in #plasma last week but will try again tonight :) * Hanyoung is working on a better time picker: https://invent.kde.org/libraries/kirigami-addons/-/merge_requests/17 Currently blocked by AM/PM vs 24hours format * And Clau is working on a better date picker: https://invent.kde.org/libraries/kirigami-addons/-/merge_requests/20 (upstreaming the modification from Kalendar) Help is welcome for doing reviews :) Cheers, Carl > > Jonathan > > On Fri, 5 Mar 2021 at 02:04, hanyoung wrote: > > > Hello everyone! > > > > I want to move kclock to kdereview. > > > > https://invent.kde.org/plasma-mobile/kclock > > > > KClock is the alarm/clock app for Plasma Mobile. It consists of two parts, > > daemon and the client. The daemon communicates with powerdevil to register > > alarms, and provide DBus interface to interact with the client. > > > > Besides the daemon and the client, some plasmoids also included in the > > repo, although only one is enabled so far. > > > > Regards, > > > > Han
Re: New repo in kdereview: kasts
Le jeudi, mai 27, 2021 11:05 PM, Albert Astals Cid a écrit : > El dijous, 27 de maig de 2021, a les 12:20:20 (CEST), Bart De Vries va > escriure: > > > Hello everyone! > > I would like to move kasts to kdereview. > > https://invent.kde.org/plasma-mobile/kasts > > https://invent.kde.org/plasma-mobile/kclock > > Kasts is a podcast app for Plasma Mobile. It was started as a fork of > > Alligator, the Plasma Mobile feed reader. It currently features a play > > queue, play position resume/persistence, MPRIS2 support, and suspend > > inhibition. > > The left bar is super confusing on the desktop, the 4 first elements are > "toggles" but Settings and About are not, so if you do About, Settings, > About, Settings, About, Settings, About, Settings, Download. > > You don't end up in Download, you're still in Settings, and what's worse, now > you have to press back like 10 times to remove all those About and Settings > pages that are on the stack. > > Import podcast defaulting to Planet KDE is a bit weird? > > text: (!isQueue && entry.queueStatus ? "· " : "") + > entry.updated.toLocaleDateString(Qt.locale(), Locale.NarrowFormat) + > (entry.enclosure ? ( entry.enclosure.size !== 0 ? " · " + > Math.floor(entry.enclosure.size / (1024 * 1024)) + "MB" : "") : "" ) > > is a huge text puzzle that needs to be an i18nc call (or many if needed) so > translators can rearrange things in the order that make sense in their > language + translate MB That should probably use KFormat instead because it already handles the i18n stuff and will also use the correct size units for bigger/smaller downloads size. > Cheers, > Albert > > > Kind regards, > > Bart De Vries
Re: New repo in kdereview: kalk
You probably want to look at https://doc.qt.io/qt-5/qlocale.html#toFloat for converting the numbers from strings to floats. This also probably means that you need to tell Flex to consider 1.000,000 as a single token and find a way to convert it as a float before giving it to Bison. I hope this help, it's a while I didn't use Flex (and I never used Bison). Cheers, Carl Le mardi, mai 4, 2021 7:00 PM, hanyoung a écrit : > Flex doesn't take care of separators, MPFR and GMP do. Flex is merely > scanning for numbers and operators to pass to Bison. > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, May 5, 2021 12:56 AM, Thomas Baumgart t...@net-bembel.de wrote: > > > Han, > > On Dienstag, 4. Mai 2021 11:36:04 CEST hanyoung wrote: > > > > > Pushed an inelegant solution - include "," as decimal separator in flex. > > > As long as there aren't any more decimal separator we're cool. > > > > Not sure if this appropriate, but I wanted to warn you about the dilemma > > that in some locale the thousand separator and the decimal symbol are > > exactly the opposite. Example: > > German locale: 1.000,00 -> one thousand > > US locale : 1,000.00 -> one thousand > > So simply treating the comma and the dot alike without taking the locale > > into account may result in wrong values. > > Cheers, > > Thomas > > > > > ‐‐‐ Original Message ‐‐‐ > > > On Tuesday, May 4, 2021 6:54 AM, Albert Astals Cid aa...@kde.org wrote: > > > > > > > Added a failing test > > > > athttps://invent.kde.org/plasma-mobile/kalk/-/merge_requests/22 > > > > Now you have to make it work :) > > > > Cheers, > > > > Albert > > > > -- > > Regards > > Thomas Baumgart > > https://www.signal.org/ Signal, the better WhatsApp > > > > Of all the computing resources available, the most valuable one is > > programmers' time. Especially in open source where most of us have to > > sneak in time to write and debug code. (Ace Jones)
Re: Koko in KDEReview
Le mardi, mai 4, 2021 4:53 PM, Adriaan de Groot a écrit : > On Tuesday, 4 May 2021 15:50:27 CEST Halla Rempt wrote: > > > On Tuesday, 4 May 2021 15:28:30 CEST Nate Graham wrote: > > > > > I don't see anyone really trying to argue otherwise. > > > > I have certainly made that argument many times. Since only developers can > > add tags, it will be impossible for ordinary users to provide enough > > information to classify the bug. Tagging systems suck big-time. Looking it > > GIMP's gitlab issues shows that not even the OS is reliably tagged! > > What Halla said. Every time we have this conversation, Krita is the special > case, because it is a special case -- many many users, diverse platforms, > non-technical bug-reports. We must not discount Krita's experiences and needs > -- conversely not ignore the needs of some obscure edge-case tool that is only > going to get FreeBSD sysadmins to file bug reports (which might be fine in > GitLab issues, because there's only ever 3 users). If Bugzilla was working so well for Krita, I'm wondering why they are redirecting their users to write their bug reports first in an external tool (krita-artists.org) instead of Bugzilla. > Any migration has to be able to handle huge numbers of issues, and also > provide maintainers tools to manage them, and to handle the diversity of issue > meta-data that bugzilla handles. > > To move this conversation forward, we'd need a concrete example of "these are > the tools used to manage issue lifecycle, similar to how bugs lifecycle in > bugzilla works". I know Harald has built tools and views and things to help > out there, but we do need a .. well, a concrete proposal for how things would > work. Currently, the extra tooling we maintain for closing bugs and adding comments in Bugzilla when an MR is opened is currently natively supported by GitLab. For bug triagging, there is also a very helpful tool made by GitLab: https://gitlab.com/gitlab-org/gitlab-triage This tool allows for example to add special labels when an issue/MR, older than a few days, didn't get any comments yet or adding automatically OS labels when Windows/Arch/FreeBSD is mentioned in the issue. Also, it's important to note that different teams have different needs and finding a tool that fits everyone will be very difficult. For example in NeoChat, I have special needs like asking the bug reporter to add some information about the matrix instance used, the libQuotient version used, ... and for that, I need a special bug reports template. Something that Bugzilla doesn't provide and without it, the bugs report are in many cases worthless. I really don't think forcing every KDE project to use Bugzilla is a good idea. As long as it uses KDE infra it should be fine (compliance with our manifesto). Some documentation website aren't using docs.kde.org but their own tooling (e.g. docs.krita.org, docs.plasma-mobile.org, ...), should we also force them to use docs.kde.org? Should we force every project to use forum.kde.org? > That it's possible to manage a gazillion issues in GitLab (maybe EE > features, though) can be seen by looking at https://gitlab.com/gitlab-org/ > gitlab/-/issues GitLab issues in GitLab: there's 37 thousand of them, but > there's also 78 pages of labels at https://gitlab.com/gitlab-org/gitlab/-/ > labels to pick from. I suspect there's a non-0 amount of FTE's doing bug- > labeling -- can we afford that? > > [ade]
Re: Koko in KDEReview
Le mardi, mai 4, 2021 12:21 AM, Albert Astals Cid a écrit : > El dimarts, 4 de maig de 2021, a les 0:07:19 (CEST), Carl Schwan va escriure: > > > Le lundi, mai 3, 2021 4:35 PM, Harald Sitter sit...@kde.org a écrit : > > > > > On 23.04.21 01:00, Carl Schwan wrote: > > > > > > > > > > > - 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. > > > > > > > > > > Did I miss something? The last agreement I recall was that we are > > > > > using > > > > > bugzilla for bugs and gitlab for tasks for the time being. If even as > > > > > developer I have to go hunting where $project tracks their bugs I'm > > > > > sure > > > > > not going to be a happy camper. > > > > > > > > > > > Also we don't use KCrash. > > > > > > > > > > Shouldn't you? > > > > > > > > The problem is that DrKonqi doesn't really work on Plasma Mobile and I > > > > don't think > > > > this justify getting locked up in using Bugzilla. If having a bugzilla > > > > product > > > > is really required, we can request one but I can't guarantee that I > > > > will look at it > > > > more often than I look at the kde-www bug reports in bugzilla (every 6 > > > > months). > > > > > > Let's consider it required then. > > > If you don't care about crash reports that's your choice I guess, but it > > > does kinda call into question the product quality since you also don't > > > have an alternative system to the kcrash-drkonqi-bugzilla caravan. Quite > > > clearly koko would have benefited from crash tracking and since the only > > > solution we presently have for that is the aforementioned stack it quite > > > clearly also would have benefited from being on bugzilla to receive > > > those crash reports and potentially move to other products if the crash > > > is not in koko. After all, crashes get submitted to the product that > > > crashed, not the library of the top most frame. > > > I have to be honest, it is a bit surreal to even have to argue this. I > > > get thorough enjoyment out of throwing tomatoes at the current system > > > but to actively pretend that the problem-domain of crashing software > > > doesn't exist so you don't have to look at bugzilla sure as heck doesn't > > > solve anything. In particular since you pitched koko as convergent and > > > useful on the desktop. > > > If all that's stopping you from embracing crash tracking is drkonqi then > > > I am happy to tell you that sticking a mobile-suitable UI on top > > > shouldn't be all that difficult ;) > > > > Would you be open to an MR adding GitLab support to DrKonqi? > > We don't use gitlab for user bug reports. Do you have a link to the policy? I looked into https://community.kde.org/Policies and I found nothing. https://manifesto.kde.org/commitments.html says that we should only use online service hosted by KDE, but as far I know invent is hosted by KDE. Also considering that bugzilla is almost unmaintained, that should be something to reconsider if there is really such policy. For info, the Bugzilla UX initiative died when the lead developer was fired by Mozilla. And the Harmony project which is trying to bring back the improvements from BMO (the Mozilla internal fork) is progressing at an abysmal pace. Bugzilla itself had its last code contribution one year ago. Cheers, Carl > > Cheers, > Albert > > > > HS
Re: Koko in KDEReview
Le lundi, mai 3, 2021 4:35 PM, Harald Sitter a écrit : > On 23.04.21 01:00, Carl Schwan wrote: > > > > > > > - 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. > > > > > > Did I miss something? The last agreement I recall was that we are using > > > bugzilla for bugs and gitlab for tasks for the time being. If even as > > > developer I have to go hunting where $project tracks their bugs I'm sure > > > not going to be a happy camper. > > > > > > > Also we don't use KCrash. > > > > > > Shouldn't you? > > > > The problem is that DrKonqi doesn't really work on Plasma Mobile and I > > don't think > > this justify getting locked up in using Bugzilla. If having a bugzilla > > product > > is really required, we can request one but I can't guarantee that I will > > look at it > > more often than I look at the kde-www bug reports in bugzilla (every 6 > > months). > > Let's consider it required then. > > If you don't care about crash reports that's your choice I guess, but it > does kinda call into question the product quality since you also don't > have an alternative system to the kcrash-drkonqi-bugzilla caravan. Quite > clearly koko would have benefited from crash tracking and since the only > solution we presently have for that is the aforementioned stack it quite > clearly also would have benefited from being on bugzilla to receive > those crash reports and potentially move to other products if the crash > is not in koko. After all, crashes get submitted to the product that > crashed, not the library of the top most frame. > > I have to be honest, it is a bit surreal to even have to argue this. I > get thorough enjoyment out of throwing tomatoes at the current system > but to actively pretend that the problem-domain of crashing software > doesn't exist so you don't have to look at bugzilla sure as heck doesn't > solve anything. In particular since you pitched koko as convergent and > useful on the desktop. > > If all that's stopping you from embracing crash tracking is drkonqi then > I am happy to tell you that sticking a mobile-suitable UI on top > shouldn't be all that difficult ;) Would you be open to an MR adding GitLab support to DrKonqi? > HS
Kirigami Addons in KDEReview
Hello folks, I would like to put request a KDE review on the Kirigami Addons project. This repository contains for the moment 2 plugins: * A TreeView for QML: this is maintained by Marco and provides a QML tree view using KItemModels::KDescendantsProxyModel. A copy of this is already in use in the Plasma System Monitor. * A DateTime collections of elements: this is maintained by both me and David Edmundson and provides a date picker, a month view for calendars and a time picker. More plugins might be added in the future to allow to share basic visual components between kirigami applications without putting too much random stuff in Kirigami or adding dependencies to Kirigami. You can find a link to the repo here: https://invent.kde.org/libraries/kirigami-addons/ Regards Carl Schwan https://carlschwan.eu
Re: Koko in KDEReview
Le mardi, mars 23, 2021 1:31 PM, Harald Sitter a écrit:
> On 16.03.21 20:10, Carl Schwan wrote:
>
> > Le mardi, mars 16, 2021 12:55 PM, Harald Sitter sit...@kde.org 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.
>
> Did I miss something? The last agreement I recall was that we are using
> bugzilla for bugs and gitlab for tasks for the time being. If even as
> developer I have to go hunting where $project tracks their bugs I'm sure
> not going to be a happy camper.
>
> > Also we don't use KCrash.
>
> Shouldn't you?
>
> > > > 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.
>
> Still crashes when I move an image with geodata into the picture dir :(
>
> at ../src/reversegeocoder.cpp:151
I think I fixed it with
https://invent.kde.org/graphics/koko/-/commit/d2c51a814fcc1646003338d1dbcbfb1aa4126d3f
>
> > > 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.
>
> That's what [1] does.
> You register on kdbusservice register as org.kde.koko and connect to
> activateRequested so when the user clicks on an image while koko is
> already running that opening request is sent to the running instance
> instead of starting a completely new one.
Finally found the time to implement it:
https://invent.kde.org/graphics/koko/-/merge_requests/65/diffs :D
>
> > > - 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
> > >
> >
> > Could you take a look into `~/.local/share/koko/imageData.sqlite3` with
> > sqlitebrowser and tell me if the locations and image are correctly tagged?
> > Also try to remove `~/.local/share/koko/imageData.sqlite3` and
> > `~/.local/share/koko/fstracker.sqlite3`
> > after pulling the project new, this might have been caused by the racing
> > code from above.
>
> Works after I wiped config and data to start with a fresh set of data
> :shrug:
>
> HS
Le mardi, mars 23, 2021 1:31 PM, Harald Sitter
a écrit:
> On 16.03.21 20:10,
Re: KQuickImageEditor in KDEReview
Le jeudi, mars 25, 2021 4:47 PM, Harald Sitter a écrit :
> - really close to 100% reuse cover. plz consider adding data to
> KQuickImageEditorConfig.cmake.in and src/controls/plugins.qmltypes
>
> - in fact... shouldn't the qmltypes file be generated at build time?
> - there's commented out KDEFrameworkCompilerSettings in CMakeLists,
> please remove it, Friedrich asked us to not use it outside frameworks
> and having it commented out only tempts people into using it ;)
>
> - as with koko, it might make sense to bump the kf5 requirement to
> 5.79 and use clang format+hooks. there are some stilistic
> inconsistency within the code already
>
> - you should consider adding an option() definition for the
> BUILD_SHARED_LIBS variable so it is documented and expicitly
> initialized to a default value, I guess
>
> - ResizeRectangle has raw pointers that aren't initialized to nullptr by
> default
> - resizerectangle.cpp includes moc_resizerectangle.cpp is there a
> reason for that? shouldn't automoc magic do this on its own?
>
> - same for resizehandle.cpp
>
> some typos in imagedocument.h:
> Mirrror
> horizonal (actually in mirrocommand.{h,cpp} as well)
> operation
Thanks for the review and sorry for the delay. I just made the changes :)
>
> HS
>
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: Koko in KDEReview
Le dimanche, mars 14, 2021 12:22 AM, Albert Astals Cid 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 Fixed https://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. > 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: KQuickImageEditor in KDEReview
Le samedi, mars 13, 2021 11:33 PM, Albert Astals Cid a écrit : > El dissabte, 13 de març de 2021, a les 23:10:11 CET, Carl Schwan va escriure: > > > Hello again, > > I putting KQuickImageEditor in KDEReview. KQuickImageEditor is a very > > simple image editor for QtQuick projects. It is designed to not depends > > on Kirigami (but a simple example that integrate in Kirigami application > > is provided in the source code). It doesn't have any translations in it > > and just focus on image manipulation. It's currently used by NeoChat, Pix > > and Koko and packaged in all the major distributions (Fedora, openSUSE, > > Arch, > > Neon). > > I currently advice against using it on your own project since I'm not > > completely happy with the current backend and will probably make change > > to the API. > > Am I understand this email correctly? > > It seems you say "please review this; I'll rewrite it shortly". > > Maybe we should wait to do the review after the rewrite? It seems that making KQuickImageEditor pass KDEReview is a requirement for Koko KDEReview process and since I want to have a stable release of Koko in the next Pinephone batch, I would really appreciate a review. Also just to clarify KQuickImageEditor currently works for simple image manipulation like rotation, cropping, mirroring an image. The problem is more that the current back-end limits the possibility of image editing to only these simple operations. This is enough to almost reach feature parity with Gwenview own image editor (that was my goal when I first started this project) but won't make it possible to apply filters and other cool effects that many except for an integrated image editor in chat applications on mobile for example. Cheers, Carl > Cheers, > Albert > > > Repo: https://invent.kde.org/libraries/kquickimageeditor/ > > Regards, > > Carl
KQuickImageEditor in KDEReview
Hello again, I putting KQuickImageEditor in KDEReview. KQuickImageEditor is a very simple image editor for QtQuick projects. It is designed to not depends on Kirigami (but a simple example that integrate in Kirigami application is provided in the source code). It doesn't have any translations in it and just focus on image manipulation. It's currently used by NeoChat, Pix and Koko and packaged in all the major distributions (Fedora, openSUSE, Arch, Neon). I currently advice against using it on your own project since I'm not completely happy with the current backend and will probably make change to the API. Repo: https://invent.kde.org/libraries/kquickimageeditor/ Regards, Carl
Koko in KDEReview
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 failed[1] 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) Cheers, Carl [1]: https://marc.info/?l=kde-core-devel=159177814907322=2
Re: Review of KGeoTag
You can change the metadata of your repository in repo-metadata[1] and make sure you send a mail to the translators mailing list and give them enough time to translate your application. See releasing software [2] Cheers, Carl [1]: https://invent.kde.org/sysadmin/repo-metadata [2]: https://community.kde.org/ReleasingSoftware Original Message On 27 Dec 2020, 2:18 PM, Tobias Leupold wrote: > Am Sonntag, 27. Dezember 2020, 00:21:14 CET schrieb Albert Astals Cid: >> El diumenge, 20 de desembre de 2020, a les 12:34:21 CET, Tobias Leupold va > escriure: >> > Dear core devs, >> > >> > is there anything left I can do so that KGeoTag can be moved to extragear/ >> > graphics? Thanks for supporting me and this project :-) >> >> I think no answer means you can assume everyone is happy :) >> > > This is nice :-) So KGeoTag can be moved? What di I have to do to request it? > Or can I even request it? ;-) > > I would tag a first release then soonish. > > Cheers, Tobias
Re: NeoChat in KDEReview
Le jeudi, novembre 19, 2020 11:27 PM, Carl Schwan a écrit : > Hello, > > Tobias and I have been working on a Matrix client using Kirigami, > named NeoChat. NeoChat is still missing a few features to become > a full-featured Matrix client (most notably encryption support and > video chat support), but it is starting to be good enough for > interacting with public rooms. It is using version 0.6 of > libQuotient and is a fork of the (abandoned) Spectral client. > > For the moment the feature supported are: > > - Sending messages > > - Sending files from clipboard and filesystem > > - Reply to message (right-click on a message to access menu) > > - Start a private chat (but not encrypted) > > - Show notifications, for the moment there is only a global switch > to disable it. We plan to implement the configuration part of the > specification soon. > > - Auto-completion of usernames in chat > > - Emoji picker > > - Basic room setting page > > - Send and accept invitations > > - /rainbow (very important) > > - /me > > - And more features are contently added > > We already support a nightly build for Flatpak and a quite > experimental Android build. > > The only external dependencies for NeoChat are libQuotient > (0.6.x branch) and cmark. > > Concerning the release plan, we want to release an initial > version to ship with the Pinephone KDE edition. And once with > are happy with the feature provided by NeoChat (e.g. encryption > support) we plan on moving it to the release service. > > We have an active Matrix room for discussion around NeoChat at > #neochat:kde.org. > > Thanks in advance for your review and helpful advice. > > Carl and Tobias > Hi, So NeoChat is now for more than 14 days in KDE Review. If there is no more objections, I will move it to extragear tomorrow. Since the start of KDE review, NeoChat gained a few more features and interface improvements: * Now display the date when a message was sent * Now show highlighted messages * Improved sidebar design (thanks to a design from manueljlin) * Add a simpler mode to the timeline (without displaying avatars) * Fixed login with chat.opendesktop.org * Created and fixed the bug with text wrapped text sent :p * Improved the support for multiple accounts * Notification improvement (clicking on them now open the room and then starting NeoChat you don't get spammed by notifications anymore) * Added a bit of KStandardShortcut support (btw it would be nice to expose them in an easy way to QML apps) * Improved auto-completion of usernames and emojis * Added simpler copy-pasting of images * Better autofocus of the chat text field * Better system tray integration * ... Also we gained a few contributors \o/ * Nate did a lot of QA * Aleix worked on the better system tray * Nero Burner worked on making the mobile version a bit better * Noah improved the setting page * Peter Eszlari made some changes to the AppStream metadata * Alexey Andreyev improved the username colors contrast on dark themes I wouldn't call NeoChat bug free and feature-complete yet but for I see myself using NeoChat more and more as a daily driver and only use Element as a backup now. Regards, Carl
Re: MauiKit and Index review
Le lundi, septembre 28, 2020 9:02 AM, Camilo Higuita Rodriguez a écrit : Hi, some feedback: Index looks visually really nice, great job on that front :) In term of technical review: * There are tons of clazy warning in your codebase: I fixed some of them in [1] but there are more of them. I would encourage you to look into setting up clazy, it provides tons of helpful advice. * https://invent.kde.org/maui/mauikit/-/blob/v1.2/src/platforms/linux/kdeconnect.cpp#L41 This won't work if I set LANGUAGE=fr_FR as my environment variable. Also I don't think it is a good idea to parse the command line output like this. You should probably ask the kdeconnect team if they can add machine-readable interface or a dbus API for your usecase. * https://invent.kde.org/maui/mauikit/-/blob/v1.2/src/utils/syncing/syncing.cpp#L198 This strings should be translated if they are visible to the user. * You are using qDebug in mauikit, you should probably use QLoggingCategory instead. Cheers, Carl [1]: https://invent.kde.org/maui/mauikit/-/merge_requests/25/diffs > Hi, > For the next stable release, we would like to go through KDE review first. > > To start I want to submit MauiKit and Index for review, and later on the > other apps. > https://invent.kde.org/maui/mauikit > https://invent.kde.org/maui/index > > The changes we have made to get to this review are all in the development > branch. > > I will be available to perform any needed fixes and answer any questions > since I'm the main developer and maintainer. > > Greetings, > Camilo Higuita >
Re: NeoChat in KDEReview
Le dimanche, novembre 22, 2020 9:16 PM, Adriaan de Groot a écrit : > Thanks Carl for chasing Albert's comments so quickly. Here's my review > comments on neochat 5316e32004fcfa60d72f373e2e55b44b8fecf2c7 (master HEAD as > of right now). > > On Sunday, 22 November 2020 12:40:16 CET Carl Schwan wrote: > > > Le samedi, novembre 21, 2020 1:26 AM, Albert Astals Cid aa...@kde.org a > > écrit : > > > > El dijous, 19 de novembre de 2020, a les 23:27:24 CET, Carl Schwan va > > escriure: > > > > > Tobias and I have been working on a Matrix client using Kirigami, > > > > named NeoChat. NeoChat is still missing a few features to become > > I'm going to admit that I'm using KDE Frameworks 5.75, rather than 5.76. For > Kirigami, where application use is now strongly steering development and > bugfixing, that might be a terrible choice. I've been told at least some bugs > are fixed in 5.76 already. > > That said: > > -1. Uses the Spectral icon in the About page and in the systray (only > confusing if Spectral is also around, and depending on your relationship with > Spectral, might be kind of rude). We have some propositions for icons, so the Spectral icon will go away before the first public release. Note that originally the plan was to incubate Spectral but because the community couldn't agree about anonymous contributions, the project was never incubated :( Today Black hat seems to have stopped maintaining Spectral and this is why NeoChat now exists. > 0. Emoji fonts continue to be an issue (a packaging issue, I'm sure -- noto > emoji and noto-extra or equivalents seem to be needed) . Yeah this is a packaging issue. This is a sad thing that in 2020 some distros still didn't have figured this problem. In my openSUSE install, I use this local font config: https://gist.github.com/IgnoredAmbience/7c99b6cf9a8b73c9312a71d1209d9bbb > > 1. Alongside the "write your message" there are three buttons. None of them > have tooltips. There's a smiley (for emoji), a paperclip (for > attachments) and > a lemon juicer. Is there ever, ever, any reason to click the lemon juicer? The lemon juicer is a "send message" button, nevertheless, we do need tooltips. /me is wondering why this icon was misunderstood has a lemon juicer icon. > 2. Clicking on the emoji button gets me an emoji picker -- with no tooltips, > and no way to get back to writing a text message. (I suspect this is > frameworks-version dependent, since the text block is also way too tall) Works, as expected in Kirigami 5.76, changing the dependencies, is not always a good idea ;) > > 3. In the upper-right of the chat pane, there's a round (it was square-ish > yesterday) button with an up-chevron in it. No tooltip. Clicking on it > does > nothing (I get an error message on stdout: searching for non-existent > event .. > which makes me think this goes back in history looking for mentions). > It'd be > nice to have it disabled when there's nothing it can do. The button should disappear once you have scrolled to 100% to the bottom of the room. There is definitely room for improvement in it. > 4. There's no way to resize or hide the list of channels. Most of the time > that's the least interesting thing on screen -- I just need a channel > avatar > and number of messages, not the full description of each channel. I could try to have a mode with only a list of avatars and not the name, but this will need a bit of UX work to determine how to toggle this mode. > > 5. The show-room-members pane doesn't have a tooltip, and doesn't highlight > like a button does (like the emoji button). This is something defined in Kirigami but since you and Albert complained about it, I guess this is something that could also need some improvements. There was in fact already some improvements in Kirigami because of the need for NeoChat. > > Usage scenarios: > > 6. Click on the text-field for writing messages. Type "derp". Notice flashing > text cursor in text-field. Click on the room-list. Text-cursor disappears > from > text-field. Type something: this doesn't appear anywhere. It doesn't > search > or filter the room list, nor does it go to the regular text input. > > Since there's a "search" field for rooms, I expect that typing things into > neochat goes to the-message-to-be-sent except if something explicitly > different is chosen. Quasselclient does this: click on the chats list and > start typing, and it re-sets focus to the message box. I need to investigate if this is possible in QML. QML always feels quite limited around keyboard navigation and focus. > 7. RMB "mark as read" on a room to clear the un
Re: NeoChat in KDEReview
Le samedi, novembre 21, 2020 1:26 AM, Albert Astals Cid a écrit : > El dijous, 19 de novembre de 2020, a les 23:27:24 CET, Carl Schwan va > escriure: > > > Hello, > > Tobias and I have been working on a Matrix client using Kirigami, > > named NeoChat. NeoChat is still missing a few features to become > > a full-featured Matrix client (most notably encryption support and > > video chat support), but it is starting to be good enough for > > interacting with public rooms. It is using version 0.6 of > > libQuotient and is a fork of the (abandoned) Spectral client. > > For the moment the feature supported are: > > > > - Sending messages > > - Sending files from clipboard and filesystem > > - Reply to message (right-click on a message to access menu) > > - Start a private chat (but not encrypted) > > - Show notifications, for the moment there is only a global switch > > to disable it. We plan to implement the configuration part of the > > specification soon. > > > > - Auto-completion of usernames in chat > > - Emoji picker > > - Basic room setting page > > - Send and accept invitations > > - /rainbow (very important) > > - /me > > - And more features are contently added > > > > We already support a nightly build for Flatpak and a quite > > experimental Android build. > > The only external dependencies for NeoChat are libQuotient > > (0.6.x branch) and cmark. > > Concerning the release plan, we want to release an initial > > version to ship with the Pinephone KDE edition. And once with > > are happy with the feature provided by NeoChat (e.g. encryption > > support) we plan on moving it to the release service. > > We have an active Matrix room for discussion around NeoChat at > > #neochat:kde.org. > > Thanks in advance for your review and helpful advice. > > Nitpick (just at the beginning because it's the first thing i faced when > trying to compile): It would be nicer if you would use the feature_summary > better, i.e. don't mark things required in the find_package level but on the > set_package_properties level. so i get a nice summary with all the things i'm > missing the first time i try instead of having to run cmake N times until i > install everything. > > I tried to login to https://webchat.kde.org (which doesn't seem to be the > correct url i have to use i guess) and i got "no feedback at all" that things > were failing. I can even press the Login more times in what seems to be > spawning more connection attempts. I've since learnt that > https://kde.modular.im is the correct url to use. > > I tried to login to https://matrix.org and then got a notification that > something was wrong (i was using kde's server credentials) but the > notification went away before i could read it. Seems not a very nice UI to > hide important error messages before i can read them. > > If i use "https://kde.modular.im " (<- notice the space at the end) as server > to connect to, nothing happens, no error, no nothing, either automatically > remove trailing spaces or at least tell me "you stupid user fix your url" > > The chat window uses the wrong background colors, gray is not the background > color my theme uses for text areas, it's white. > > "Room setting" in the sidebar should be "Room settings"? > > If i'm in a channel and press settings, then accounts, then explore rooms, it > think it makes no sense UI wise that the top bar < doesn't bring me directly > to the channel and instead has me go to accounts and settings first. > > If i'm in about neochat, i don't think the top bar should still have the > "open this channel sidebar" on top right, i'm not really on a channel right > now. > > Speaking about that "open this channel sidebar" on top right, it could really > use a tooltip, the icon is not really that obvious the first time you click > it it's like hoping it's not the kill everyone button :) > > I am not sure how i did it (i think i was loging in and login out again) but > i ended up with two panels https://i.imgur.com/2ot4ROY.png > > The first time you login, the chat sorting is all weird, see > https://i.imgur.com/2ot4ROY.png (ignore the right panel), there groups, then > direct messages, then groups again on the left panel > > There seems to be some issue with text wrapping, see how > https://i.imgur.com/2NsTx3X.png gets turns into > https://i.imgur.com/TePoCAx.png (the black on the right is the window behind > neochat) > > In the room settings having Save not be at the end of the layout is
NeoChat in KDEReview
Hello, Tobias and I have been working on a Matrix client using Kirigami, named NeoChat. NeoChat is still missing a few features to become a full-featured Matrix client (most notably encryption support and video chat support), but it is starting to be good enough for interacting with public rooms. It is using version 0.6 of libQuotient and is a fork of the (abandoned) Spectral client. For the moment the feature supported are: * Sending messages * Sending files from clipboard and filesystem * Reply to message (right-click on a message to access menu) * Start a private chat (but not encrypted) * Show notifications, for the moment there is only a global switch to disable it. We plan to implement the configuration part of the specification soon. * Auto-completion of usernames in chat * Emoji picker * Basic room setting page * Send and accept invitations * /rainbow (very important) * /me * And more features are contently added We already support a nightly build for Flatpak and a quite experimental Android build. The only external dependencies for NeoChat are libQuotient (0.6.x branch) and cmark. Concerning the release plan, we want to release an initial version to ship with the Pinephone KDE edition. And once with are happy with the feature provided by NeoChat (e.g. encryption support) we plan on moving it to the release service. We have an active Matrix room for discussion around NeoChat at #neochat:kde.org. Thanks in advance for your review and helpful advice. Carl and Tobias
Announcing MyKDE
Hello folks, I'm happy to announce the successful deployment of the new identity system in KDE, codename MyKDE. The new identity system is now available in https://my.kde.org. You should be able to login into the my.kde.org website with your normal KDE credential. For the moment, only the wikis are using MyKDE but in the comming months this should change with more and more services switching to MyKDE. I will let you all know of the progress of the migration. FAQ: Why the move? - identity.kde.org is using OpenLDAP for user management with a small PHP frontend allowing the account creation. And we had the following problems with it: * Account removal is hard, requiring significant manual intervention and effort (several hours work in some instances) * Account registration takes 30 seconds or more to complete, creating a poor user experience * Groups don't scale effectively * Anti-spam measures are too crude More on that in https://phabricator.kde.org/T8449 Will my data be migrated? - Yes, your data are migrated just by login into MyKDE once. This will migrate all your group membership (KDE developer, Akademy Team, ...), personal data and password. For users who didn't log into MyKDE during the migration period. If you are a KDE developer or KDE e.V. member, your account will be imported as a disabled account and you will need to ask sysadmins to enabled it. For the rest of the users of identity.kde.org who don't have a membership to groups, your account will be removed. We think this is the best solution because there is no need to store personal information that we don't need from users who don't use the system anymore. If you want to conserve your account (and username), please log at least once. We will send periodic emails reminding you of migrating your account. How do I register a new account in MyKDE? - For the moment the possibility of registering a new account is disabled in MyKDE and the only possibility is to create an identity.kde.org account and then migrate your account. This is due to the fact we don't want some accounts existing only in MyKDE. This will naturally change when we migrate fully to MyKDE. How to I collect a badge? - MyKDE has the possibility to grant badges to users. For the moment there is only one badge enabled: KDE developer. This badge is given to every KDE developer and is displayed on their public profile (if enabled). When the new Season of KDE website will be deployed, it will be also possible to have an SoK mentor and SoK mentee badge. I'm interested in ideas of new badges (and badge designs), so please let me know if you have a genius idea that doesn't gamify KDE contribution (e.g no made 100/1000/10 000 commits badge). Note that you are in control of that badge get displayed. What is the public profile functionality? - One of the new features of MyKDE is the possibility to have a public profile. This public profile is opt-in, so you need to explicitly enable it to make it work and it can display a small bio, your avatar, name, username, social network account, Liberapay account, and badges earned. This is for example how it looks for me: https://my.kde.org/user/carlschwan/ Can I contribute to MyKDE? -- Yes, the source code is hosted in https://invent.kde.org/websites/my-kde-org and all the deployment information can be found here: https://sysadmin-docs.kde.org/services/mykde.html Cheers, Carl Schwan https://carlschwan.eu
Re: plasma-systemmonitor in kdereview
Le jeudi, octobre 1, 2020 11:36 AM, Arjen Hiemstra a écrit : > Hello, > > I'd hereby like to announce that plasma-systemmonitor is in kdereview. It can > be found at https://invent.kde.org/plasma/plasma-systemmonitor . > > plasma-systemmonitor is a new system monitor UI built with Kirigami. It makes > use of the ksystemstats daemon and the faces system for system monitor > plasmoids that were both introduced in Plasma 5.19. > > Our current plan is to do a "preview release" alongside Plasma 5.20, then have > it be an official part of Plasma with 5.21. Plasma System Monitor looks quite good, but it doesn't look like it is navigable with the keyboard only. I know that some of the issues are caused by Kirigami and Qml but it looks like many custom components can't get any focus with tab and need the mouse to work. It is also normal for Table component to import private api from qqc2-desktop-style framework? https://invent.kde.org/plasma/plasma-systemmonitor/-/blob/master/src/table/FirstCellDelegate.qml#L13 Cheers, Carl > > Cheers, > Arjen
Re: KDEReview for Kontrast
Le jeudi, juillet 30, 2020 11:16 AM, Carl Schwan a écrit : > Hi, > I would like to move Kontrast, a contrast checker application, to KDEReview. > Kontrast can check if two colors pass the WCAG 2.0 specification and save > some user's favorite color combinations. > > Some screenshots of the application and a design review from the VSG is > available here: https://invent.kde.org/accessibility/kontrast/-/issues/1 > > From a code point of view, the application is very simple, but I still would > appreciate a general code review on it (it's my first Qt app written from > scratch). The code is available here: > https://invent.kde.org/accessibility/kontrast > > I don't plan to add new features and would like after the KDEReview, to > release a first version of the application, and then move it to the release > service so that the application gets regularly translations improvement. > > Thanks > Carl Hi again, It is now more than 14 days that Kontrast is in KDEReview and I think I fixed all the points raised here and in IRC. I would like to release the first version somewhere next week and possibly a minor version 2 or 3 weeks later for an additional translation update and possible bug fixes. So I will move to extragear this evening (CEST) if nobody object to that. Cheers, Carl
Re: KDEReview for Kontrast
Le lundi, août 3, 2020 11:12 PM, Albert Astals Cid a écrit :
> El dilluns, 3 d’agost de 2020, a les 4:26:25 CEST, Carl Schwan va escriure:
>
> > Le dimanche, août 2, 2020 6:20 PM, Albert Astals Cid aa...@kde.org a écrit :
> >
> > > El dijous, 30 de juliol de 2020, a les 11:16:25 CEST, Carl Schwan va
> > > escriure:
> > >
> > > > Hi,
> > > > I would like to move Kontrast, a contrast checker application, to
> > > > KDEReview Kontrast can check if two colors pass the WCAG 2.0
> > > > specification and save some user's favorite color combinations.
> > > > Some screenshots of the application and a design review from the VSG is
> > > > available here: https://invent.kde.org/accessibility/kontrast/-/issues/1
> > > > From a code point of view, the application is very simple, but I still
> > > > would appreciate a general code review on it (it's my first Qt app
> > > > written from scratch). The code is available here:
> > > > https://invent.kde.org/accessibility/kontrast
> > > > I don't plan to add new features and would like after the KDEReview, to
> > > > release a first version of the application, and then move it to the
> > > > release service so that the application gets regularly translations
> > > > improvement.
> >
> > Hi Albert,
> > Thanks a lot for the review
> >
> > > You don't have an icon, which is not optimal [actually i see you have an
> > > icon in invent.k.o so the hard part of drawing it seems to be done :)]
> >
> > I added the icon and I hope I installed it to the correct location:
> > https://invent.kde.org/accessibility/kontrast/-/commit/8a008c1387c0234d5e1d537bdd331007d7b1ff07.
> > It was already stored in breeze-icons but I guess it is better to also
> > have the app icon in the application so that it is displayed on other DEs.
>
> I'm 93% sure the file should be kontrast.svg given you're doing
> QApplication::setWindowIcon(QIcon::fromTheme(QStringLiteral("kontrast")));
I updated my setWindowIcon call now and the icon now works.
>
> > > The # of the colors is cut for me https://i.imgur.com/1GC2sEU.png
I fixed this behavior of the TextField and also added a maximumLength attribute
so that the text can't be more than 7 characters long.
I also now make sure that the text color of the field is always visible.
https://invent.kde.org/accessibility/kontrast/-/commit/2d235189603c87ead8d03cc0bef9d1933716552d
> > > Missing i18n:
> > > ./src/contents/ui/MainPage.qml:28: title: "Please choose a color"
> >
> > Fixed now
> >
> > > Would be great if you had the typical --help --author, etc.
> > > See QCommandLineParser and KAboutData::setupCommandLine
I now also added the KAboutData::setupCommandLine call and --help and --author
work.
> > > Would a documentation of the ranges make sense?
> > > i.e. something that has the ranges and the descriptions you put for each
> > > of the ranges in one place? Something like a "Help" page.
> >
> > Great ideas, I put them on my TODO list.
> > https://invent.kde.org/accessibility/kontrast/-/issues
There is now a basic help page adding information about the contrast range:
https://invent.kde.org/accessibility/kontrast/-/merge_requests/4
> >
> > > Could only test part of the app since you're requiring unreleased
> > > Kirigami 2.14
> > > Which probably means your
> > > set(KF5_MIN_VERSION "5.70.0")
> > > should be changed to
> > > set(KF5_MIN_VERSION "5.73.0")
> >
> > I have now changed the kirigami dependency to require an older Kirigami
> > version, since
> > I wasn't using any new Kirigami feature anyway.
>
> No you have not?
>
> ./src/contents/ui/FavoritePage.qml:8:import org.kde.kirigami 2.14 as Kirigami
Sorry it looks like I forgot to commit the change :(
https://invent.kde.org/accessibility/kontrast/-/commit/d73003f36d71ec036a7d612eb3487ea3801bd6c1
>
> > But I would still recommend using Kontrast
> > with the latest Kirigami version since the new version comes with a few
> > Accessibility
> > improvements ;)
> >
> > > Out of curiosity any reason you decided to go with
> > > auto SavedColorModel::refresh() -> void
> > > instead of
> > > void SavedColorModel::refresh()
> > > ?
> >
> > This code was contributed by Carson Black and I have no strong preferences
> > for the coding style
> > of the methods. I guess changing it back to the traditional style could
> > make sense to follow
> > the general KDE coding style.
>
> No need, i was just curious about the waste of horizontal space :)
>
> Cheers,
> Albert
>
> > > Cheers,
> > > Albert
> > >
> > > > Thanks
> > > > Carl
Re: KDEReview for Kontrast
Le dimanche, août 2, 2020 6:20 PM, Albert Astals Cid a écrit : > El dijous, 30 de juliol de 2020, a les 11:16:25 CEST, Carl Schwan va escriure: > > > Hi, > > I would like to move Kontrast, a contrast checker application, to KDEReview > > Kontrast can check if two colors pass the WCAG 2.0 specification and save > > some user's favorite color combinations. > > Some screenshots of the application and a design review from the VSG is > > available here: https://invent.kde.org/accessibility/kontrast/-/issues/1 > > From a code point of view, the application is very simple, but I still > > would appreciate a general code review on it (it's my first Qt app written > > from scratch). The code is available here: > > https://invent.kde.org/accessibility/kontrast > > I don't plan to add new features and would like after the KDEReview, to > > release a first version of the application, and then move it to the release > > service so that the application gets regularly translations improvement. Hi Albert, Thanks a lot for the review > You don't have an icon, which is not optimal [actually i see you have an icon > in invent.k.o so the hard part of drawing it seems to be done :)] I added the icon and I hope I installed it to the correct location: https://invent.kde.org/accessibility/kontrast/-/commit/8a008c1387c0234d5e1d537bdd331007d7b1ff07. It was already stored in breeze-icons but I guess it is better to also have the app icon in the application so that it is displayed on other DEs. > > The # of the colors is cut for me https://i.imgur.com/1GC2sEU.png > > Missing i18n: > ./src/contents/ui/MainPage.qml:28: title: "Please choose a color" Fixed now > > Would be great if you had the typical --help --author, etc. > See QCommandLineParser and KAboutData::setupCommandLine > > Would a documentation of the ranges make sense? > i.e. something that has the ranges and the descriptions you put for each of > the ranges in one place? Something like a "Help" page. Great ideas, I put them on my TODO list. https://invent.kde.org/accessibility/kontrast/-/issues > > Could only test part of the app since you're requiring unreleased Kirigami > 2.14 > Which probably means your > set(KF5_MIN_VERSION "5.70.0") > should be changed to > set(KF5_MIN_VERSION "5.73.0") I have now changed the kirigami dependency to require an older Kirigami version, since I wasn't using any new Kirigami feature anyway. But I would still recommend using Kontrast with the latest Kirigami version since the new version comes with a few Accessibility improvements ;) > > Out of curiosity any reason you decided to go with > auto SavedColorModel::refresh() -> void > instead of > void SavedColorModel::refresh() > ? This code was contributed by Carson Black and I have no strong preferences for the coding style of the methods. I guess changing it back to the traditional style could make sense to follow the general KDE coding style. > > Cheers, > Albert > > > Thanks > > Carl
Re: KDEReview for Kontrast
Le dimanche, août 2, 2020 2:58 PM, Nate Graham a écrit : > Hello Carl, > This looks very useful! Overall I'd say the UI is good. One thing I find > myself missing while playing around is the ability to test system > colorschemes though. That would be a really nice addition. I'm not sure this feature would make sense in Kontrast, but maybe this functionality should be integrated into the new color scheme editor Noah is building. The actual logic for calculating the contrast is very small. What do you think? > > Nate > > On 7/30/20 3:16 AM, Carl Schwan wrote: > > > Hi, > > I would like to move Kontrast, a contrast checker application, to > > KDEReview. Kontrast can check if two colors pass the WCAG 2.0 specification > > and save some user's favorite color combinations. > > Some screenshots of the application and a design review from the VSG is > > available here: https://invent.kde.org/accessibility/kontrast/-/issues/1 > > From a code point of view, the application is very simple, but I still > > would appreciate a general code review on it (it's my first Qt app written > > from scratch). The code is available here: > > https://invent.kde.org/accessibility/kontrast > > I don't plan to add new features and would like after the KDEReview, to > > release a first version of the application, and then move it to the release > > service so that the application gets regularly translations improvement. > > Thanks > > Carl
Re: KDEReview for Kontrast
Carl Schwan https://carlschwan.eu ‐‐‐ Original Message ‐‐‐ Le dimanche, août 2, 2020 3:36 PM, Nicolas Fella a écrit : > Hi Carl, > > a couple of nitpicks, otherwise looks neat. > > - your CMakeLists.txt does not specify a minimum Qt/KF5 version. Also > ECM 0.0.8 is likely quite old and a bit optimistic > > - Setting CMAKE_CXX_STANDARD to 11 is implicitly done by ECM, no need to > do that manually. It also contradicts the > target_compile_features(kontrast PRIVATE cxx_std_17) you set later > > - You can save yourself the explicit call to qt5_add_resources by adding > resources.qrc to the add_executable call. This is called AUTORCC in > cmake and ECM enables it by default It is probably worth changing this in the default Kirigami template in KAppTemplete since this is where I took the code. Same for the CMAKE_CXX_STANDARD declaration and the ECM 0.0.8. > > - Instead of using QScopedPointer you should be able to just > > put Kontrast on the stack > > - consider setting "isMenu: true" on your global drawer, that turns it > into a hamburger menu on the desktop, which is more appropriate than a > drawer Thanks for the feedback, I think I have now fixed all the things you found. > > Cheers > > Nico > > On 30.07.20 11:16, Carl Schwan wrote: > > > > Hi, > > I would like to move Kontrast, a contrast checker application, to > > KDEReview. Kontrast can check if two colors pass the WCAG 2.0 specification > > and save some user's favorite color combinations. > > Some screenshots of the application and a design review from the VSG is > > available here: https://invent.kde.org/accessibility/kontrast/-/issues/1 > > From a code point of view, the application is very simple, but I still > > would appreciate a general code review on it (it's my first Qt app written > > from scratch). The code is available here: > > https://invent.kde.org/accessibility/kontrast > > I don't plan to add new features and would like after the KDEReview, to > > release a first version of the application, and then move it to the release > > service so that the application gets regularly translations improvement. > > Thanks > > Carl
KDEReview for Kontrast
Hi, I would like to move Kontrast, a contrast checker application, to KDEReview. Kontrast can check if two colors pass the WCAG 2.0 specification and save some user's favorite color combinations. Some screenshots of the application and a design review from the VSG is available here: https://invent.kde.org/accessibility/kontrast/-/issues/1 >From a code point of view, the application is very simple, but I still would >appreciate a general code review on it (it's my first Qt app written from >scratch). The code is available here: >https://invent.kde.org/accessibility/kontrast I don't plan to add new features and would like after the KDEReview, to release a first version of the application, and then move it to the release service so that the application gets regularly translations improvement. Thanks Carl
Re: Move Koko to KDEReview
Le jeudi, juin 11, 2020 9:43 PM, Albert Astals Cid a écrit :
> El dimarts, 9 de juny de 2020, a les 13:30:35 CEST, Carl Schwan va escriure:
>
> > Hi,
> > I would like to move Koko, a convergent image viewer, to KDEReview.
> > Koko is already shipped in the base Plasma mobile image and I was
> > surprised that it was still in playground. The current devs are mostly
> > Nicolas, Marco and me.
>
> Is this baloo based? I guess it would explain why I can hardly see any images.
> Ah no, it only lists images from the "Pictures" folder, i see, kind of weird
> for a desktop app.
This is the default behavior in Digikam and KPhotoAlbum, the only difference is
that these apps allow changing this behavior. I guess it would make sense to
make
it configurable (for the case the image collection is located in an external
drive
for example) but this is not my priority yet.
> I think you have a memory leak in FileSystemTracker::reindexSubFolder,
> there's a FileSystemImageFetcher new'ed and i can't see it being deleted.
>
> > From the release sanity checklist:
> >
> > - licensing should be ok (LGPL-2.1-only or LGPL-3.0-only or
> > LicenseRef-KDE-Accepted-LGPL), but some headers are missing in the
> > CMake files :/
> >
> > - A Messages.sh file is missing and help would be welcome to figure
> > out if Koko need one since translations are regularly being pushed by
> > scripty.
> >
>
> Yes you need one, Yuri already added it.
>
> What you also need and you don't have is a call to
> KLocalizedString::setApplicationDomain("koko"); in your main.cpp
This was added in https://invent.kde.org/plasma-mobile/koko/-/merge_requests/25
and the
Kirigami AboutPage component was also added at the same time :)
>
> > - Screenshot is missing but I plan to add one before the release.
> > - CI works and there is a .gitlab-ci.yml file.
> > - There is an AppStream file.
> > - There is some documentation on userbase: https://userbase.kde.org/Koko
> > I plan to also update it before the next release.
> >
>
> I'm kind of unsure how i feel about it downloading things on cmake time.
I asked a few packagers I know and for them, since the packagers can download
the files and put them into the tarball, it should be fine. But they also
said that it would be way better to have it fetched as run time, but it also
means that I will need to do some larger change since currently, the code
expects the files to be there and assert otherwise. I will let you all know
them I figure out an elegant solution.
>
> Also the left bar seems to need some layouting fixes, there's an "l" missing
> from the button at the bottom and the slider also can go "past" the bar as
> illustrated by the screenshot https://i.imgur.com/KTo8WmG.png
Fixed using the same hack as in Discover, the current problem is that Kirigami
default sidebar width is too large, but hardcoding a width can break using a
different locale. I believe this will require a discussion in the kirigami and
VDG channel to decide on sane default width, so that applications don't need to
hardcode size that can break on different locales.
> Cheers,
> Albert
>
> > Carl Schwan
> > https://carlschwan.eu
publickey - carl@carlschwan.eu - 0x7F564CB5.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Re: Move Koko to KDEReview
Le mercredi, juin 10, 2020 9:01 AM, Yuri Chornoivan a écrit : > > > 10 червня 2020, 11:35:37, від "Carl Schwan"c...@carlschwan.eu: > > > Hi, > > I would like to move Koko, a convergent image viewer, to KDEReview. > > Koko is already shipped in the base Plasma mobile image and I was > > surprised that it was still in playground. The current devs are mostly > > Nicolas, Marco and me. > > Koko is following the KDE HIG and is build using QtQuick and the > > Kirigami framework. > > The repo is located here: https://invent.kde.org/plasma-mobile/koko/. > > There is only one know big issue, but it is in the progress of > > being resolved1. > > In the future, I plan to add a simple image editor that is currently > > being developed as a separate and reusable library. More info about > > it is available in my latest blog post2. > > I would be happy if it could be reviewed and my goal is to move it to > > the release service, I hope in time for 20.08. > > From the release sanity checklist: > > > > - licensing should be ok (LGPL-2.1-only or LGPL-3.0-only or > > LicenseRef-KDE-Accepted-LGPL), but some headers are missing in the > > CMake files :/ > > > > - A Messages.sh file is missing and help would be welcome to figure > > out if Koko need one since translations are regularly being pushed by > > scripty. > > > > Added. Scripty will extract the catalog for translation tomorrow. > > But I bet the translations will not be loaded because of the lack of > KAboutData and friends. See KLook: > > https://invent.kde.org/graphics/klook/-/blob/master/src/main.cpp > > Hope this helps and thanks for your work. > > Best regards, > Yuri Thanks for the Messages.sh commit, I now created a merge request adding the KAboutData bits: https://invent.kde.org/plasma-mobile/koko/-/merge_requests/25 > > > - Screenshot is missing but I plan to add one before the release. > > - CI works and there is a .gitlab-ci.yml file. > > - There is an AppStream file. > > - There is some documentation on userbase: https://userbase.kde.org/Koko > > I plan to also update it before the next release. > > > > > > Carl Schwan > > https://carlschwan.eu publickey - carl@carlschwan.eu - 0x7F564CB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Move Koko to KDEReview
Hi, I would like to move Koko, a convergent image viewer, to KDEReview. Koko is already shipped in the base Plasma mobile image and I was surprised that it was still in playground. The current devs are mostly Nicolas, Marco and me. Koko is following the KDE HIG and is build using QtQuick and the Kirigami framework. The repo is located here: https://invent.kde.org/plasma-mobile/koko/. There is only one know big issue, but it is in the progress of being resolved[1]. In the future, I plan to add a simple image editor that is currently being developed as a separate and reusable library. More info about it is available in my latest blog post[2]. I would be happy if it could be reviewed and my goal is to move it to the release service, I hope in time for 20.08. >From the release sanity checklist: * licensing should be ok (LGPL-2.1-only or LGPL-3.0-only or LicenseRef-KDE-Accepted-LGPL), but some headers are missing in the CMake files :/ * A Messages.sh file is missing and help would be welcome to figure out if Koko need one since translations are regularly being pushed by scripty. * Screenshot is missing but I plan to add one before the release. * CI works and there is a .gitlab-ci.yml file. * There is an AppStream file. * There is some documentation on userbase: https://userbase.kde.org/Koko I plan to also update it before the next release. Carl Schwan https://carlschwan.eu [1]: https://invent.kde.org/plasma-mobile/koko/-/merge_requests/20 [2]: https://carlschwan.eu/2020/06/06/koko-desktop.html publickey - carl@carlschwan.eu - 0x7F564CB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
