Re: Proposal unify back our release schedules
On Friday, April 19, 2024 6:39:01 PM GMT+2 Kevin Ottens wrote: > Hello, > > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker here > I think. I'll try to add a couple of extra aspects to feed the thinking on > this topic. Thanks you all for raising some important points. Taking into account the feedback, I would like to slightly change my proposal. - Unify only the release schedule of Gear and Plasma with a frequency of either 4 months or 6 months. This would follow the Fibonacci release schedule. - Keep framework release once every month. But ensure that once every 4 (or 6) months, it happens at the same time as Gear and Plasma. We can keep the frequent features release of framework, which seems to be valuable for people not compiling the whole stack from source. For the occasion where the Framework, Gear and Plasma, we should then ensure that the framework release is done at the same time or slightly before the gear and plasma release and ideally there is also a special beta release of Framework done at the same time as the gear and Plasma beta, which can be tested together with the other beta releases. If Plasma decides to switch to a release every 6 months and Gear prefers to keep a shorter release cycle, then I would suggest using 3 months for gear so that we still have an unified released of framework, gear and plasma once every 6 months. I'm less fan of this and if we have a very good reason to switch to a 6 months release cycle for Plasma, this argument should also apply to Gear. > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote: > > > > * We end up with 3 different products which are released at different > > times > > but are connected together. Apps and Plasma both need Framework, Plasma > > needs some packages from gear like kio-extra, Gear needs some package from > > Plasma like Breeze. Coordinating all these inter-groups dependencies is > > complex and was one the reason we had to do a megarelease for Plasma 6. > > Also for the end user, one product is a lot easier to understand. > > This is an engineering topic in this case. > > And, to me, this is an excellent reason not to reunify release schedules! > Because what it tells me is that we're still having dependency issues which > need to be solved. > > The example you give shows Plasma depending on Gear, this shouldn't happen, > so I'd argue: let's fix that instead. > > Aligning the release schedules would only hide such structural issues. > > This was one of the main engineering motives to split things up: when it > wasn't splitted this would stay hidden much longer everyone being comfy with > it. > > Now it's creating pain: perfect, that makes the issue obvious, but it should > be addressed not masked. > > This is in part what Volker highlighted pointing out this should be less of > a problem with key components being moved to Plasma. Again, if there are > more, let's just address them. > > So as pointed out by Sune and Volker: this is a feature (at least in the > Frameworks case) not a bug. I'm been working a lot on the visual of applications across the whole stack and for me, the pain is mostly caused by the fact element of our styling are spread across the 3 releases: gear/plasma and framework. The megarelease has been tremendously helpful to get visual changes implemented consistently across the entire stack and I don't think this can be solved even with the best will. Plasma holds Breeze which holds information about how our controls look like. There was discussion in the KF6 board to move breeze to be a framework but due to the license this is not possible (unless we change the definition of framework and allow GPL stuff). Framework holds qqc2-desktop-style and breeze-icons as well as a lot of custom widgets frameworks like Kirigami, KWidgetsAddons, KConfigWidgets, KItemView, KXmlGui, ... There are also a lot of libraries in gear which contains custom widgets (a lot in PIM but not only). Apps themselves also contains a lot of design elements. This includes some custom widgets but also the general layout of the app and dialogs. This could be fixed by adding a lot more widgets in apps to KWidgetsAddons/Kirigami, but it doesn't always make sense as some widgets are super niche and don't belong to a Framework/library. Some examples from the recent redesign in the megarelease are the design of periodical table cell elements in Kalzium which previously followed the Oxygen guidelines and now is more Breeze looking. Another one is the layout of the Kate search and replace dock and a lot of other docks which had to be changed to have a more "frameless" look. It won't solve the issue for extragear applications, but I don't want the search of a perfect solution for 100% of our apps prevent us to f
Re: Proposal unify back our release schedules
On Friday, April 19, 2024 2:03:45 PM GMT+2 Luigi Toscano wrote: > We also have and we will continue to have applications which are not on this > schedule, and thus KDE will continue to be unfit as a general brand for > them. The work to reduce the dependencies improved with the move to Qt 6 > (for example the Frameworks-but-really-Plasma moved to Plasma), surely it > can be improved. And this is fine. For these apps, they can still continue to depends on Framework as they wish and the API and ABI stability are still guaranteed. They won't have as often a feature release of Framework but I don't expect this to be a big issue as these apps already often prefer to depend on older framework release instead of pursuing the latest release. > > * We currently don't have a stable branch for Framework and it takes often > > up to> > > one month for fixes to be deployed. The Framework releases is also not > > in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > > But the point of Frameworks is that it should be "always stable". This is unfortunately not the case. Errors happen and I feel like having a beta period shared with the rest of the stack and a patch release one week after the release would be really helpful for the stability of Framework. > > * We could have an unified LTS release including more than just Plasma. > > This is> > > something that distros have been asking for some time already because > > having just Plasma receiving bug-fixes but not Framework nor the apps > > is not that helpful. > Wasn't it said that LTS are difficult? I've heard different voices even from > Plasma. I'm not a big fan of doing LTS release either. I just think a LTS release of gear + plasma + framework would be better than one of just Plasma. > > * In term of promotion, it is very difficult to advertise the 3 releases > > because ... > > Again, this will still leave out everything which does not happen to be part > of this 3 blocks. Which is fine. Apps outside of Gear have been doing their own release at their own pace with their own release announcement and will continue to do so. This proposal doesn't change that. It is not better or worse for them. > > * We won't have 3 different release teams but instead have a bigger one > > with a> > > bigger bus factor. We could also unify the tooling for doing this mass > > releases a bit. > > Releasing improved over time, and the tooling is definitely more unified > than before (I think Frameworks uses the same tool as Plasma). With the > discussion about improving the creating of tarballs directly from the tags, > this may be more a non-problem). It's improving and this is good. But you still need people to run the scripts at some interval, ensure that the builds are passing for everything and ping the correct people if not, move the translations to the correct branch in SVN, ... > > I do understand that there was valid reasons for splitting KDE Software > > Collection for Plasma 5 but I don't think this worked out. These were as > > far as I know the main arguments used for splitting the Software > > Collection. > > It doesn't mean moving back is the solution. Also, the split happened before > Qt5, and the reason are still there. The split is not solving the issues we were thinking it would solve and is additionally causing other issues. For me this is a clear indication that we need to rethink the split, that the current status quo is not working, and that we need to find a better solution. I'm proposing this proposal as a possible solution and indeed this might not be the only one, but this is only one I came up. Anyone is free to propose counter proposal on how to improve the situation ;) > > * Trying to move away from "KDE" being recognized as the software instead > > of the> > > community. This unfortunately didn't really work out, everyone is still > > using KDE to refer to the desktop. Even distros call their edition > > "KDE" and I don't blame them, it's difficult to find a better term than > > that as for example "Fedora KDE Spin" not only contains Plasma but also > > a lot of KDE apps. Splitting the releases won't help with that, we need > > to find a better approach or just let it go and accept that people will > > keep using KDE to describe the desktop/software. > > And again, we have and will have stuff which does not fit that. The main > problem is the Desktop which is seen as "KDE". People use "KDE" to refer to the "core" components and this includes stuff like Dolphin, Kate and Okular, it's not only the desktop. > Maybe it will take just more time and another generation of people. I don't think so and even if it did require more time, do we want to wait another decade and see if the situation improve? > > * Better promotion of our apps outside of Plasma. This is a valid point > > but I think> > > pursuing
Proposal unify back our release schedules
Hello Community, I know this might be a controversial idea, but I would like to propose reunify our release schedules. I feel like splitting our releases schedules between Frameworks, Plasma and Gear is not working as well as we intended it to be when we split the releases schedules for Plasma 5. This is for multiple reasons: * We end up with 3 different products which are released at different times but are connected together. Apps and Plasma both need Framework, Plasma needs some packages from gear like kio-extra, Gear needs some package from Plasma like Breeze. Coordinating all these inter-groups dependencies is complex and was one the reason we had to do a megarelease for Plasma 6. Also for the end user, one product is a lot easier to understand. * This results in very frequent releases which creates a lot of work for distros and talking with some distro maintainers they seems to agree that having a big releases every 4 months is better than having constantly a new minor or major release from either Framework, Gear or Plasma. * We currently don't have a stable branch for Framework and it takes often up to one month for fixes to be deployed. The Framework releases is also not in sync with either Gear nor Plasma while these two modules heavily make use of Framework and contribute to Framework. * We could have an unified LTS release including more than just Plasma. This is something that distros have been asking for some time already because having just Plasma receiving bug-fixes but not Framework nor the apps is not that helpful. * In term of promotion, it is very difficult to advertise the 3 releases because combined we have an important release of either Gear, Plasma or Framework every few weeks. This is too frequent and often while a combined announcement would have enough content to be published in a tech newspaper. When splitting the content accross 2 announcements (Gear and Plasma), we reduce the content per announcement and this makes it less interesting for the journalists to write about us. This doesn't come from me, this is that some journalists directly told me. * We won't have 3 different release teams but instead have a bigger one with a bigger bus factor. We could also unify the tooling for doing this mass releases a bit. I do understand that there was valid reasons for splitting KDE Software Collection for Plasma 5 but I don't think this worked out. These were as far as I know the main arguments used for splitting the Software Collection. * Trying to move away from "KDE" being recognized as the software instead of the community. This unfortunately didn't really work out, everyone is still using KDE to refer to the desktop. Even distros call their edition "KDE" and I don't blame them, it's difficult to find a better term than that as for example "Fedora KDE Spin" not only contains Plasma but also a lot of KDE apps. Splitting the releases won't help with that, we need to find a better approach or just let it go and accept that people will keep using KDE to describe the desktop/software. * Better promotion of our apps outside of Plasma. This is a valid point but I think pursuing our current strategy of putting our apps in many app store to be more effective. We could also show the platforms support of each applications more prominently in our releases announcements like we already do on apps.kde.org (e.g. https://apps.kde.org/okular/). Generally Plasma releases fare a lot better in term of promotion than the gear announcements and showing the applications on an unified announcement would likely help spread the words about our applications better. * Helps with outside usage of our frameworks. These didn't get as much success as we were hoping when splitting. I think having a stable branch for Framework might help but this is only a guess. It would be interesting to know of cases where people considered using some Framework and to know why they decided against or for it and if this proposal would helps or not. In effect this proposal would mean: * We do one major release every 4 months and then minor releases with a frequency based on the Fibonacci numbers as this releases cycle works very well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could unify that for one or the other one. Or let each component keep their current versioning scheme depending whether we want to merge Plama and Gear as product or keep it separate. I'm a bit undecided about this. * "KDE Framework" will still exists as an entity and its ABI and API compatibility requirement. Only change is the release frequency and the introduction of a stable branch in sync with the other components. * Only have one release announcement on our website. We can call it Megarelease 6.XX like we did for Plasma 6/Gear 24.02 or find a better name. I would avoid reusing Software Collection first
Re: Should we stop distributing source tarballs?
On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote: > It seems a lot of people feel conservative in favor of tarballs, so > maybe I aimed too far. At least I think the discussion brought some > interesting points that we can explore further. Some I identified: > > - The tarballs should contain no changes with respect to git, or > minimal changes obviously justifiable in a diff. I would argue that there should be no change at all. Adapting the versions and adding the version to the AppStream file should be done in a git commit and not done in the tarball. This is already done by everyone using releaseme and following the steps from https://community.kde.org/ReleasingSoftware > - Tarballs should only be generated in a reproducible manner using > scripts. Ideally by the CI only. > - We should start to sign tarballs in the CI. I disagree. I want my tarball to be signed with my GPG key stored in my Yubiky and not by a generic KDE key. It should be a proof that I as a maintainer of a project did the release and not someone else. Same with the upload to download.kde.org, while this adds some overhead in the process, I think it is important that KDE Sysadmins are the one who move the tarball to their final location and do some minimal check (checksum match, it's not a random person doing the release, ...). > - We should start to sign commits and tags. Git recently made this > super easy by allowing signing with the ssh keys that we all are > already using to push things, so no excuses for not enabling this. > Sample config below: > > [user] > signingkey = > [commit] > gpgsign = true > [gpg] > format = ssh > [tag] > forceSignAnnotated = true +1 git tags are already signed for people following the releaseme workflow. Signing commits is also good and I encourage everyone to do it but I wouldn't make it a requirement as it increases the barrier to contribution for new contributors. signature.asc Description: This is a digitally signed message part.
Re: AppStream Metadata with our releases
Sensing from my phone so sorry for the html email On Sat, Mar 23, 2024, at 9:06 PM, Julius Künzel wrote: > 22.03.2024 17:22:33 Albert Astals Cid : > > > El divendres, 22 de març de 2024, a les 0:37:00 (CET), Julius Künzel va > > escriure: > >> Hi! > >> > >> (This mail goes to multiple lists, please reply to kde-devel) > >> > >> With Flathub beeing more strict on its AppStream metadata guidlines [1] > >> there is yet another spotlight on AppStream metadata. > >> > >> AppStream metadata are consumed by app stores like Flathub, Snapcraft, > >> Discover, our scripts to submit apps to the Microsoft Store and last but > >> not least by apps.kde.org [2]. > >> > >> For release info in particular the quality guidelines say: "Make sure all > >> your releases have release notes, even minor ones." [3] As I think this > >> makes perfectly sense, I like to propose two things that seem straight > >> forward to me: > >> > >> - We should not remove older releases from the AppStream data as already > >> suggested by Carl in a merge request [4]. > >> > >> - Also it would be convenient to add noteworthy changes to the metadata > >> together with the related code change. However at the moment for KDE Gear > >> the release is usually only added to the metadata a few days before > >> tagging. Would it be possible to add the next minor release to the release > >> branch right after the current one has been released and the next major > >> release to master ones the upcoming version has been branched? > >> > >> I belive this makes it easier for developers to contribute to the release > >> meta info and I hope it hence raises motivation to do so. > > > > > > My pessimistic opinion is that no one is going to add release notes, we've > > tried multiple ways to do it, even just asking people to add a keyword to > > the > > commit log if that commit log was release news worthy and no one did it past > > the first few weeks/months. > > Well, that might happen, but we don't know if we don't try... And as I don't > see this causing any extra work and (yet) can't see any downsides, it is even > worth it if it helps just a single app or developer, no? I see that Volker do add release information for Itinerary on every release and I also try to do that for neochat, tokodon and a few other apps. > > > > > It seems appstream has finally added the support (or maybe was there > > forever?), so my suggestion is that we just add an release+url entry > > pointing > > to > > https://kde.org/announcements/gear/x.y.z/ > > > > This way we don't have to do the work twice and has the added bonus of > > already > > translatable. > > > > This is a nice suggestion too! > However, I don't think this conflicts with my suggestion as the text in the > appstream should usually be just a short summary of the highlights. So let's > do both? +1
Re: kio-gdrive changes needed to conform to new Google requirements
On Thursday, February 15, 2024 9:53:39 PM CET Nate Graham wrote: > Hello folks, > The KDE e.V. board received an email from Google about changes required > for kio-gdrive. I've opened an Issue about it at > https://invent.kde.org/network/kio-gdrive/-/issues/1 with more details. > To my knowledge, kio-gdrive is maintainerless, so we're in need of a > kind soul who will volunteer to make any needed changes to the software. > > :) Any takers? I just looked into it and I don't want to be pesimistic but it sounds like Google is shutting us down. We are currently the 'drive' scope which allow us to access all the files of the users. This is the scope that google doesn't want us to use anymore. The alternatives proposed by google are: - drive.appdata: this allow only to access an app specific folder to store app specific data. It's fine if you want to sync app data between an app on multiple platforms but not much more. - drive.file: this is more a file picker API where the user can select a file and allow the application to use it. Again not helpful for a sync client See https://developers.google.com/drive/api/guides/api-specific-auth So we need to submit for re-verification and hope they allow us to continue using the API. We seen to be an allowed use-case according to their doc: https://developers.google.com/workspace/workspace-api-user-data-developer-policy#appropriate_access_to_and_use_ofs But it still requires some non-technical work: - Create a video of the gdrive workflow including the login and oauth process - An annual security assessment (not sure how hard it is to pass and hopefully it is free...) See: https://support.google.com/cloud/answer/13464321?sjid=5292936327783040555-EU# https://support.google.com/cloud/answer/13465431 I can probably help a bit with e.g. doing the video but starting the process needs to be done by someone who has access to the google account (probably the board). Cheers, Carl > > Nate
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: KDE Gear projects with failing CI (master) (30 January 2024)
On Tuesday, January 30, 2024 9:33:40 PM CET Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple reasons. > > Good news: 5 repositories got fixed > > Bad news: 7 repo still failing and 5 new this week > > > > krecorder - 3rd week > * https://invent.kde.org/utilities/krecorder/-/pipelines/594251 > * All the craft_android builds are broken fixed thanks to Nico https://invent.kde.org/utilities/krecorder/-/merge_requests/34 > akonadi-search - 2nd week > * https://invent.kde.org/pim/akonadi-search/-/pipelines/594243 > * FreeBSD tests are failing > > > cantor - 2nd week > * https://invent.kde.org/education/cantor/-/pipelines/594236 > * testmaxima fails on FreeBSD > > > konsole - 2nd week > * https://invent.kde.org/utilities/konsole/-/pipelines/594234 > * flatpak build complains about icon-not-found fixed https://invent.kde.org/utilities/konsole/-/merge_requests/953 > dolphin - 2nd week > * https://invent.kde.org/system/dolphin/-/pipelines/594235 > * flatpak build complains about icon-not-found On it https://invent.kde.org/system/dolphin/-/merge_requests/710 > gwenview - 2nd week > * https://invent.kde.org/graphics/gwenview/-/pipelines/594238 > * cfitsio SHA doesn't match on flatpak build > > > kipi-plugins - 2nd week > * https://invent.kde.org/graphics/kipi-plugins/-/pipelines/594247 > * CI fails to find libmediawiki > > > kirigami-gallery - NEW > * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/594323 > * flatpak build complains about icon-not-found > > > kbackup - NEW > * https://invent.kde.org/utilities/kbackup/-/pipelines/594246 > * flatpak build complains about icon-not-found > > > ark - NEW > * https://invent.kde.org/utilities/ark/-/pipelines/594239 > * tests fail on FreeBSD > > kimap - NEW > * https://invent.kde.org/pim/kimap/-/pipelines/594244 > * tests fail on FreeBSD > > > merkuro - NEW > * https://invent.kde.org/pim/merkuro/-/pipelines/594248 > * tests fail on FreeBSD > > > Cheers, > Albert
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
Stale MRs
Hello, Friendly reminder that the following repository will give you a list of stalled merge requests without review and is updated every week, https://invent.kde.org/teams/gardening/gitlab/-/issues It would be nice if some more devs would subscribe to this repo and try to unblock some of the pending MRs. In particular the Non-Dev MRs category where we should try to give new contributors feedback in a timely manner. Cheers, Carl
Re: KDE Gear features list
On Monday, November 27, 2023 10:49:04???PM CET Carl Schwan wrote: > Hello, > > I started working on the announcement for the the megarelease. For Plasma, > Nate collected all the new user facing changes here: > https://community.kde.org/Plasma/Plasma_6#User-facing_changes > > I would appreciate if gear app maintainers and contributors could do the > same for KDE gear: https://community.kde.org/Gear/Gear_24.02 I just need a > link to commit, MR or bug report and a few words about the change. > > I'm also working on a sliglty tweeaked format for the announcement which > would allow to mention both the big major changes as well as more minor > improvements than previously. So don't mind also adding more minor changes > to the wiki page, but I can't promise I will manage to mention everything. > > If you posted your progress already on a blog post (like we do in KDE PIM) a > link to that is also great. Thanks to all who contributed so far to the wiki page and a gentle ping to those who didn't yet. Preview of the announcement is available here: https://api.carlschwan.eu/announcements/megarelease/6/ (user: kde, password: kde) If you think I missed something important or there are some incorrect details, the corresponding merge request is here ;) https://invent.kde.org/websites/kde-org/-/merge_requests/244 Note that the screenshots are far from being the final and I will retake most if not all of them in the coming weeks. Cheers, Carl
Re: Flathub and Snap Store entries for KGeoTag
On Tuesday, January 2, 2024 10:50:07???PM CET Tobias Leupold wrote: > Hi all! > > As far as I can grasp it, https://apps.kde.org/de/kgeotag/ is automatically > generated from KGeoTag's appdata.xml file. However, the site lists both > Flathub and the Snapcraft as a possible installation source for KGeoTag, > with "KDE" referenced as the publisher on both sites. I never used neither, > so I don't know much about this besides those two are approaches to provide > distribution independent packages, without relying on the respective > package manager. > > But what this is about: > > On Flathub, one can read "No changelog provided" and "Proprietary: This app > is not developed in the open, so only its developers know how it works. It > may be insecure in ways that are hard to detect, and it may change without > oversight." > > Obviously, neither is true ... No changelog provided is true. You don't have any changelog in your appdata.xml, you can look at how we do this in NeoChat https://invent.kde.org/network/neochat/-/blob/master/ org.kde.neochat.appdata.xml?ref_type=heads#L407 Generally I recommend to follow the quality guidelines of Flathub https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/quality-guidelines/ For the proprietary part, I asked in the flatpak matrix channel and this is probably an issue with appstream-glib used by gnome software and flathub and that doesn't recognize LicenseRef-KDE-Accepted-GPL in your appdata.xml. Discover actually has the same issue... I'm not sure we need to add the LicenseRef in the appstream file is actually needed. For the user it's interesting that the project is licensed under gpl 3 not that it could also potentially be licensed under gpl 4 in the future. This is an information only needed in your source code, I would say but INAL ;) > > On Snapcraft, there's a similar "License: unset". This is afaik not taken from the appstream file and doesn't affect only KGeoTag, the way I got this resolved in the past is to ask Jonathan to fix it ;) > How can this be fixed? Is there something I can do about this? By adding > something to the invent repo? Or somewhere else? > > Thanks for all help! I hope this helps :) Cheers, Carl > > Cheers, Tobias
Spacing in our apps
Hi,
I'm been trying to unify a bit the usage of spacing in our apps and I'm
noticing a difference between how we do it in QWidgets apps and QML apps.
In QtWidgets apps, we use
- pixelMetric(QStyle::PM_Layout{Left,Right,Top,Bottom}Margin) for the margins
- pixelMetric(QStyle::PM_Layout{Vertical,Horizontal}Margin) for the spacing
between items in layout
In practice all these pixel metrics are equal to 6 pixels with Fusion, Oxygen
and Breeze. These means that in some cases, some apps are even hardcoding
these values in their .ui files, which is bad and we should try to avoid this.
In Kirigami apps, we use:
- Kirigami.Units.smallSpacing = 4 pixels
- Kirigami.Units.mediumSpacing = 6 pixels
- Kirigami.Units.largeSpacing = 8 pixels
In most cases, smallSpacing and largeSpacing are used as mediumSpacing was
introduced later on, so it doesn't match the values from QtWidgets apps. Worse
we don't really have clear guidelines when to use small or large spacing, so
it's mostly done arbitrarely and not consistantly :(
Also having 3 different Kirigami.Units.*Spacing values that are each only 2
pixels appart doesn't sounds like a great idea as it's hard to see a
difference between these values taken side by side.
I see three ways to move forward with this issue:
a) Remove smallSpacing and largeSpacing from Kirigami, and rename
mediumSpacing to just spacing. This unified spacing value would be defined in
qqc2-desktop-style to use whatever value is defined in the current QStyle.
a bis) Instead of creating only a generic "spacing" property, we create a
"Kirigami.Units.margins" or "Kirigami.Units.paddings" property to use for
paddings of QtQuick Controls and mapped to the Layout*Margin pixel metrics and
a "Kirigami.Units.spacing" property mapped to the Layout*Spacing pixel
metrics. For Breeze and Oxygen, both value would map to 6 pixels anyway, but
it might make it easier to switch to other values in the future as well as
make the usage of Units value more explit.
b) Use 4 pixels as standard spacing in our QtWidgets apps and add a "margins"
and "largeMargin" helper methods in KWidgetsAddons or QStyle similar to this
QMargins QStyle::largeMargins() const
{
return QMargins{
pixelMetric(QStyle::PM_LayoutLeftMargin),
pixelMetric(QStyle::PM_LayoutTopMargin),
pixelMetric(QStyle::PM_LayoutRightMargin),
pixelMetric(QStyle::PM_LayoutBottomMargin)
}
}
QMargins QStyle::largeMargins() const
{
return QMargins{
pixelMetric(QStyle::PM_LayoutLeftMargin) * 2,
pixelMetric(QStyle::PM_LayoutTopMargin) * 2,
pixelMetric(QStyle::PM_LayoutRightMargin) * 2,
pixelMetric(QStyle::PM_LayoutBottomMargin) * 2
}
}
then we can remove mediumSpacing from Kirigami and ensure that in both our
Kirigami and QtWidgets apps, we use small or large only no spacing at all. We
should still try to define some guidelines when to use large or small spacing.
c) Do nothing and accept that spacing in Kirigami apps and QtWidgets are
different. We might still want to define in our doc/hig the usecase for
largeSpacing and smallSpacing
Personally I see advantages and disadvantages for all these solutions. I had a
preference on b) but while writing this mail I'm slowly liking the a bis) idea
more and more as we might not need a small spacing and large spacing and could
get away with just one unified spacing.
Cheers,
Carl
Re: KParts and the Qt5->Qt6 transition
On Wednesday, December 6, 2023 9:51:20?PM CET Nicolas Fella wrote: > Hi, Hi, > the transition of many apps to Qt6 provides some challenges for apps > producing and consuming KParts. > > KParts are implemented as Qt plugins and as such are specific to the Qt > version they are built against. In other words, a KPart built against > Qt5 cannot be loaded by an app using Qt6 and vice versa. > > Since some parts are used by a variety of apps this is causing problems. > When we last discussed this problem the consensus was "Port as many > things as possible and see where we are at then". Now we are approaching > a point where we need to take stock and decide what to do. > > There's several cases to consider: > > 1) Applications using their own parts without external users. This > happens in PIM where e.g. kmailpart is only used by KMail and Kontact. > No problem here > > 2) Applications loading specific parts from other applications. These > are easy enough to search for. We have the following cases: > > . > > okularpart (Okular is in the process of getting ported): > > - kile (no Qt6 port) > > - kbibtex (no Qt6 port) It looks like kbibtex was ported two days ago. Would it be possible to have a gitlab issue or wiki page to keep track of the changes? This also let people know where help is needed. Cheers, Carl
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
Re: Unified internal communications channel
On Thursday, December 7, 2023 4:15:36?PM CET Nate Graham wrote: > Hello everyone, > > There have been a couple instances of drama this week caused by > decisions being made without some of the relevant stakeholders knowing > about them. In all cases, the decisions were announced, but either not > announced in the places where all the stakeholders saw it, or not all > stakeholders were able to notice the announcement in a place where they > do generally pay attention. The drama could have been avoided if the promo folks would have followed my recommandation to contact the relevant stakeholders in the plasma- de...@kde.org mailing list or attend the Plasma chat meeting hapenning every Monday at 4 PM in the Plasma matrix/irc channel. I tried to bring this up many times and it was dismissed every time i brough it up and I was told that I didn't understood the proposed idea and that should re-read the previous messages. It is unfortunately a recurring pattern in the promo channel and I decided for now to leave the kde-promo matrix channel as I feel like I'm wasting my time there. > It makes me think that maybe the KDE development community has grown so > large that we can't reasonably expect everyone to be paying attention to > everything, or for everyone with something to announce to know exactly > where the people who need to know it expect to find those messages. > > So perhaps this could be addressed at the source by creating a single > unified "internal announcements" place that everyone can pay attention > to without fear of being spammed with too many messages. In theory the > kde-devel mailing list is one such place, but it's got more than just > announcements, and also mailing lists aren't very accessible for a lot > of newer contributors who didn't grow up with them. > > What I'm proposing is some kind of place that *only* has internal > announcements and is very log signal-to-noise such that we can > fearlessly recommend that *everybody* subscribe to it. In addition, > ideally those who want to subscribe via mailing list could do so, but > its content would automatically appear in other places too, such as > discuss.kde.org and an invent.kde.org project. That way people can > subscribe by whatever means is most comfortable to them. > > Thoughts? I fear this will just create a new source of information instead of unifying the source of information. We already have the following channels for announcements: - planet.kde.org: contains release announcements, gear release schedule announcement from Albert as well as random development updates - kde-code-de...@kde.org: contains mostly news about new apps and modules - kde-devel@kde.org: contains the gear release schedule announcements and other technical announcements - plasma-de...@kde.org: contains important for plasma developers and the meeting notes of the monday chat meeting. - kde-commun...@kde.org contains general community (non technical) announcements Adding a new channel that is either a mailing list, rss feed or a forum category won't help and will probably only makes it worse. It's also very difficult to defines that is an important internal news for the whole community is as it will be different for every subproject in KDE. The plasma logo discussion would have not been very relevant for any app developers. Similarly discussion about the new default database backend for Akonadi won't be interesting for Plasma developers but might be interesting for KMyMoney and other non-PIM apps using Akonadi. Something that might help is merging the kde-core-devel and kde-devel mailing lists as those are very similar and should hopefully not be too complicated to do. Cheers, Carl > > Nate
Re: Interest in building an LLM frontend for KDE
On Friday, December 1, 2023 5:44:26?AM CET Andre Heinecke wrote: > Hi. > > On Friday, 01 December 2023 03:53:22 CET Loren Burkholder wrote: > > they can be quite useful for tasks like programming. > > I need it desperately for intelligent spellchecking / grammar fixes ?? > > > Should we be joining the mainstream push to put AI into everything or > > should we stand apart and let Microsoft have its fun focusing on AI > > instead of potentially more useful features? I don't recall seeing any > > discussion about this before (at least not here), so I think those are > > all questions that should be fairly considered before development on a > > KDE LLM frontend begins. > I don't think so. I have the slight feeling that you want to start an > abstract discussion here and then magically the "KDE Community" will > develop something. Just do it or don't. It will always be in the users > freedom to use it or not. I would love to have an optional KMail plugin > that interacts with an LLM. Others might not ?? I just want to point out that KMail has via KTextAddons already integration with many AI technology both online and local. This is not enabled by default and for many of the plugins this needs some extra configuration (e.g. API key) to work. For translations, KTextAddons supports bergamot (local and open source), libretranslate (local and open source) as well yandex, deepl, bing, google and lingva. For grammar checks, KTextAddons supports languagetool (open core and self hostable), grammalecte (open source but only for french). For speech to text, KTextAddons supports whishper (local and open source), vosk (local and open source) and google For text to speech, KTextAddons uses QTextToSpeech underneath which uses a varieties of local backend: https://doc.qt.io/qt-6/qttexttospeech-engines.html More details can be found in the repo https://invent.kde.org/libraries/ktextaddons/ KTextAddons is currently used in Ruqola and the KDE PIM apps and I was hoping to at some point also find the time to add it to some QML app. Laurent already did some work to separete the core part from the widgets parts. Cheers, Carl
KDE Gear features list
Hello, I started working on the announcement for the the megarelease. For Plasma, Nate collected all the new user facing changes here: https://community.kde.org/Plasma/Plasma_6#User-facing_changes I would appreciate if gear app maintainers and contributors could do the same for KDE gear: https://community.kde.org/Gear/Gear_24.02 I just need a link to commit, MR or bug report and a few words about the change. I'm also working on a sliglty tweeaked format for the announcement which would allow to mention both the big major changes as well as more minor improvements than previously. So don't mind also adding more minor changes to the wiki page, but I can't promise I will manage to mention everything. If you posted your progress already on a blog post (like we do in KDE PIM) a link to that is also great. Cheers, Carl PS: if you are interested in seeing the WIP state for the announcement webpage, feel free to contact me privately. I'm just not posting it here so that it doesn't end up on Reddit.
Re: KDE Gear 24.02 bug fix releases and next Gear releases
On Monday, November 27, 2023 8:57:26?AM GMT+1 Heiko Becker wrote: > Hi everyone, > > the question of the next Gear release (after 24.02) came up in #kde-devel > yesterday evening. Due to this, it also occured to me that we haven't > scheduled any bug fix releases for 24.02 itself. Which is a bit connected > to the first question, because I guess we don't want too many stable > branches at the same time (as in more than 1 really). > > I mostly see three options, but of course please chime if you think of > something else: > > > a) Continue with the usual dates, eg. 24.04 and 24.08. (or omitting 24.04 > and continue with 24.08 right away) > > b) Continue with the usual interval, so 24.06, 24.10 and so on > > c) Slightly change the interval to come back to the proven schedule with > its nice numbers divisible by 4, so something like, 24.05 and 24.08. > > > Personally, I'd favour b) or c). I think a) is either too short or too > long. Not sure how b) would interact with holiday schedules, exams or > distro releases though. b) would mean the major gear releases and plasma releases would be sort of synchronized as both are once ever 4 months and Plasma releases have been happening in February, June and October. This would mean a return of a megarelease from the KDE 4 times, which is a something I would like to see but it is also a controversial idea. As someone who spend a lot of time on the gear and plasma announcements every 2 months, I personally would prefer to spend even more time on a big announcement every 4 months. Also from a promo perspective, having a bit announcement every 4 months for gear + plasma is more effective than having a less big annoucement every 2 months. This might also be good for distros as from a feature perspective, they can align themselve with one 4 months cycle and not 2 different 4 months cycles. But in any case, that would be worse than the status quo is having the gear and plasma announcement just one week or two appart, as it would be quite unsustainable for the promo team in term of work load. And it means a prolonged period of release stress for us. Additionally the first release would eclipse the second one as tech/linux newspapers/youtubers will only report about the first release and not the second one, because they don't want to publish too much KDE news days appart. So if we don't release the major version of Gear and Plasma at the same time, I would prefer to keep them apart as before and go with a) or c). Cheers, Carl > > Regards, > Heiko
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: Breeze and ECM are incompatible for installing icons
On Friday, November 3, 2023 12:46:20 AM CET Albert Astals Cid wrote:
> El dijous, 2 de novembre de 2023, a les 14:36:16 (CET), David Jarvie va
>
> escriure:
> > Breeze installs its icons in a different directory structure from other
> > icon themes, with the result that the ECM cmake command ecm_install_icons
> > doesn't work for Breeze icons. The only way to install an application
> > specific Breeze icon is to hard code its location, for example
> > "${KDE_INSTALL_ICONDIR}/breeze/actions/22/".
>
> Why are you installing icons in breeze icon theme if you're not the breeze
> icon theme?
>
> Seems wrong to me.
Yes, it's wrong. We made the same mistake in Tokodon and the correct way to do
it is to install in the hicolor theme. This allow the theme to overwrite the
icon if they want and don't force you to hardcode the breeze icon theme.
Re: Bringing Glaxnimate into KDE
On Monday, October 30, 2023 11:43:47 AM CET Mattia Basaglia wrote: > Hi, Hi Matt, > I'm the maintainer of Glaxnimate (https://glaxnimate.mattbas.org/) a > vector graphics animation editor that has been integrated with kdenlive > through the MLT framework. I've been having talks with some of the > kdenlive devs and we came to the conclusion that it would be helpful to > bring Glaxnimate into KDE. > > With the help of jk from kdenlive, we've made the code reuse compliant, > and added some craft jobs to the CI. > > I would need some guidance on how to push this further. First thing first, make sure you have read https://manifesto.kde.org/ commitments/ and https://manifesto.kde.org/benefits/ Then you need to find a sponsor and this mailing list is indeed the right place to do that. I think someone from the Kdenlive team with whom you already interacted (e.g. jk) would be the best for this task. In none of them has the time, I can probably also help. Then create a sysadmin request to move your repo to the KDE infrastructure: https://phabricator.kde.org/maniphest/task/edit/form/2/ And ask to get a KDE developer account in https://identity.kde.org so you can keep your git write access to your project ;) Cheers, Carl > > Thanks, > > Matt
Re: KDE Gear projects with failing CI (release/23.08) (17 October 2023)
I'm a bit confused as to why this was only added to the release/23.08 branch and not master as well. Also the licensing issue was not solved correctly, see the following patch: https://invent.kde.org/accessibility/kontrast/-/commit/17ece874e0f2fda3f8a6553ac7386b911faad405 In the future, please open a merge request. This is the sort of issues that can be easily caught up in code reviews ;) Cheers, Carl On Tue, Oct 17, 2023, at 11:07 PM, Scarlett Moore wrote: > Fixed! > Scarlett > > On Tue, Oct 17, 2023 at 1:54 PM Albert Astals Cid wrote: > > > > Please work on fixing them, otherwise i will remove the failing CI > > jobs on their 4th failing week, it is very important that CI is passing for > > multiple reasons. > > > > Good news: We're down to only 1 non passing repository. > > > > = FAILING UNIT TESTS = > > > > kontrast: (1st week) > > * https://invent.kde.org/accessibility/kontrast/-/pipelines/501951 > > * reuse check is failing > > > > >
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.
Re: KDE Gear projects with failing CI (release/23.08) (8 August 2023)
On Wed, Aug 9, 2023, at 9:44 AM, Johnny Jazeix wrote: > Le mar. 8 août 2023 à 23:24, Albert Astals Cid a écrit : > > > > Please work on fixing them, otherwise i will eventually remove the failing > > CI > > jobs, it is very important that CI is passing for multiple reasons. > > > > This is the first release/23.08 report > > > > = REUSE FAILURES (3 repos) = > > > > partitionmanager: > > * https://invent.kde.org/system/partitionmanager/-/pipelines/456102 > > > > MR done by Carl: > https://invent.kde.org/system/partitionmanager/-/merge_requests/32, > will need to be cherry-picked in release/23.08 once merged. Unfortunately the reuse failure in release/23.08 looks more serious https://invent.kde.org/system/partitionmanager/-/jobs/1107615 No idea why reuse it completely not working on that branch > > kpmcore: > > * https://invent.kde.org/system/kpmcore/-/pipelines/456103 > > > > I've cherry-picked the fix in master, it builds fine now > > > kweather: > > * https://invent.kde.org/utilities/kweather/-/pipelines/456125 > > > > I've cherry-picked the fix in master, now and also the one needed for > Flatpak (runtime upgrade) > > > > > = FLATPAK FAILURES (1 repo) = > > > > calindori: > > * https://invent.kde.org/plasma-mobile/calindori/-/jobs/1106264 > > * I think it should be compiling kcalendarcore from a tag, not a branch > > > > Carl fixed it! > > Cheers, > > Johnny >
Re: Kalm Incubation Request
Hi, Since you are already a kde developer, just create a sysadmin ticket to move this project outside of your personal invent namespace and then send an email to kde-core-de...@kde.org to start the KDE Review process. You don't need the incubation which is to bring external projects (and their contributors) to KDE. Cheers, Carl On Sat, Jul 29, 2023, at 11:25 AM, pl...@mailbox.org wrote: > Hello all, > > I'm looking for a sponsor to incubate Kalm > (https://invent.kde.org/plata/kalm/-/issues/1). > > Kalm visualizes breathing techniques to help you kalm down. > > Currently supported techniques: > - 4-7-8 Breathing > - Coordinated Breathing > - Box Breathing > - Box Breathing (sleep) > - Resonant Breathing > - Nadi Shodhana > - Yogic Breathing > > Currently, I'm the only maintainer. > > Original announcement and screenshots in > https://discuss.kde.org/t/kalm-new-breathing-techniques-app/1941. > > Best regards > Plata >
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
Incubation of KleverNotes
Hi, Just wanted to notify the developer community that I'm sponsoring the incubation of KleverNotes. KleverNotes is a convergent markdown note-taking and management application using Kirigami/QML. I made some contributions to it last week and I think that with a bit more polishing this would be a fantastic addition to KDE. Currently, the code can be found here: https://gitlab.com/schul9louis/klever but I will create a sysadmin task to move it to the office namespace in invent. I created a wiki page to track the progress https://community.kde.org/Incubator/Projects/KleverNotes Speaking of the wiki, I wonder if it would make sense to move the incubation task list to a GitLab task instead of tracking this in a wiki? Cheers, Carl
Re: MR Gardening - A discussion, please leave your input!
Hi, We should never close a MR automatically. Only a maintainer of a project or the author itself should close a MR. The decision if a MR should be closed or not is often depending on a context (e.g. a MR required another MR to be merged first and it is taking more time than expected, the author is busy with other things but will eventually come back to it, ...) and a script is unable to see this. I do not mind poking people semi-regularly (every 6 months or so), but again this should probably be done manually and with a small personalized message for example: "Hi, I really like this work, do you intent to continue working on it or can I take over" than a generic message that feels fake. I really hate communicating with robots instead of with humans and I really see the trends of trying to automatize all our interaction with dumb robots and chat bots in our society really worrying. If we want to automatize, we should instead try to list the stale MRs and maybe send the list to the mailing list once a month so that people are reminded about them and take a look at which one they may be able to unlock. Cheers, Carl --- Original Message --- Le dimanche 5 mars 2023 à 11:13 AM, AnnoyingRains a écrit : > For a short amount of time now, there have been some small-scale > trials of replying to old MRs with a reminder, and suggesting that the > author closes the MR if it is either no longer needed or if it needs > more work and the author does not have time for it. > > This has appeared to have a positive impact on the state of KDE > software from this (albeit limited) trial. Some MRs have had renewed > interest, others have admitted that they had forgotten that the MR > even existed. > > We did consider closing MRs if there was no activity after our ping > message. We are no longer planning on doing this, as it is more > destructive than helpful. All decisions on if a MR should be closed > will be left with the maintainers and the person who opened the MR. > > So, we need a proper discussion about this, should we send these > reminder messages at all? If so, how old should an MR be before > sending this reminder? Should closing the MR even be suggested in the > message? > > If your specific project does not play nicely with this programme, > please let us know and we can add it to the list of exclusions on our > KDE Community page. > > I need your input, > - Kye Potter, KDE Gardening
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: "Gardening" old bugreports
Please exclude from the bug report reminder: koko tokodon kalendar kde.org planet.kde.org www.kde.org season.kde.org KDE Mediawiki and any bug reported by myself as well as the following projects for the MR reminder: koko tokodon kalendar arianna vail arkade basically everything in the websites namespace and any MR created by myself I'm getting already way too many emails and I have an hard time keeping up with them so if I can avoid getting more of them, that would be good. Cheers, Carl --- Original Message --- Le vendredi 27 janvier 2023 à 10:56 PM, Justin Zobel a écrit : > Thanks for the feedback, everyone. > > Given the distribution of positive vs negative feedback, we plan to > resume automatic bug triage of old non-wishlist bugs that have not > been updated in over 2 years. If you would like to opt your product > out of this initiative because you're able to keep on top of the > manual bug triage work, please let us know and we'll be happy to > accommodate you. > > Exclusions so far: > - okteta > - krita > - any bug reported by sit...@kde.org > > Thanks again for the feedback! > > On Sun, Jan 22, 2023 at 6:10 PM Thomas Baumgart t...@net-bembel.de wrote: > > > On Donnerstag, 19. Januar 2023 22:39:45 CET Johannes Zarl-Zierl wrote: > > > > > Hi, > > > > > > Am Donnerstag, 19. Jänner 2023, 12:26:08 CET schrieb Nicolas Fella: > > > > > > > Am 19.01.23 um 04:04 schrieb Justin: > > > > > > > > > The gardening team aims to find out if the bug reports are still > > > > > relevant by involving the users who reported them in determining if > > > > > they are still valid. This increases community involvement and helps > > > > > KDE as there isn't anywhere near enough manpower to review the > > > > > thousands upon thousands of bugs that haven't been touched in years. > > > > > > > > Anecdotally many people don't like such automated changes being done to > > > > their bugreports that don't actually engage with the content of the > > > > report. > > > > > > Well, anecdotally you will mostly get feedback from people who don't like > > > it. > > > Unless something is exceptionally great, few people will take the time to > > > speak out in favor of something that is already happening. > > > > > > > > The bugs that we are interacting with are ones that have not had any > > > > > activity for over 2 years. We are simply trying to reinvigorate > > > > > discussion on those bugs to see if they are still valid. If the user > > > > > does not reply within the standard 30 day period after a bug is set to > > > > > NEEDSINFO, it is automatically closed by the Bug Janitor. > > > > > > > > > > I am not simply closing bugs, so I do take offense that care is not > > > > > applied. > > > > > > > > Properly "triaging" old reports requires at least some level of > > > > understanding of the project, codebase etc. I'm afraid there is no > > > > simple solution to that and rule-based approaches aren't good enough. > > > > Even taking things like CONFIRMED status or wishlist priority into > > > > account assumes that these have actually been consistently applied. > > > > > > As a maintainer on a small project, I'm quite happy to get an occasional > > > nudge > > > on old reports. Yes, I do occasionally go over old reports to see if they > > > are > > > still valid, but having somebody else doing this methodically makes sure I > > > don't gloss over some bug that could be closed or fixed. > > > > > > Having this done by someone else without too much internal knowledge is an > > > absolute plus in my opinion. After all, if you want to clean up your > > > attic, > > > you try to find a helper who does not have the same emotional attachment > > > as > > > yourself. > > > > > > > > I will halt it until it is approved by more developers. However if it > > > > > is decided that it isn't wanted then the KDE as a whole will need to > > > > > entice more people in sorting old bugs individually as it is clearly > > > > > not a priority right now for the majority. > > > > > > Speaking for KPhotoAlbum, I really appreciate the bugzilla gardening. > > > Thank > > > you for doing it! > > > > I can second that for the KMyMoney project. An occasional poke and the > > automated cleanup when no response arrives where it is needed helps a lot. > > > > -- > > > > Regards > > > > Thomas Baumgart > > > > - > > With every day I come closer to the grave and learn something new. > > It all happens because I have wandered around too much and stumbled into > > the Linux world - which is a fantastic place to be! (Algis Kabaila †) > > -
Re : VDG application design sprint?
Le mardi 24 janvier 2023 à 12:43 AM, Nicolas Fella a écrit : > Hi, > > I think it would make sense for us to have a VDG sprint of sorts in the > near-ish future. This would allow to discuss some larger design topics > and set a vision for the longer-term future. I believe this is important > for us to be able to work together effectively. > > I'd suggest to focus on application design topics, like layout, > structure, and arrangement of apps, and less on things like Plasma and > styles/themes. I'd also suggest to approach this more from a design/UX > PoV and don't let us be driven by implementation details. But these are > just my suggestions that are subject to debate. > > Time/place/modality is all to be discussed, I'm mainly writing this to > gauge interest, so if you are interested let me know. Count me in :) Cheers, Carl > Cheers > > Nicolas
Re: [GSoC Mentors] GSoC 2023 open for org applications January 23 - February 7
Hi, I added 2 ideas for Kalendar. Cheers, Carl --- Original Message --- Le dimanche 22 janvier 2023 à 10:22 AM, Johnny Jazeix a écrit : > Hi, > > org applications start tomorrow and there is no idea at all in the page > (https://community.kde.org/GSoC/2023/Ideas). Are we interested to participate > to GSoC this year? > > Cheers, > > Johnny > > Le mar. 10 janv. 2023 à 21:58, Johnny Jazeix a écrit : > >> Hi, >> >> Are there people willing to help co-admin this year? For now, we are 3 >> admins so one more would be nice to share the workload. >> >> I've updated the skeleton wiki page to create the 2023 season: >> https://community.kde.org/GSoC/2023/Ideas. >> >> Please start discussing among your teams what ideas will be great to have >> this year and who is willing to mentor, as the organisation application date >> needs to apply between the January 23 - Feb 7, 2023 and we need a wiki page >> filled with ideas by then. >> >> More info can be found at >> https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html >> >> Cheers, >> >> Johnny >> >> -- Forwarded message - >> De : 'sttaylor' via Google Summer of Code Mentors List >> >> Date: lun. 14 nov. 2022 à 23:51 >> Subject: [GSoC Mentors] GSoC 2023 open for org applications January 23 - >> February 7 >> To: Google Summer of Code Mentors List >> >> >> We’re pleased to >> [announce](https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html) >> the Google Summer of Code 2023 program and >> [timeline](https://developers.google.com/open-source/gsoc/timeline). GSoC >> Org Applications are open from January 23 - Feb 7, 2023. >> >> In 2022 we implemented our biggest changes to the program in its 18 year >> history and had an overwhelmingly positive response to the changes (extended >> timelines, medium and large size projects and opening eligibility beyond >> students) so we are keeping the changes as we go into 2023 with a couple of >> minor tweaks. >> >> - >> >> Per the conversation on the mentor list this summer, we are expanding the >> eligibility to include students and beginners to open source development. >> There was some confusion about students who might have some experience in >> open source so we have fixed that with this new eligibility rule. >> >> - >> >> The other change is that we are back to allowing a person to be accepted as >> a GSoC Contributor up to 2 times (regardless of when their first GSoC >> acceptance was). This assumes they could still be considered a beginner - >> ie. they didn’t participate as a GSoC student in 2015 and have been actively >> involved in open source development since then and want to come back 8 years >> later to be a GSoC Contributor. >> >> - >> >> We have shifted the timeline to start a couple of weeks earlier, so that the >> program wraps up for the standard 12 week projects by early September which >> is generally what the schedule looked like for many of the past 18 years. >> >> Spreading the word about GSoC >> >> The [GSoC 2023 >> flyer](https://developers.google.com/open-source/gsoc/resources/downloads/GSoC2023Flyer.pdf) >> and the new, more colorful and exciting [GSoC 2023 >> slides](https://developers.google.com/open-source/gsoc/resources/downloads/GSoC2023Presentation.pdf) >> are available for you to use in any presentations you wish to do about >> GSoC. We need your help to spread the word amongst your circles. >> >> We encourage you to explore our >> [resources](https://developers.google.com/open-source/gsoc/resources/),[timeline](https://developers.google.com/open-source/gsoc/timeline), >> the [Contributor/Student >> Guide](https://google.github.io/gsocguides/student/)and [Mentor >> Guide](https://google.github.io/gsocguides/mentor/) as well. >> >> Have a group you think GSoC Program Admins should reach out to? >> >> Diversity in open source communities is vital to the health of our >> communities. Please spread the word about GSoC to communities in your >> country or in your network particularly those that reach underrepresented >> groups in open source. If you have a suggestion for a group you think the >> GSoC team should add to our list of contacts that we send out emails to >> about the program early in the new year, or if you have a group that you >> think would be a good opportunity for GSoC Administrators to give a talk >> about GSoC please email us at gsoc-supp...@google.com with their details >> (email and contact person if you have one available). >> >> See you at FOSDEM! >> >> As Chris mentioned in the GSoC 22 Mentor Summit a couple of weeks ago, our >> team is very excited to attend FOSDEM in Brussels in 2023. We will send more >> details in January but we are in the early stages of planning a GSoC Meetup >> for Saturday night during FOSDEM as we have done in previous years. Looking >> forward to seeing many of you in Brussels in February! >> >> GSoC Videos
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: Request for Sponsor for Project ghostwriter
Le dimanche 18 septembre 2022 à 2:10 AM, a écrit : > Hello, Hi and welcome, > I would like to request a sponsor for incubating my existing Qt project, > ghostwriter. ghostwriter is a Markdown editor that aims to provide a > relaxing, distraction-free writing environment. It's a really nice project and I'm willing to sponsor it. I'll send you in a seperate email with the next steps to not being to noisy on the mailing list. Cheers, Carl > Project GitHub Repo: https://github.com/wereturtle/ghostwriter > Project Website: https://wereturtle.github.io/ghostwriter > > Maintainter Committing to the Project: > > - Megan Conkle > > Planned KDE Manifesto Compliance: > > Open Governance: I would like to open ghostwriter's governance to the KDE > community in general to help limit the bus factor and share the load. > > Free Software: ghostwriter is already licensed under GPL3. Various > third-party libraries and artwork in use by the project have GPL3-compatible > licenses. While it is presently hosted on GitHub, I would like to transition > it to KDE Invent's GitLab server as it's new home, and to take advantage of > KDE's releases/CI rather continuing to use GitHub Actions or AppVeyor for > releases. > > Inclusivity: Anyone can participate! > > Innovation: ghostwriter is always improving, and by incubating the project > with KDE, I hope that it can include KDE frameworks innovations and other > people's ideas/contributions. > > Common Ownership: I would like to increase the bus factor for the project by > asking the KDE community to share ownership and contribute. > > End-User Focus: In addition to ensuring a smooth user experience, > ghostwriter's goals include providing translates of its interface text into > as many languages as possible, and always keeping accessibility in mind. To > meet these goals, the project will transition from using Qt Linguist to il8n. > Other KDE framework APIs will be evaluated as well, such as Sonnet for spell > checking. > > Thank you very much for your time! > > Megan Conkle
Re: incubating kdsoap-ws-discovery-client
Le lundi 12 septembre 2022 à 10:19 PM, Albert Astals Cid a écrit : > El dilluns, 12 de setembre de 2022, a les 16:13:24 (CEST), Harald Sitter va > escriure: > > > Hola, > > > > I'm going to incubate kdsoap-ws-discovery-client [1] as a KDE project. > > It's a critical piece of our smb infrastructure. Nate kindly agreed to > > be my sponsor (: > > > > [1] https://gitlab.com/caspermeijn/kdsoap-ws-discovery-client > > > Does this mean we're going to fork it? > > Or you have Casper's agreement that he will shut down the gitlab repo? Looks like there was an agreement in https://gitlab.com/caspermeijn/kdsoap-ws-discovery-client/-/merge_requests/17#note_1095779523 Cheers, Carl > > Cheers, > Albert > > > HS > > > >
Re: kdesrc -- stuck building kwayland
Le lundi 12 septembre 2022 à 7:08 PM, Thiago Macieira a écrit : > On Monday, 12 September 2022 08:55:10 PDT Nicola Mingotti wrote: > > > Therefore it seems the wisest option to me to wait till you guys update the > > CMakeLists.txt. > > > That's simply going to make the build fail earlier, with a different but more > meaningful error message. > > You need Wayland 1.20 if you want to build this version of kwayland. > > > Thank you for kdesrc, there are a few quirks but in general it is great we > > can try new stuff in a stable system ! > > > That's not always possible. This is such a case. You'll need an upgrade. Or you can compile your own wayland in the same prefix as the rest of KDE. If the new wayland version doesn't need other updated dependencies this might be a viable alternative. Cheers, Carl > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel DCAI Cloud Engineering >
Re: akonadi won't start
Le jeudi 14 juillet 2022 à 9:31 AM, Robert Voinea a écrit :
> Hello
>
> I have encountered the same situation some time ago.
> I'm on Archlinux and it happened after an update of mariadb.
>
> If you try to start mysqld by hand, you'll see that it is trying to open a
> file that is not there.
> Creating that file allowed mysqld to start.
> I can't remember the name of that file though... and it had nothing to do with
> mysqld.conf
yes and this was fixed in
https://invent.kde.org/pim/akonadi/-/commit/aebb20a082d05b36458008fedff4397f022c3ffa
>
>
> On Thursday, 14 July 2022 01:53:08 EEST Mike Diehl wrote:
>
> > Hi all.
> >
> > I posted this to the user's group some time ago. It was suggested that I
> > post to the dev group. So, here I go.
> >
> > I'm having trouble getting akonadi to start. When I try to start it, I get
> > this error message:
> >
> > $ akonadictl start
> > Connecting to deprecated signal
> > QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
> > mdiehl@mikeworkstation:~$ org.kde.pim.akonadiserver: Starting up the
> > Akonadi Server... mysqld-akonadi: [ERROR] Failed to open required defaults
> > file: /home/mdiehl/ mysqld-akonadi: [ERROR] Fatal error in defaults
> > handling. Program aborted! org.kde.pim.akonadiserver: database server
> > stopped unexpectedly
> > org.kde.pim.akonadiserver: Database process exited unexpectedly during
> > initial connection! org.kde.pim.akonadiserver: executable:
> > "/usr/sbin/mysqld-akonadi"
> > org.kde.pim.akonadiserver: arguments:
> > ("--defaults-file=/home/mdiehl/.local/share/akonadi/mysql.conf",
> > "--datadir=/home/mdiehl/.local/share/akonadi/db_data/",
> > "--socket=/run/user/1000/akonadi/mysql.socket",
> > "--pid-file=/run/user/1000/akonadi/mysq l.pid")
> > org.kde.pim.akonadiserver: stdout: ""
> > org.kde.pim.akonadiserver: stderr: "mysqld-akonadi: [ERROR] Failed to open
> > required defaults file: /home/mdiehl/.local/share/akonadi/mysql.conf
> > mysqld-akonadi: [ERROR] Fatal error in defaults handling. Program aborted!"
> > org.kde.pim.akonadiserver: exit code: 1
> > org.kde.pim.akonadiserver: process error: "Unknown error"
> > mysqladmin: connect to server at 'localhost' failed
> > error: 'Can't connect to local MySQL server through socket
> > '/run/user/1000/akonadi/mysql.socket' (2)' Check that mysqld is running and
> > that the socket: '/run/user/1000/akonadi/mysql.socket' exists!
> > org.kde.pim.akonadiserver: Failed to remove runtime connection config file
> > org.kde.pim.akonadiserver: Shutting down AkonadiServer...
> > org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited
> > normally...
> >
> > I can confirm that /home/mdiehl/.local/share/akonadi/mysql.conf does exist
> > and has readable permissions.
> >
> > Any suggestions would be most appreciated.
> >
> > Mike
>
>
>
> --
> Robert Voinea
> Software Engineer
> +4 0740 467 262
>
> Don't take life too seriously. You'll never get out of it alive.
> (Elbert Hubbard)
KDE Gear 22.08 announcement preparation
Hi, The 22.08 release is approaching and the promo needs your help in compiling interesting new features in this release. If you have anything noteworthy, please add it to https://collaborate.kde.org/s/wESNQmM9eb5fq85 . As a general reminder, a noteworthy thing is something that non-technical users are able to understand and not a small bug fix. Ideally add a link to either a commit, bug report, or/and phab task and a screenshot (to put in the Images subfolder). Thanks for helping, Carl Schwan https://carlschwan.eu
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 : Re: NetworkManagerQt
Le vendredi 27 mai 2022 à 10:03 PM, Nicolas Fella a écrit : > Hi, > > On 27/05/2022 17:35, Kovour, Sathyanarayana wrote: > >> Hi >> >> My name is Sathya Kovour, I am part of Baxter International, a medical >> device manufacturer. >> >> We come across NetworkManagerQt >> https://marketplace.qt.io/products/networkmanagerqt, and we have a few >> questions while we are making decision to use this very convenient modules >> in our project. >> >> - As per above link this project is accessible for us with LGPL v2.1+. >> According to our legal department this is very restrictive for our >> distribution scenarios. I am wondering if you offer any additional licenses >> for this project to be used in our commercial setup without copy left clause. > > The short answer is: No. > > The longer answer is: To do this one would need to contact all of the > contributors/copyright holders and ask them to agree to a new license. That > is doable in theory but prohibitively difficult in practice. In adition to that Nicolas already said, you might want to double check if the LGPL 2.1 license is really to restrictive for your distributions scenarios. The LGPL 2.1 is more permissive than the normal GPL 2 and the LGPL 3 and as been specially be developed to be integrated inside proprietary projects. I'm not a layer, but the key requirement for the LGPL 2.1 license is that you link the library with your project using dynamic linking, add a link to the source code and if you do modification to the library, you also need to publish your modification to the library. The rest of your project is not affected by the copy left clause. I hope this helps, Cheers, Carl >> I understand Linux Network Manager 1.16 support WPA3, does NetworkManagerQt >> enables us to use WPA3 capabilities if we have a compatible network manager >> installed on our embedded system? > > Without knowing all of the details I'd say: yes, probably. And even if there > are missing things for this in networkmanager-qt those should be easy enough > to add. > >> A quick reply is highly appreciated. >> >> Thanks >> >> Sathya > > Cheers > > Nicolas
Re: KDE Incubator: Telly Skout Sponsor
Hi, An EPG is a TV guide application. https://en.m.wikipedia.org/wiki/Electronic_program_guide I agree that using 'TV guide' instead of EPG is a bit clearer :) Cheers, Carl Original Message On May 5, 2022, 00:53, Aleix Pol < aleix...@kde.org> wrote: > > > Hi Plata, > Would you be able to explain a bit what a "Convergent EPG" is? > > Aleix > > On Wed, Apr 27, 2022 at 11:53 PM Albert Astals Cid wrote: > > > > El dilluns, 25 d’abril de 2022, a les 18:09:42 (CEST), Plata va escriure: > > > Hello, > > > > Hi. > > > > > I'm developing Telly Skout, a convergent Kirigami based EPG > > > (https://invent.kde.org/plata/telly-skout). > > > I started developing this because I was missing an EPG to daily drive > > > Plasma Mobile (coming from Android). > > > Currently, I'm the only committer but I hope that this might change now > > > after moving to KDE Invent from GitHub. > > > I would love to see Telly Skout becoming part of Plasma (Mobile) Gear. > > > Therefore, I'm looking for a sponsor. > > > > That's great :) We can always use more developers in KDE. Welcome! > > I'm not super experienced myself on Plasma Mobile, so I'd suggest you to > > drop in their Matrix channel (or mailing list) and ask there > > https://plasma-mobile.org/join/ > > If you don't have any luck I will help you, after all the incubating part > > is relatively generic for most of the KDE parts. > > > > Cheers, > > Albert > > > > > Best regards > > > Plata
Re : Re: KF6 meeting notes 2021-12-07
Le mercredi 8 décembre 2021 à 11:26 AM, David Redondo a écrit : > Am Dienstag, 7. Dezember 2021, 18:04:19 CET schrieb Volker Krause: > > > https://phabricator.kde.org/T11587 > > > > - there are bigger plans to rework color scheming, this needs more > > coordination with the effort to down-tier this for KF6 > > - would likely mean only storing the color scheme name in kdeglobals > > rather > > than actual colors > > I actually started a branch to use QSettings instead of KConfig for > KColorScheme with some changes to the public API that does this. > https://invent.kde.org/frameworks/kconfigwidgets/-/commits/work/davidre/ > qsettings/ > > > - do we need per color cascading or is that rather a bug? compare e.g. > > to > > Kate's syntax highlighting themes. > > This does away with per color cascading, and imo there's not much use > case for > it. When introducing the Header color set extra effort was taken to NOT > have > > cascading for those. Also Plasma will only allow creating full color > schemes > from the gui iirc. Cascading of color scheme doesn't really make sense and is actually causing problems with the Header when an application allows to overwrite the theme (e.g. neochat, elisa, ...) but the app theme used doesn't have a Header role defined, then you get a mix of two themes and it's a bit broken. There was an attempt to fix this here: https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/52
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: Respin request Kirigami
Le lundi 11 octobre 2021 à 12:56 PM, David Faure a écrit : > On lundi 11 octobre 2021 12:46:04 CEST Carl Schwan wrote: > > > I don't think it is so urgent that we need a 5.87.1 version of > > Kirigami. So it can't wait a month. > > Do you mean "it can't wait" or "it can wait"? It can wait. Sorry for the confusion :/ > > > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5
Re: Respin request Kirigami
Le lundi 11 octobre 2021 à 11:43 AM, David Faure a écrit : > On lundi 4 octobre 2021 12:39:35 CEST Carl Schwan wrote: > > > Please include > > https://invent.kde.org/frameworks/kirigami/-/commit/e7ffa04038307efef10c168 > > 2042e795d4a32a935 > > > > This fixes some nasty bugs for the Kirigami settings component. > > Hello Carl, > I missed this email. > Please send respin requests to release-t...@kde.org Sorry I didn't know. I wil do that the next time. > I suppose a 5.87.1 version of kirigami is needed then? I don't think it is so urgent that we need a 5.87.1 version of Kirigami. So it can't wait a month. It's just impacting Kalendar (not released), Koko (we already reverted the patch porting to Kirigami.SettingPage) and NeoChat (we can wait before porting from the existing vendored SettingPage component to the new upstream one). Regards Carl > > - > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5
Respin request Kirigami
Hello, Please include https://invent.kde.org/frameworks/kirigami/-/commit/e7ffa04038307efef10c1682042e795d4a32a935 This fixes some nasty bugs for the Kirigami settings component. Carl Schwan https://carlschwan.eu
Re: QML API docs for C++ wrapper types?
Le vendredi 17 septembre 2021 à 3:23 PM, Volker Krause a écrit : > Hi, > do we have an example somewhere how to do API docs markup properly for C++ > wrappers for QML APIs? I don't think we have and it's currently with Doxygen a bit hard to do something similar to the Qt documentation with a separate list of C++ types and one of QML types (with a link from the QML types to the C++ types). I'm not sure that is the best way forward with this issue. This would be two possibilities: * Use QDoc. There is already basic support for QDoc inside KApidox thanks to Jannet. This would need more work and I'm not sure how stuff like dependencies are handled. More importantly, moving to QDoc is a **lot** of work to port the doc comments to the QDoc syntax and would need some work in QDoc to also support doc comments inside .h files (I talked with upstream during the Qt Contributor submit and they are fine with us adding this feature as an option). * Continuing using Doxygen. This would be less work, we could use custom doxygen commands for indicating in a unified way how to import the component. More problematic would be the case of classes that can be used from both QML and C++. Should we display in these cases the documentation for both the QML usage and C++ usage? There are also issues that documenting pure QML construct (attached properties, nested properties, ...) is hard and the way this is currently done with DoxyQML is hacky and probably would need first-class support in Doxygen. For now in your merge requests, I would probably put some information in the readme/additional doc page that the library is usable from QML. Your latest blog post about the Notification QML with some small changes could be a great starting point for this. It's not perfect but at least it's documented and can be found. Cheers, Carl > > Thinking about cases like these: > https://invent.kde.org/frameworks/knotifications/-/merge_requests/49/ > diffs#aa15f1228c0fb7ecaaa96bb9d8d843ef37033c2b_0_12 > https://invent.kde.org/frameworks/ki18n/-/merge_requests/19/ > diffs#31824e8758f678d4b04f3f329c208c8df64f5e25_0_33 > https://invent.kde.org/frameworks/syntax-highlighting/-/blob/master/src/quick/ > repositorywrapper.h#L20 > > How can I make those show up as they actually look like from a QML POV, ie. > with their exported type names etc? > > Thanks, > Volker
Re : KApiDox move from dedicated server to Jenkins
Le vendredi 10 septembre 2021 à 7:23 PM, Frederik Schwarzer a écrit : > Hi, Hi :D > we have been working on getting KApiDox to run on Jenkins. This work has > been taken way longer than I expected but has now reached a state close > to finished. :) > > So I would like to invite you to check https://api-dev.kde.org/ for any > show stoppers. Great work :D I see on an issue that I would qualify as blocking and it's the lack of the ECM generated doc: https://api-dev.kde.org/ecm. We are also losing the kube/sink doc (located at api.kde.org/doc/sink) but it's also available in readthedocs and ihmo it should be in Doxygen format. We also are losing the krita/kmymoney/other app private api generation, but that maybe can be generated in another ci pipeline later. Not sure how much thses apps' developers are using it. On the upside, I see that mauikit doc is finally correctly generated using qdoc. Yeah \o/ Cheers, Carl > > Known issues (not show stoppers): > > - For now the Maintainers field defaults to "KDE Developers" for > potential GDPR violation reasons, which needs to be figured out later. > - Some modules contain formatting issues regarding markdown code blocks. > These are also there in the current system and need to be checked at > some point. > - The "Older versions" links are broken. Since those docs are not > generated anymore, we need to figure out a way to have them available > statically. > > If we do not see any bigger issues, I would like to go live with the new > system in a week or two. > > Thanks for your help. > > CHeers, > Frederik
Re : KConfigXT generated class gets value from kdeglobals config file
Le dimanche 8 août 2021 à 11:15 PM, George Florea Banus a écrit : > In my app I'm using KConfigXT for my settings. > I have a general group and in it I have a ColorScheme entry. > Now when there is no ColorScheme set by the user and I try to access > this entry, instead of getting its default value it gets the value > stored in `~/.config/kdeglobals` (which also has a ColorScheme entry > under the General group). > https://invent.kde.org/multimedia/haruna/-/blob/master/src/settings/generalsettings.kcfg#L46 > https://invent.kde.org/multimedia/haruna/-/blob/master/src/settings/generalsettings.kcfgc > Any ideas how to prevent this? I'd rather not change the name of the > entry or the group. Hi, when creating a KSharedConfig, you can specify if kdeglobals will be read and then you can tell KConfigXT that you want to read from an existing KSharedPtr: https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html On another note, for color scheme handling in a QML app, this is how I did it in NeoChat: https://invent.kde.org/network/neochat/-/blob/master/imports/NeoChat/Settings/ColorScheme.qml and https://invent.kde.org/network/neochat/-/blob/master/src/colorschemer.h This allows the user to override the color scheme while using by default the system theme. Cheers, Carl
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: Incubating linux-stopmotion
Le mercredi, avril 7, 2021 9:45 PM, Christoph Grüninger a écrit : > Dear KDE team, Hi :) > I would like to apply for linux-stopmotion to become a KDE project. > > == Project description == > Linux Stopmotion is a Free Open Source application to create stop-motion > animations. It helps you capture and edit the frames of your animation > and export them as a single file. > Direct capture from webcams, MiniDV cameras, and DSLR cameras. It offers > onion-skinning, import images from disk, and time lapse photography. LSM > supports multiple scenes, frame editing, basic sound track, animation > playback at different frame rates, and GIMP integration for image. > Movies can be exported to a file and to Cinelerra frame lists. > Technically, it is a C++ / Qt application with optional dependencies to > camera capture libraries. > LSM is part of DebianEdu; LSM packages are available for at least Debian > and openSuse. > Website: linuxstopmotion.org > Git / Mailing list: sourceforge.net/projects/linuxstopmotion/ > > == List of people committing to the project == > Tim Band > Christoph Grüninger > > == Plan to be in compliance with the KDE manifesto == > We already comply wih the KDE manifesto - except for the infrastructure. > We plan to > > - move over to KDE's Git repository This sounds like a very nice project. I'm willing to mentor you. The next step would be to move your repository to invent and get you and Cristoph write access to the KDE repos. Can you and Christoph in identity.kde.org create a developer application and add me as the sponsor (also mention that this is part of the incubation process)? I will create the sysadmin request to create the repo. > - switch to a mailing list within KDE's infrastructure > - use KDE bug tracker > - see what else makes sense for the project like Phabricator > Maybe we have to change the name of the application. You don't need to have a K in your application name to be a KDE application :) Cheers, Carl > Kind regards, > Christoph >
KDE Gear promotion material
Hello everyone, The release of KDE Gear 21.04 is approaching and it would be nice if developers could help promo by adding the new features and bugfixes in the app they are maintaining in the following file: https://invent.kde.org/websites/kde-org/-/edit/work/gear-2104/content/announcements/gear/21.04.md?from_merge_request_iid=85 It doesn't needs to be elaborate and can just be a list of MR/commits/ bugreports closed/... Thanks, Carl
Re: Koko in KDEReview
Le dimanche, mars 14, 2021 1:03 AM, Carl Schwan a écrit : > Le dimanche, mars 14, 2021 12:22 AM, Albert Astals Cid aa...@kde.org a écrit : > > > El dissabte, 13 de març de 2021, a les 20:14:26 CET, Carl Schwan va > > escriure: > > > > > Hi, > > > I would like to move Koko to KDEReview. Koko is a convergent image > > > viewer that works on both Plasma Desktop and Plasma Mobile. It's the > > > second try of Koko in KDEReview, the first try failed1 because Koko > > > didn't really worked with traditional packaging and was too focused > > > on the mobile usecase. > > > Since the first attempt, a lot of things changed. There is now > > > packaging instructions in the readme, and a lot of features have > > > been added: > > > > > > - Simple image editor > > > - Metadata editing and viewing (contributed by Mikel) > > > - Slideshow (contributed by Mike) > > > - Allow to open images from Dolphin with Koko > > > - Better share dialog > > > - Better file browsing (contributed by Mikel and me) > > > - Remote folder browsing with KIO > > > - Better indexing with live updates (contributed by Mikel) > > > - Bookmark folders (contributed by Mikel) > > > - Support of animated images (contributed by Mikel and me) > > > - Make it possible to add pictures to favorites (contributed by Mikel) > > > > > > There are additionally two features that will hopefully be added soon: > > > > > > - File operation (copy, move, delete, ...) > > > - A better single image editor. Currently it is using simple QImage > > > manipulation with a command pattern but to make it a bit more powerful > > > and to support filters and other useful features this won't work. So > > > I have been experimenting with glsl shaders and then rendering the > > > image in an offscreen windows and another way and probably the safest > > > one > > > in term of maintenance and features of using the gegl library from > > > GIMP. > > > I would appreciate some opinions about that. > > > > > > > > > The repo: https://invent.kde.org/graphics/koko > > > The repo for the image editor: > > > https://invent.kde.org/libraries/kquickimageeditor/ > > > (required for koko to run) > > > > These two seem like should be fixable relatively easily > > QCommandLineParser: already having an option named "h" > > QCommandLineParser: already having an option named "help-all" > > QCommandLineParser: already having an option named "v" > > qrc:/qml/SelectionDelegateHighlight.qml:13: TypeError: Cannot read property > > 'z' of undefined > > done > > > While watching a photo in a folder, if i press Fullscreen i lose keyboard > > navigation with left/right arrows > > Fixedhttps://invent.kde.org/graphics/koko/commit/dfa608bd127e3108993edb7728e2d1954ed59cab > > > The "Select All" button does nothing? Or i don't understand what it does > > ^_^ Ahhh i see, it only selects images, not folders, that's a bit > > confusing. Maybe rename to Select All Images? Or it will be too long? > > Using "Select All Images" is a good idea I think. At least when no image is > selected and it's the only button in the toolbar. I will ask VDG for their > opinion tomorrow. > > > I would like to be able to move myself around in the "folder view" with the > > keyboard, but i understand that if this is mainly mobile oriented that's > > probably not so important. > > Keyboard navigation has been something Mikel and I have been focused on, but > the keyboard navigation in grid view has been more of a challenge I would > have hoped. For some reasons the focus chain never go to the grid view :( I > will try to investigate more. This should be almost fixed now. Koko should now be fully keyboard navigable, but there is still room for progress. > > > I would really like if we had a kxmlgui equivalent for QtQuick that gave me > > the "configure shortcuts" and stuff functionality, but that's unrelated to > > koko :) > > Same (and also editable toolbars) :) I might give it a try somedays > > > Cheers, > > Albert > > > > > Cheers, > > > Carl
Re: Koko in KDEReview
Le mardi, mars 16, 2021 12:55 PM, Harald Sitter a écrit :
> On Tue, Mar 16, 2021 at 12:49 PM Harald Sitter sit...@kde.org wrote:
>
> > Yay!
Thanks for the big review :)
> >
> > - please get a bugzilla produce created for it
Not a fan of that. This will ends up exactly like the www bugs, something
that I look into every 6 months. We already have many issues opened in
invent and it's working fine for us. Also we don't use KCrash.
> > - COPYING-CMAKE-SCRIPTS seems unused
removed
> > - the find_package calls on qt5 probably should be versioned on
> > whatever version you actually tested with, currently it's unversioned
> > which I doubt is correct
> >
> > - same for kquickimageeditor
Fixed
> > - kquickimageeditor is found with an empty COMPONENTS list. is that
> > intentional?
I think I fixed it. The CMake code is inspired by some random stuff I found in
the frameworks, this is probably why...
> > - unless you specifically target kf5.70 it might make sense to bump to
> > .79 and use KDEGitCommitHooks so clang-format is more consistently
> > applied
Done
> > - kdtree.{c,h} references BSD-3-Clause but that license isn't in the
> > source
Done
> > - on the topic of licensing: since the code base is really close to
> > complete reuse coverage it might be nice to push it over the finishing
> > line and then `reuse lint` it to not have it fall behind again
This will be a bit tricky since the remaining files were not written by any
current contributors. I could try to contact the old contributors.
> > - some classes have trivial constructors/destructors and could use
> > =default (e.g. roles.cpp, types.cpp, processor.cpp, openfilemodel.cpp,
> > probably others)
Fixed
> >
> > - some of those are further QObjects that have a parent signature but
> > don't delegate construction correctly (i.e. the parent arg is never
> > forwarded to QObject). since they are also trivial the constructors
> > could be removed and replaced by `using QObject::QObject;` to adopt
> > QObject's ctors (e.g. roles.cpp, types.cpp)
Fixed
> >
> > - some of the .h's have `parent = 0`, it'd be nice to have them use
> > nullptr instead
Done
> >
> > - some functions take references when they should take const refs
> > (e.g. `void setPath(QString )` or the ImageProcessorRunnable ctor)
> > this suggests they mutate the object, but really the mentioned
> > functions don't
Done
> >
> > - for future reference: .appdata.xml is a legacy suffix and
> > .metainfo.xml ought to be used instead. alas, no point changing this
> > now to avoid extra work for the i18n team
> >
> > - the appstream file must use the CDN not a wiki for screenshots
> > https://invent.kde.org/websites/product-screenshots
Done
> >
> > - also generally speaking please don't generate or use thumbs for
> > appstream files, appstream-generator will thumbnail the raw images
> > during assembling stage on the distro side of things
> >
> > - appstream data has a help link that goes nowhere
> >
> > While koko is running, if I copy a file with geodata to the pictures
> > dir it crashes on `kd_insert3 (tree=0x0,` supposedly because the
> > geocoder had been deinit()'d while it was still running. most notably
> > Processor (which is the gui thread) calls deinit on the geocoder
> > (which is used from various runner threads). in point of fact,
> > glancing over the code I'm not convinced this is actually correctly
> > threading
> > ImageProcessorRunnable is a runnable that is put into the thread pool.
> > Inside its run there's
> >
> > if (!m_geoCoder->initialized()) {
> > m_geoCoder->init();
> > }
> >
> >
> > This is racing code. In between the call to initialized() and the
> > init() another thread might have done init() already. At best that is
> > leaking kd_create instances, at worst that crashes on one of the many
> > asserts on members. On top of that Processor then also calls into
> > deinit() from its thread which might be at any point in time while the
> > Runnable's run() runs. The entire construct is lacking any sort of
> > appreciation for thread synchronization. This needs at least a mutex
> > to synchronize the init/deinit and possibly lookup if kd_* is not
> > thread safe.
> > I am not sure if the init-deinit dance is really adding much value
> > here. If it isn't I might just do away with the deinit TBH.
> > HS
This code is now using a ReadWriteLock. This should fix the racing code.
>
> Oh! Three follow ups:
>
> - is it intentional that this isn't a uniqueapp [1]? do multiple
> concurrent koko instances even work with the database?
It is intentional since users can open image from Dolphin while Koko is
already running. Maybe I could look into using KDSingleApplication for
this usecase. Also multiple koko instances seems to be working in my
experience but I didn't really test that in details.
>
> - the
Re: 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
Re: Getting involved in SoK
Hi, Le mercredi, novembre 18, 2020 5:07 AM, Aleix Pol a écrit : > Including Timothée who will be co-mentoring the project. :) > > Aleix > > On Wed, Nov 18, 2020 at 5:03 AM Aleix Pol aleix...@kde.org wrote: > > > On Sun, Nov 15, 2020 at 10:42 AM Mariam Fahmy mariamfahm...@gmail.com wrote: > > > > > Hello, > > > Thanks alot for helping me. > > > I have basically understand what you have provided me, what next step > > > shall I do to start in this project? > > > Thanks in advance. > > > On Mon, 9 Nov 2020, 3:40 pm Aleix Pol, aleix...@kde.org wrote: > > > > > > > On Fri, Nov 6, 2020 at 7:37 PM Mariam Fahmy mariamfahm...@gmail.com > > > > wrote: > > > > > > > > > Hello, > > > > > Thanks alot for your advice. > > > > > I have installed the project locally and I start discovering how > > > > > backends work with codebase. > > > > > I have understood but I am missing things. > > > > > After doing some research and gathering information, here's what I > > > > > can't clearly understand: (Sorry if questions are little bit silly) > > > > > > > > Hi Mariam, > > > > No need to worry, feel free to ask away. > > > > > > > > > 1- what does it mean by resource? > > > > > When I searched about it, I found that resources may be data required > > > > > by user or requests from clients, is it right ? > > > > > > > > You can see here the class that defines a resource, should help you > > > > see what it represents: > > > > https://invent.kde.org/plasma/discover/-/blob/master/libdiscover/resources/AbstractResource.h > > > > In general, it's an asset: be it an application, a wallpaper or > > > > anything that can be listed and installed. > > > > > > > > > 2- to create a new resources backend we need to implement two classes, > > > > > The first class is the basic class which saves all created resources > > > > > and install & remove application or cancel transactions. > > > > > The second class, I didn't understand it's functionality, I found > > > > > that it is related to plugins but didn't understand it. > > > > > > > > The second important one is the resource I just mentioned above. > > > > Please explain a bit more what you don't understand. > > > > > > > > > 3-Filters in the base class: its target to filter the new requested > > > > > resources? > > > > > > > > filters we just use when searching, to see what's being searched. > > > > In the case of this project it shouldn't be very important, since we > > > > will just be listing a system image. > > > > > > > > > 4- for each new resource backend, it should include all the methods > > > > > of base class, right? > > > > > As these methods acts as properties for each new resource. > > > > > > > > You need to implement all the abstract (i.e. virtual = 0) methods. The > > > > rest of virtuals you can override if you want to give it a different > > > > functionality. > > > > > > > > > 5- I have searched about plugins, but I didn't fully understand it, > > > > > plugins enable programmers to update host program while keeping the > > > > > user within the program's environment, but I can't understand what is > > > > > the role of plugins here if we receive new requests and make new > > > > > resources? > > > > > It is meant that while creating a new resource, we need plugin in > > > > > order to keep the user with the program's environment without > > > > > altering it or affecting it while creating new resources? > > > > > > > > It's just a way to build the applications so the whole project doesn't > > > > depend on a specific technology. You can see the ones we implement > > > > right now here: > > > > https://invent.kde.org/plasma/discover/-/tree/master/libdiscover/backends > > > > This project should be adding a new OSTreeRPMBackend folder in here > > > > that will only take care of this one implementation. > > > > I hope this helps, > > > > Aleix > > > > Adding the mentors list to know what the exact process for students is. > > Mariam, in the meantime, if you want to start working on it or want to > > have some kind of call to get started, tell me and I'll see to it. > > Aleix I just finished fixing the last few issues in the new season.kde.org website. The timeline hasn't been published yet, but I hope Caio will soon publish it. But you should already be able to start writing a proposal. There is some instructions about that in https://community.kde.org/GSoC#Student_proposal_guidelines. This is for GSoC but SoC is similar. Mentors should create an account in season.kde.org and request their mentor account. And then after I accept their request, should be able to see the proposals and comment them, if there is no bug in the software ;) Cheers, Carl
Re: Call for Mentors (and Admins) for Season of KDE 2021
Le mardi, octobre 13, 2020 2:01 PM, Adriaan de Groot a écrit : Hi Adriaan, sorry for the late answer. It looks like I missed this mail. > On Thursday, 10 September 2020 16:11:08 CEST Caio Jordão Carvalho wrote: > > > As discussed in the SoK/GSoC BoF that we had yesterday, our plan is > > to start the next edition of Season of KDE soon. But first we need to > > include > > some ideas in our ideas page and, most importantly, we need mentors! So > > I couldn't tell if SoK was moving forward or likely to happen this year, but > since I wrote up a bunch of starter-issues for Calamares (close-to-a-KDE- > project) for Hacktoberfest (not-a-KDE-activity) which also fit the SoK theme, > I did the following: > > - updated SoK wiki front (https://community.kde.org/SoK) to mention 2021 > - added a general About page > - added Calamares projects (there's a dozen hacktoberfest issues available, > all of which are also suitable SoK things) Thanks a lot for this :) We are still looking for mentors so if anyone has a bit of time and good ideas of potential projects, please consider mentoring for SoK 2021. > > I did not: > > - even try to update https://season.kde.org/ (because Drupal, so it's not > something I think I can reach) A new website was created during GSoC and I should really start deploying it. I will let the mailing lists know then this is done. Cheers, Carl > > The s.k.o site makes it look like December 2019 is in the future, which is > kind of confusing. It'd be better to have it showing, say, the text "SoK > 2020 > is over, we're collecting ideas for 2021, the fancy JavaScript > wheel-calendar- > thingy is switched off but take a look at the Wiki for now" so it's clear > where we're at. > > [ade] >
D28861: Sonnet add Malayalam trigram
ognarb added a subscriber: sandsmark. REPOSITORY R246 Sonnet REVISION DETAIL https://phabricator.kde.org/D28861 To: aiswaryak, #frameworks Cc: sandsmark, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
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
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: Question about copyright notices
Le jeudi, septembre 24, 2020 1:43 AM, Albert Astals Cid a écrit : > El dimecres, 23 de setembre de 2020, a les 19:35:26 CEST, Andreas > Cord-Landwehr va escriure: > > > On Montag, 21. September 2020 22:32:37 CEST Matthieu Gallien wrote: > > > > > Is there some consensus as to what is best for code hosted by the KDE > > > community ? > > > > Hi, that is a good question! I cannot recall that we discussed this during > > the > > last decade. Anyways, there is not a documented consensus either in the > > licensing policy or in the licensing wiki. The REUSE project just says in > > their FAQ [1] that there are several options. But I think it would be good > > to > > have a preferred way. > > Until today, I mostly saw the approach "author updated year on latest > > change", > > but I also know KDE projects where mass-copyright updates were done in the > > past. > > Personally, I would prefer the way Johan described: Update the year only on > > change. But that is only my opinion. What do the others think? > > If you're not doing any change you're not creating copyright because there's > nothing being created, so yes i would not agree on updating the copyright if > you don't change anything. > > Also remember that you don't need to really write that you have copyright on > things, you create copyright by just creating the things, the copyright > notices are a nicety not really a requirement if you have other things like > git that can prove who and when something was created [*] afaik, since copyrights are still valid for decades after the date of your death in most countries[1]. I'm not sure it is really useful to update them. Cheers, Carl [1]: https://en.wikipedia.org/wiki/List_of_countries%27_copyright_lengths > > Cheers, > Albert > > - Not a lawyer, not sure how valid a git commit log is to prove you created > something in court > > > Cheers, > > Andreas > > [1] https://reuse.software/faq/#years-copyright
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: Porting a project to KDE
Le vendredi, août 14, 2020 4:44 PM, Francois Blanchette a écrit : > Hi Carl, > > Thank you for your reply. > > Yes I meant port it to KDE because it is a qt 5.15 compliant > application already. > And yes i want to make LGCK builder a KDE application hosted on KDE > infrastructure as a first step. I would definitely prefer to > integrate with KDE plasma but I see this as a secondary step. I'm > trying to find the path forward which makes most sense. > > What would you recommend? Hi, You will need to find a KDE developer who would like to sponsor your project and make sure that you get developer access to KDE repositories, help you import your project to invent.kde.org and make sure the process happens smoothly :) Unfortunately, I don't have the time to take care of this process myself, but I'm sure someone here will volunteer and help you. Your project looks very nice and I think it will be a positive addition to KDE and hope that being part of KDE will also help LGCK Builder. Cheers, Carl > > Regards, > Frank B. > > On 8/14/20, Carl Schwan c...@carlschwan.eu wrote: > > > Le vendredi, août 14, 2020 3:07 PM, Francois Blanchette > > cfrankb.2...@gmail.com a écrit : > > > > > Hi > > > > Hi Frank, > > > > > My project is call LGCK builder. It is a Game Construction Kit > > > written in C++ using a combination of Qt5, OpenGL and SDL. In addition > > > to the main IDE there is also a standalone Sprite Editor. The main > > > engine implements the graphics, inputs and sounds components via a > > > series of Interfaces which allows different implementers (right now > > > SDL, OpenGL and SFML are fleshed out). Additional back-ends could be > > > added by simply swapping one implementer for another. I think the > > > design is unique because it is object-oriented which frees users from > > > messing around with the old tile-2-tile formula. > > > You can read more about on the official page > > > https://cfrankb.com/lgck?main > > > There is a 5 minute video explaining how to make a game > > > https://www.youtube.com/watch?v=lN3gkZWr-PM > > > The full source code can be found here: > > > https://github.com/cfrankb/lgck-src > > > Here are some screenshots of the project > > > https://cfrankb.com/lgck/gallery.html?latest > > > > I'm on the phone right now so I didn't tried it, but this looks like a > > very nice project. > > > > > I would like some help or pointers on how to port it to Qt. > > > > I guess you mean KDE and not Qt, since you mentioned that your project > > was using Qt5 above. > > Are you interested in making LGCK builder a KDE application hosted on > > KDE infrastructure (https://community.kde.org/Incubator) or making your > > project use KDE Frameworks and better integrated with KDE Plasma? or both? > > Regards, > > Carl > > > > > Regards, > > > Frank B.
Re: Porting a project to KDE
Le vendredi, août 14, 2020 3:07 PM, Francois Blanchette a écrit : > Hi Hi Frank, > > My project is call LGCK builder. It is a Game Construction Kit > written in C++ using a combination of Qt5, OpenGL and SDL. In addition > to the main IDE there is also a standalone Sprite Editor. The main > engine implements the graphics, inputs and sounds components via a > series of Interfaces which allows different implementers (right now > SDL, OpenGL and SFML are fleshed out). Additional back-ends could be > added by simply swapping one implementer for another. I think the > design is unique because it is object-oriented which frees users from > messing around with the old tile-2-tile formula. > > You can read more about on the official page > https://cfrankb.com/lgck?main > > There is a 5 minute video explaining how to make a game > https://www.youtube.com/watch?v=lN3gkZWr-PM > > The full source code can be found here: > https://github.com/cfrankb/lgck-src > > Here are some screenshots of the project > https://cfrankb.com/lgck/gallery.html?latest I'm on the phone right now so I didn't tried it, but this looks like a very nice project. > I would like some help or pointers on how to port it to Qt. I guess you mean KDE and not Qt, since you mentioned that your project was using Qt5 above. Are you interested in making LGCK builder a KDE application hosted on KDE infrastructure (https://community.kde.org/Incubator) or making your project use KDE Frameworks and better integrated with KDE Plasma? or both? Regards, Carl > > Regards, > Frank B.
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
