Re: Part-time KDE sabbatical, feedback or guidance appreciated (but no pressure)

[Christoph Grüninger]

Hi Jakob,
great to hear you want to dedicate some serious amount of work to KDE! Your 
plan to split your love to (1) a pet project and (2) some higher-impact place 
sounds about right.

My advise is, to give different corners of the KDE world a try. Having nice 
people that interact with you, are interested in your contribution, and maybe 
even provide helpful feedback is worth more then self-actualization by starting 
your own application, that will have your name all over it. Consider your 
contribution after the 6 to 12 months time; will it last or bit-rot away 
because nobody cares?

Start with smaller fixes (spelling, fix deprecation or compiler warnings, 
translation, whatever you spot within a couple of hours) and try to get your 
stuff included. Then you learn where you feel welcome.

You might consider:
- KDE Games, they are less complex applications. Some lack some love.
- KDE Incubator projects, rough diamonds which bear the potential that your 
contribution brings the application a leap forward
- Help switching from Qt 5 to Qt 6. Many things can be spotted by following the 
deprecation warnings when compiling with Qt 5.15. Porting to Frameworks 6 could 
get you involved with layers closer to KDE's inner workings.
- You can look for less coding related tasks, to get you started. One example 
is updating Kile's documentation [2]

Have fun!
Christoph

[1] https://community.kde.org/Incubator/Incubated_Projects
[2] https://invent.kde.org/office/kile/-/issues/6


> Jakob Petsovits  hat am 08.05.2023 03:44 CEST 
> geschrieben:
> 
>  
> Hi all,
> 
> If it helps, think of this email as some sort of bizarro GSoC/SoK 
> application, with less detail perhaps, where you can only comment/advise but 
> not reject. (In return I can't ask for a dedicated mentor, but having a 
> preferred point of contact or two would be really nice! If any of these plans 
> below seem worth supporting to you.)
> 
> I last contributed a little bit to KDE prior to the KDE 4.0 release, sometime 
> prior to 2010, renaming icons to conform to the XDG spec. My energy levels 
> were never high enough to make meaningful contributions after that in 
> addition to full-time work. So after a number of years in proprietary 
> software, I'm quitting my job for the time being to focus on some personal 
> goals. This includes helping KDE (on Linux in particular) with world 
> domination as a part-time endeavor. Reserving the right to fail of course, 
> and to pause at any point if self-care asks for it.
> 
> In short, I'll have an estimated 6-12 months during which I'm hoping to make 
> some improvements and/or additions to KDE, with notably less intensity than a 
> GSoC project but with a longer time frame instead. I'd like to produce 
> something of value that will outlive my sabbatical. I need to get some 
> practice with modern Qt/QML and get a sense for how to use the different KDE 
> communication channels in order to be more useful than annoying, and in order 
> to actually connect with the community. Thankfully Joseph P.D.V.G. posted a 
> rather neat intro email to kde-soc recently, to which I'm still subscribed 
> (haha), so that helps with not missing the obvious basics.
> 
> In particular, I'd like to ask for feedback about how to make my development 
> time count. What to look at, or how to approach it. Here's what I have in 
> mind right now, feel free to steer me into a different direction if it 
> doesn't sound ideal. Thanks in advance for any feedback, or even just taking 
> the time to read through this wall of text.
> 
> ---
> 
> Big picture plan: a two-pronged approach with time split between two separate 
> tracks.
> 
> (1) Work on a personal pet project, a stand-alone app or plasmoid to act both 
> as a playground with freedom to learn & experiment, but also with the goal of 
> ending up in official KDE releases (Gear or Plasma) eventually. Safe space to 
> tinker with if I need a break from other hard stuff.
> 
> (2) Dive into existing KDE "core" codebases for maximum impact but also to 
> get exposure to a wider subset of the community. I was thinking it'll be a 
> good idea to focus on semi-random bugfixing first and then see where that 
> takes me, it might lead to a spin-off new project or new topics of interest.
> 
> I would switch back and forth between both, but within each track focus 
> mostly on one thing at a time.
> 
> For (1), I've previously started with some UI ideas for a convergent app with 
> combined scanning and PDF page re-ordering functionality (think PDF Arranger) 
> at https://invent.kde.org/jpetso/marascan-concept. Frankly, Skanpage has 
> improved a whole bunch, after painful introspection I've got to admit that it 
> barely makes sense to start a competing app now. However, what would still 
> make sense (imho) is to work on some of the components I had in mind, make 
> them suitable also for Skanpage and perhaps someday in the future build my 
> alternative mobile-friendly Kirigami app around

