[GSoC] Interest in applying
Hello, I have been a Linux user ever since I got my own laptop and started dablling in programming. After a short period with Mint (and Cinnamon), I switched to KDE's software suite and have never looked back. I admire the work everyone involved has put into the project over the years, and how great the software has become. Plasma 6, for example, has been an incredible journey to watch (mostly through Nate Graham's amazing blog!), with an excellent payoff. Congrats to everyone! Since I use KDE software every single day, the thought of giving back to the project through technical contributions has been something I've always wanted to do, but never quite gotten into (though I started fixing a workspace OSD bug at some point). I am a Computer Science student, currently taking a Master's degree in Portugal's top university. I have a strong passion for algorithms, data structures and high performance computing, having participated in many programming contests (nationals, SWERC, Google's now defunct competitions, etc) too. I have also some experience in contributing to open-source and working in software development teams. After carefully reading your approved ideas page, the ones that stand out more to me are: * Improving Lokalize's suggestions (I'm a big supporter of quality i18n) * Sharing non-text clipboard content with KDEConnect (KC is an amazing and pretty unique tool) * Improve forms/javascript support in Okular (I think Okular is a great PDF reader already, but it does lack good forms support, something increasingly more useful nowadays) I am aware of the very tight deadline and that it may be hard to write a community-backed proposal now, but unfortunately I was only made aware of Google's program a couple of days ago. Still, I'm going to try my best to write a quality proposal until Tuesday. If you have any suggestions, please let me know! I'd love to further discuss these with you. Kind regards, ~tmpod PS: To all celebrating Easter (and not hehe!), I hope you have wonderful Sunday.
Re: [GSoC] Interest in applying
Olá, On 31/03/2024 16.16, tmpod wrote: > After carefully reading your approved ideas page, the ones that > stand > out more to me are: > * Improving Lokalize's suggestions (I'm a big supporter of quality i18n) Thanks for your interest in this. Please subscribe to: https://mail.kde.org/mailman/listinfo/kde-i18n-doc/ You may wish to also join the associated Matrix room: https://go.kde.org/matrix/#/#kde-i18n:kde.org There is also a Portuguese mailing list: https://mail.kde.org/mailman/listinfo/kde-i18n-pt > * Sharing non-text clipboard content with KDEConnect (KC is an amazing > and pretty unique tool) > * Improve forms/javascript support in Okular (I think Okular is a great > PDF reader already, but it does lack good forms support, something > increasingly more useful nowadays) > > I am aware of the very tight deadline and that it may be hard to write a > community-backed proposal now, but unfortunately I was only made aware > of Google's program a couple of days ago. Still, I'm going to try my > best to write a quality proposal until Tuesday. > > If you have any suggestions, please let me know! Typically need to find a mentor - many people do start applications early and have made prior contributions to KDE. In addition to the contact methods listed for each of the projects you find interesting, you might also want to post to: https://go.kde.org/matrix/#/#kde-mentorship:kde.org KDE does also organize Season of KDE at the beginning of every year, https://mentorship.kde.org/sok/ though contributions to KDE projects are welcome also outside of these programs. > I'd love to further discuss these with you. > > Kind regards, > > ~tmpod > > > PS: To all celebrating Easter (and not hehe!), I hope you have wonderful > Sunday.
Re: [GSoC] Interest in applying
Olá, Hi! :D Thank you for your kind response. Thanks for your interest in this. Please subscribe to: https://mail.kde.org/mailman/listinfo/kde-i18n-doc/ You may wish to also join the associated Matrix room: https://go.kde.org/matrix/#/#kde-i18n:kde.org There is also a Portuguese mailing list: https://mail.kde.org/mailman/listinfo/kde-i18n-pt Yes, already on those o7 Typically need to find a mentor - many people do start applications early and have made prior contributions to KDE. In addition to the contact methods listed for each of the projects you find interesting, you might also want to post to: https://go.kde.org/matrix/#/#kde-mentorship:kde.org Right, that's what I thought. The timing here is very unfortunate, but I will still try. Next year I'll prepare with plenty of time. :) KDE does also organize Season of KDE at the beginning of every year, https://mentorship.kde.org/sok/ though contributions to KDE projects are welcome also outside of these programs. Yeah, I still intend of finishing that bug fix sometime before summer hehe Cheers, ~tmpod
Re: APIs for persistent remote access and headless/hybrid sessions
A remote session would need the following four pieces: 1. An API for the remote access tool to request a remote display and authenticate. This could involve a headless greeter session for remote login or direct authentication of some sort. 2. A way for the login manager to launch a session in headless mode. 3. A way for the login manager to query whether an existing session is headless or can dynamically transition to being headless (and trigger the transition if so). 4. A way for the remote desktop tool to connect to and control a headless session (both the headless greeter, if used, and the user session). I think all of these parts can, and arguably should, be completely independent of a standardized org.freedesktop.DisplayManager: (1) should arguably be a separate interface than that for local display managers. Discussion on the wlroots tracker suggests many users of wlroots-based compositors prefer to have a simple local login manager like ly or greetd. Having a separate interface allows a separate package to offer remote login functionality on the system bus. A full featured display manager like GDM or SDDM could still offer both interfaces itself for better integration. (2) could be as simple as a property in the session's .desktop file providing a command-line for headless launch. (3) would presumably be an interface provided on the user bus by the compositor itself. (4) would also be a compositor-provided interface, which could either be a new or expanded Portal API or a distinct API like that proposed by Jonas Ådahl. I believe ConsoleKit and logind already provide a mechanism for a local login manager to switch to and unlock an existing session, so the main piece of functionality more integration or a standardized display manager API would provide would be to provide a way for the session to kick back to the login screen when curtained, instead of staying in the foreground with the physical inputs and outputs disabled. Please let me know if I'm missing something, though. I'm still relatively new to this area. > Also, it looks like there's a draft spec being worked on by Jonas > Ådahl about a remote desktop protocol (presumably based on what GNOME > has been working on). Indeed. (I mentioned it in my initial message.) However, I do not believe it is directly related to the remote login support Joan Torres is working on for GNOME Remote Desktop, which relies on GNOME-specific unstable APIs, but is rather a separate effort to provide a standard interface for what I call piece (4) above.
