Re: developer account set up
> We usually recommend contributors to create branches in the main repository > (work/gsoc/...). Is it possible without a developer account? > > Johnny It doesn't have to be the GSoc student that creates the branches, only that they are the ones putting commits in it. Something I've seen done is the mentor creates the work branch (work/gsoc/student) and the student creates MRs to merge their work into the branch instead of targetting master.
Re: Part-time KDE sabbatical, feedback or guidance appreciated (but no pressure)
Welcome back to KDE! Yes, involving yourself in bug reports is in my opinion the best way to get started, especially if you want to orient yourself with the gargantuan codebase of KDE. > I'd also be interested in having something like the mouse button mapping UIs > that Windows users get from their mouse manufacturer, enabling remapping of > mouse buttons not just to keys but also to modify other mouse (or keyboard) > behaviors while pressed. With Wayland it can be app-/window-specific too, I > think. And of course it would be a good selling point that hey, *any* mouse > can have all the features as opposed to being tied to the driver and > manufacturer. Some changes to KWin will likely be required to power the > configured mapping in practice. Ultimately this kind of configuration UI > should be part of in System Settings. This already exists in some capacity - you can remap extra mouse buttons in the Mouse KCM (the button is called "Re-bind Additional Mouse Buttons..."). Not sure how well it works, because it doesn't pick up on my additional buttons on my G600 for some reason. The help is always appreciated though, especially for modifier support and such which I think is a limitation of our current system. Good luck, Josh
Re: MpvQt: libmpv wrapper for Qt Quick 2/Qml
> Hello, > > I have created a libmpv wrapper library for qtquick/qml (no widgets) > https://invent.kde.org/georgefb/mpvqt. > > I created it mostly because I use mpv in Haruna and other personal projects > and keeping the code in sync got annoying. There are also other kde > projects > using mpv (plasmatube, tokodon, clip) and hopefully it can be of use to > them too. This is great George, this is something that's been on my mind for a while. It would be nice for all of the applications to adopt this and it'll simultaneously fix bugs I've found in all of them 😀 I'm not sure when I'll have time to look at this, but I support the idea. Thanks, ?Josh
Re: Interest in building an LLM frontend for KDE
Hey Loren, I agree with everyone else that as long as the model is ethically sourced and local-by-default (which is my two main problems with modern LLMs.) I see no qualms about including such a frontend in KDE. I think the hardest part will be the marketing around this new software. One of our current goals is "Sustainable Software" and current LLM models as far as I understand is extremely power hungry and inefficient. If you do go ahead with this project, I would be very careful with how we promote it. It would have to somehow push KDE values while also avoiding the ethical, climate and social minefield that's currently littering this topic. Just something to keep in mind 🙂 Thanks, Josh
Re: Unified internal communications channel
Hey Nate, thanks for formalizing this discussion 🙂 Maybe you should give some examples of "internal communication" topics here too, because it might not be clear to everyone. I'm also curious about the implications of mirroring such topics to discuss.kde.org and other "user support" type of places, because discussions tend to get derailed there. Also would such a communication tool allow replies/discussion, or is it simply a "kickstart" for discussions to take place elsewhere? I.E. an announcement saying "some developer is suggesting we should make the accent color purple" but it says "please discuss in this invent.kde.org" instead of making yet another discussion ML. Thanks, Josh
Re: Unified internal communications channel
Hi Carl, > 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. Yeah this is kind of tough to define, and I'm also wondering about the best way to handle this. Ideally, the communication channel would be low traffic (hence my suggestion to not allow discussions at all, and point people to a relevant issue if they're interested) so people won't easily ignore it. That doesn't solve the scope issue though, but might help anyway. > 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. +1 to this idea, they usually have the same kind of discussions anyway. Some posts are usually cross-posted between them. Thanks, Josh
Re: resvg
> Hello, > > What do you think about https://github.com/RazrFalcon/resvg in case of > processing and rendering SVGs? In case anyone hasn't seen this before, Harald has already tried integrating resvg with Plasma: https://kde.haraldsitter.eu/posts/resvg-for-svgs-in-qt/ Josh
Re: KDE Review Request: KRDP
> Hi! > > Arjen Hiemstra and me have been working on a RDP server called KRDP. > This allows remote desktop connections over RDP protocol. Arjen > did the heavy lifting with the streaming side and the actual protocol side. > > https://invent.kde.org/plasma/krdp I'm not knowledgeable about RDP stuff code-wise, but I would really appreciate a more up-to-date README. Like: Is it supposed to still be an example server (then why does it have a KCM?) An explanation of why a user would care would be appreciated, is this the "RDP" for wayland we need? It already has a good start with the supported/ unsupported client list and the command line options, just needs a bit more. If you update the tagline don't forget to change the repo description as well. Josh
Re: The state of our API documentation and what to do about it
> Hi, > > +1 in general. The documentation particularly for Kirigami and QML stuff > is quite sad. > > Does the switch to qdoc mean we have to write documentation in the _cpp_ > file, though? That would be unfortunate. > No, see his patch at the bottom of the e-mail. Hopefully that won't be the case if it gets accepted 🙂 Josh
Re: PSA: Enable KCrash for you application
On Thursday, August 8, 2024 9:06:03 AM EDT Nicolas Fella wrote:
> Hi,
>
> TL;DR: Call KCrash::initialize() after setting up KAboutData
>
> crash reporting via DrKonqi to Bugzilla and Sentry is powered by the
> KCrash framework, which acts as the crash handler inside the application.
>
> To install the crash handler you need to call KCrash::initialize() in
> your application's main function. Since the crash handler relies on
> information from KAboutData you should do it after the call to
> KAboutData::setApplicationData(). For best results make sure to include
> the application version in the about data.
Thanks for posting this to the ML Nico. I'm wondering since 24.08 is close to
releasing I want to get KCrash in for some of my applications. We're past
dependency freeze, though. Assuming I do the usual way of using KCrash (adding
to .kde-ci.yml and using __has_include("KCrash")) would that need approval
from the release team to make an exception? Or is it so inconsequential it
should be OK?
Thanks,
Josh
Re: PSA: Enable KCrash for you application
On Friday, August 9, 2024 11:54:39 AM EDT Joshua Goins wrote:
> Thanks for posting this to the ML Nico. I'm wondering since 24.08 is close
> to releasing I want to get KCrash in for some of my applications. We're
> past dependency freeze, though. Assuming I do the usual way of using KCrash
> (adding to .kde-ci.yml and using __has_include("KCrash")) would that need
> approval from the release team to make an exception? Or is it so
> inconsequential it should be OK?
>
> Thanks,
> Josh
Right after I posted this, I realized I also need to add a
target_link_libraries call 🙂 Although now I wonder how the CI passed in my
MRs...
Josh
Re: KDE Gear projects with failing CI (master) (24 December 2024)
On Tuesday, December 24, 2024 4:00:54 AM Eastern Standard Time Albert Astals Cid wrote: > tokodon - NEW > * https://invent.kde.org/network/tokodon/-/pipelines/848675 > * flatpak build fails I fixed this recently and now the Tokodon master CI is all green. Josh
Re: KDE Gear projects with failing CI (release/24.12) (28 January 2025)
On Tuesday, January 28, 2025 5:27:15 PM Eastern Standard Time Albert Astals Cid wrote: > neochat - 2nd week > * https://invent.kde.org/network/neochat/-/pipelines/874963 > * flatpak build fails This is now fixed, along with neochat master which was failing due to an outdated kquickimageeditor cached on the CI. Josh
Re: KDE Gear projects with failing CI (release/24.12) (17 December 2024)
On Tuesday, December 17, 2024 6:05:46 PM Eastern Standard Time Albert Astals Cid wrote: > kunifiedpush - 3rd week > * https://invent.kde.org/libraries/kunifiedpush/-/pipelines/834459 > * connectortest fails on freebsd I looked into this tonight, and from what I can tell this is some unknown breakage with FreeBSD. It started with Heiko's cd42de38df2bd23de2c93c3533c8a7dd69e26498 but that's completely unrelated to anything to BSD. Reverting the commit - of course - does nothing to solve the problem. Something changed within in the image between Nov 9th and Dec 4th, I guess. I don't have enough knowledge of BSD-anything to give a real answer beyond that, unfortunately. Josh
Re: KDE Gear projects with failing CI (master) (22 April 2025)
On Tuesday, April 22, 2025 5:21:54 PM Eastern Daylight Time Albert Astals Cid wrote: > tokodon - NEW > * https://invent.kde.org/network/tokodon/-/pipelines/933569 > * Qt6.10 build fails, my suggestion is to open a bug to track it and > temporarily disable the build Thanks for the suggestion, this is done in https://invent.kde.org/network/ tokodon/-/merge_requests/730. Josh