Re: Part-time KDE sabbatical, feedback or guidance appreciated (but no pressure)

[AnnoyingRains]

Bug reports are a great way to go, they really need a lot of love at
the moment. Lots of bug reports are for incredibly old versions and
may or may not be still valid

Good luck!
- Kye Potter, KDE Gardening

On Mon, May 8, 2023 at 1:26 PM Jakob Petsovits  wrote:
>
> On Sun, May 7, 2023, at 10:11 PM, Joshua Goins wrote:
> >> 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.
>
> Thanks for the warm welcome, and the reminder! I was aware of this (hence the 
> "not just to keys" quote) and I definitely still have to check out the code 
> to get a better sense of it.
>
> It's interesting to consider the contrast between button/key mappings and 
> action mappings. The latter is necessarily app-specific and that's pretty 
> great, at least for KDE apps that allow setting shortcuts with KDE settings 
> dialogs / System Settings.
>
> Interactions such as Ctrl + left-click in an image/vector editing app are 
> more similar to actions, but are also somewhat different in that they're 
> highly context-dependent (on the mouse pointer position) and there won't be a 
> shortcut action exposed for it. Needs a different way to configure the 
> mapping. Still conceptually app-specific though, or even "context"-specific 
> e.g. to the app's canvas view.
>
> Non-KDE apps and games probably need to map the button press to another 
> simulated peripheral input. This could work in a way that's similar to KWin's 
> window rules, although for games (i.e. an exclusively full-screen app) it 
> would be even nicer to have a screen overlay à la Steam Deck's game-specific 
> controller mapping settings. Too far removed for a starter project, but does 
> make me wonder if slide-in settings overlays for compositor/input 
> functionality are useful in other circumstances (apps in Plasma Bigscreen 
> maybe?) as well.
>
> Anyway, let's not get ahead of myself. Going to look at bug reports first. 
> Cheers!
>
> - Jakob

Re: Part-time KDE sabbatical, feedback or guidance appreciated (but no pressure)

[Jakob Petsovits]

On Sun, May 7, 2023, at 10:11 PM, Joshua Goins wrote:
>> 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.

Thanks for the warm welcome, and the reminder! I was aware of this (hence the 
"not just to keys" quote) and I definitely still have to check out the code to 
get a better sense of it.

It's interesting to consider the contrast between button/key mappings and 
action mappings. The latter is necessarily app-specific and that's pretty 
great, at least for KDE apps that allow setting shortcuts with KDE settings 
dialogs / System Settings.

Interactions such as Ctrl + left-click in an image/vector editing app are more 
similar to actions, but are also somewhat different in that they're highly 
context-dependent (on the mouse pointer position) and there won't be a shortcut 
action exposed for it. Needs a different way to configure the mapping. Still 
conceptually app-specific though, or even "context"-specific e.g. to the app's 
canvas view.

Non-KDE apps and games probably need to map the button press to another 
simulated peripheral input. This could work in a way that's similar to KWin's 
window rules, although for games (i.e. an exclusively full-screen app) it would 
be even nicer to have a screen overlay à la Steam Deck's game-specific 
controller mapping settings. Too far removed for a starter project, but does 
make me wonder if slide-in settings overlays for compositor/input functionality 
are useful in other circumstances (apps in Plasma Bigscreen maybe?) as well.

Anyway, let's not get ahead of myself. Going to look at bug reports first. 
Cheers!

- Jakob

Re: Part-time KDE sabbatical, feedback or guidance appreciated (but no pressure)

[Joshua Goins]

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

Part-time KDE sabbatical, feedback or guidance appreciated (but no pressure)

[Jakob Petsovits]

Hi all,

If it helps, think of this email as some sort of bizarro GSoC/SoK application, 
with less detail perhaps, where you can only comment/advise but not reject. (In 
return I can't ask for a dedicated mentor, but having a preferred point of 
contact or two would be really nice! If any of these plans below seem worth 
supporting to you.)

I last contributed a little bit to KDE prior to the KDE 4.0 release, sometime 
prior to 2010, renaming icons to conform to the XDG spec. My energy levels were 
never high enough to make meaningful contributions after that in addition to 
full-time work. So after a number of years in proprietary software, I'm 
quitting my job for the time being to focus on some personal goals. This 
includes helping KDE (on Linux in particular) with world domination as a 
part-time endeavor. Reserving the right to fail of course, and to pause at any 
point if self-care asks for it.

In short, I'll have an estimated 6-12 months during which I'm hoping to make 
some improvements and/or additions to KDE, with notably less intensity than a 
GSoC project but with a longer time frame instead. I'd like to produce 
something of value that will outlive my sabbatical. I need to get some practice 
with modern Qt/QML and get a sense for how to use the different KDE 
communication channels in order to be more useful than annoying, and in order 
to actually connect with the community. Thankfully Joseph P.D.V.G. posted a 
rather neat intro email to kde-soc recently, to which I'm still subscribed 
(haha), so that helps with not missing the obvious basics.

In particular, I'd like to ask for feedback about how to make my development 
time count. What to look at, or how to approach it. Here's what I have in mind 
right now, feel free to steer me into a different direction if it doesn't sound 
ideal. Thanks in advance for any feedback, or even just taking the time to read 
through this wall of text.

---

Big picture plan: a two-pronged approach with time split between two separate 
tracks.

(1) Work on a personal pet project, a stand-alone app or plasmoid to act both 
as a playground with freedom to learn & experiment, but also with the goal of 
ending up in official KDE releases (Gear or Plasma) eventually. Safe space to 
tinker with if I need a break from other hard stuff.

(2) Dive into existing KDE "core" codebases for maximum impact but also to get 
exposure to a wider subset of the community. I was thinking it'll be a good 
idea to focus on semi-random bugfixing first and then see where that takes me, 
it might lead to a spin-off new project or new topics of interest.

I would switch back and forth between both, but within each track focus mostly 
on one thing at a time.

For (1), I've previously started with some UI ideas for a convergent app with 
combined scanning and PDF page re-ordering functionality (think PDF Arranger) 
at https://invent.kde.org/jpetso/marascan-concept. Frankly, Skanpage has 
improved a whole bunch, after painful introspection I've got to admit that it 
barely makes sense to start a competing app now. However, what would still make 
sense (imho) is to work on some of the components I had in mind, make them 
suitable also for Skanpage and perhaps someday in the future build my 
alternative mobile-friendly Kirigami app around them. Things I'd like to see 
are:
  (*) a pinch-zoomable multi-page canvas that allows editing functionality such 
as drag & drop, page cropping and placing page action buttons smartly around 
the page in the empty space where they don't get in the way,
  (*) grouping disorganized SANE settings into related groups so one can save 
and select "quality presets",
  (*) a single sidebar for either scanner options or page previews, and scanner 
options being close to the "Scan" button,
  (*) being able to load existing PDFs so you can also organize pages after the 
initial save,
  (*) crop after scan, including with perspective distortion which you get from 
smartphone pictures. Looks like this isn't quite sticking with "personal pet 
project" scope here, but also the multi-page canvas is probably the most work 
and that can be prototyped on its own.

An alternative to the above project might be a game launcher in the style of 
GNOME's new Cartridge app, but designed as a plasmoid. Cartridge shows that one 
can list and start games from different game launcher apps without 
reimplementing their Wine integrations and library management. No reason why I 
should have to open a separate app just for launching stuff though, when a 
plasmoid can put the launcher directly into a secondary "start menu" in the 
panel, or as desktop widget on a dedicated virtual desktop. KDE integration may 
furthermore provide useful stuff such as switching from regular monitor 
settings for productive desktop use to temporary high refresh rates, VRR, HDR 
(in the future), custom key/button mappings, performance overrides, and whatnot.

I'd also be interested in having something like 

Re: developer account set up

[Ben Cooksley]

On Mon, May 8, 2023 at 3:22 AM Nate Graham  wrote:

> There's also no reason anymore why they need to use a work branch in the
> main repo; a fork works just fine. I do nearly all of my development
> using personal forks; it's a 100% supported first-class citizen experience.
>

For those using forks, please make sure you cleanup any fork that you're
not using once you're finished with it.

This is especially relevant if you are only using it for one or two quick
changes, as GitLab only performs something known as "housekeeping" on
repositories that have a certain level of use (I think it is run every 5
pushes)

Over the weekend I executed "housekeeping" on every repository on
invent.kde.org, including the 7,000 or so forks that exist (to put that
number in perspective, we have around 11,000 repositories in total).
It resulted in the better part of 100GB being freed, and around 600,000
inodes being released - mostly due to forks that only got used a small
handful of times.


>
> Nate
>

Thanks,
Ben


>
> On 5/7/23 17:06, Joshua Goins wrote:
> >> 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: developer account set up

[Konstantin Kharlamov]

On Sun, 2023-05-07 at 17:21 +0200, Nate Graham wrote:
> There's also no reason anymore why they need to use a work branch in the 
> main repo; a fork works just fine. I do nearly all of my development 
> using personal forks; it's a 100% supported first-class citizen experience.

+1

I remember when we were integrating Gitlab at work, people for some reason were
attempting to create branches in the upstream repo rather than on their own
fork. Had to do some explanation that this isn't the way to go, because after an
year of such workflow upstream will end up with hundreds if not thousands of
abandoned branches that serve no purpose, and who's gonna clean that up 🤷‍♂️
Especially given that people may come and go, and so in some cases you wouldn't
even find an author of a branch (and in some cases it's hard to even figure out
who could be the author in the first place).

Re: developer account set up

[Nate Graham]

There's also no reason anymore why they need to use a work branch in the 
main repo; a fork works just fine. I do nearly all of my development 
using personal forks; it's a 100% supported first-class citizen experience.


Nate

On 5/7/23 17:06, Joshua Goins wrote:

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: developer account set up

[Joshua Goins]

> 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: developer account set up

[Johnny Jazeix]

Le dim. 7 mai 2023 à 11:22, Nate Graham  a écrit :

> -Utarsh
>
> It might be worth re-thinking this policy now that we use GitLab. People
> don't need a developer account to fully contribute anymore.
>
> Nate
>
>
We usually recommend contributors to create branches in the main repository
(work/gsoc/...). Is it possible without a developer account?

Johnny


>
> On 5/7/23 09:41, Johnny Jazeix wrote:
> >
> >
> > Le sam. 6 mai 2023 à 23:31, Nate Graham  > > a écrit :
> >
> > Hello Utkarsh,
> >
> > You don't need a developer *account* to start contributing, and in
> fact
> > you can't have one until you've made a number of contributions
> > already. :)
> >
> > If you're looking for information about starting the process of
> > contributing with code, we have a bunch of documentation at
> > https://community.kde.org/Get_Involved/development
> > .
> >
> >
> > Best of luck!
> >
> > Nate
> >
> >
> > On 5/6/23 20:42, Utkarsh Kumar wrote:
> >  > Hlw, I am Utkarsh Kumar and I want to need help creating a
> developer
> >  > account setup. so please can someone suggest to me the steps I
> > need to
> >  > follow to create a developer account?
> >
> >
> > Hi Nate,
> > Utkarsh has been selected for GSoC to work on digiKam and it's a
> > prerequisite to create a developer account do in the community bonding
> > period.
> > Cheers,
> >
> > Johnny
>

Re: developer account set up

[Utkarsh Kumar]

So Right now what do I need to do? Can you suggest to me anything that is
beneficial for me?

On Sun, May 7, 2023 at 2:53 PM Nate Graham  wrote:

> -Utarsh
>
> It might be worth re-thinking this policy now that we use GitLab. People
> don't need a developer account to fully contribute anymore.
>
> Nate
>
>
> On 5/7/23 09:41, Johnny Jazeix wrote:
> >
> >
> > Le sam. 6 mai 2023 à 23:31, Nate Graham  > > a écrit :
> >
> > Hello Utkarsh,
> >
> > You don't need a developer *account* to start contributing, and in
> fact
> > you can't have one until you've made a number of contributions
> > already. :)
> >
> > If you're looking for information about starting the process of
> > contributing with code, we have a bunch of documentation at
> > https://community.kde.org/Get_Involved/development
> > .
> >
> >
> > Best of luck!
> >
> > Nate
> >
> >
> > On 5/6/23 20:42, Utkarsh Kumar wrote:
> >  > Hlw, I am Utkarsh Kumar and I want to need help creating a
> developer
> >  > account setup. so please can someone suggest to me the steps I
> > need to
> >  > follow to create a developer account?
> >
> >
> > Hi Nate,
> > Utkarsh has been selected for GSoC to work on digiKam and it's a
> > prerequisite to create a developer account do in the community bonding
> > period.
> > Cheers,
> >
> > Johnny
>

Re: developer account set up

[Nate Graham]

-Utarsh

It might be worth re-thinking this policy now that we use GitLab. People 
don't need a developer account to fully contribute anymore.


Nate


On 5/7/23 09:41, Johnny Jazeix wrote:



Le sam. 6 mai 2023 à 23:31, Nate Graham > a écrit :


Hello Utkarsh,

You don't need a developer *account* to start contributing, and in fact
you can't have one until you've made a number of contributions
already. :)

If you're looking for information about starting the process of
contributing with code, we have a bunch of documentation at
https://community.kde.org/Get_Involved/development
.


Best of luck!

Nate


On 5/6/23 20:42, Utkarsh Kumar wrote:
 > Hlw, I am Utkarsh Kumar and I want to need help creating a developer
 > account setup. so please can someone suggest to me the steps I
need to
 > follow to create a developer account?


Hi Nate,
Utkarsh has been selected for GSoC to work on digiKam and it's a 
prerequisite to create a developer account do in the community bonding 
period.

Cheers,

Johnny

Re: developer account set up

[Johnny Jazeix]

Le sam. 6 mai 2023 à 23:31, Nate Graham  a écrit :

> Hello Utkarsh,
>
> You don't need a developer *account* to start contributing, and in fact
> you can't have one until you've made a number of contributions already. :)
>
> If you're looking for information about starting the process of
> contributing with code, we have a bunch of documentation at
> https://community.kde.org/Get_Involved/development.
>
>
> Best of luck!
>
> Nate
>
>
> On 5/6/23 20:42, Utkarsh Kumar wrote:
> > Hlw, I am Utkarsh Kumar and I want to need help creating a developer
> > account setup. so please can someone suggest to me the steps I need to
> > follow to create a developer account?
>

Hi Nate,
Utkarsh has been selected for GSoC to work on digiKam and it's a
prerequisite to create a developer account do in the community bonding
period.
Cheers,

Johnny