Hi developers! I would like to pay for adding the option in the question.

1. How much would this cost? Is $100 an acceptable amount?
2. Is https://www.bountysource.com a good site to organize this? Maybe there are other ways?

I need this to be in KDE5.

Some thoughts about a bounty: no bounty can make the maintainers to accept a patch which might be a problem for it in general. Does the developer get the money if the patch is produced and not accepted for whatever reason? Goes that risk with the developer or the user? If it goes with the user how can he differentiate between bad code and good code which just got not accpeted because the maintainers don't want the feature?

Also a $100 bounty is problematic. In a country like Germany that would be about one hour of developer time. The feature cannot be done in that time in a way that it would be accepted. So it would more likely go in the area of $500 to $1000 which is quite a lot of money in e.g. a BRICS state.

That's always something which makes me uneasy about bounty programs. GSoC addresses some of the problems like needing a mentor from the organization and not including the code might be a success.

mgraesslin wrote:Some thoughts about a bounty: no bounty can make the maintainers to accept a patch which might be a problem for it in general. Does the developer get the money if the patch is produced and not accepted for whatever reason? Goes that risk with the developer or the user? If it goes with the user how can he differentiate between bad code and good code which just got not accpeted because the maintainers don't want the feature?

Also a $100 bounty is problematic. In a country like Germany that would be about one hour of developer time. The feature cannot be done in that time in a way that it would be accepted. So it would more likely go in the area of $500 to $1000 which is quite a lot of money in e.g. a BRICS state.

That's always something which makes me uneasy about bounty programs. GSoC addresses some of the problems like needing a mentor from the organization and not including the code might be a success.

Thanks for the reply.

My primary intention is to somehow move this question. Having tried everything else this is my last resort.

>no bounty can make the maintainers to accept a patch which might be a problem for it in general
>because the maintainers don't want the feature?

Maybe I am not right, but it looks to me that there is a problem indeed. Can you please share why you don't want this feature to be in KDE?

> Does the developer get the money if the patch is produced and not accepted for whatever reason? Goes that risk with the developer or the user?

My thought was to "hire" a developer which already works with Kwin and knows how to write a code that would be accepted as a good and maintainable.

> Also a $100 bounty is problematic. In a country like Germany that would be about one hour of developer time. The feature cannot be done in that time in a way that it would be accepted. So it would more likely go in the area of $500 to $1000 which is quite a lot of money in e.g. a BRICS state.

Maybe this will not work, but maybe there are developers willing to do this work. If we find out all the things needed to be done for the patch to be created and accepted and we will know how much this will cost, then we can decide whether it's feasible or not. Maybe there are other people willing to put some money in and we will collect the necessary amount.

For now there are some questions:

1. Can this feature generally be accepted into Kwin? Or you as the project leader will reject it, because you think it's useless?
2. How the patch should be done to be accepted? Looks like no one can answer this, because it all depends on you.
3. How much will this cost? The developer willing to do this can tell and we decide if we can provide this amount of money.

Are there Kwin developers reading this and willing to discuss?

blindvic wrote:1. Can this feature generally be accepted into Kwin? Or you as the project leader will reject it, because you think it's useless?

I'm concerned about the added complexity this would introduce to the focus chain. Also I'm concerned about exposing the option. It doesn't really fit to the "Task Switcher" KCM as that is per switcher and the change would affect the general behavior. So right now I don't see a place where it could be added and also be found by users where they expect it. The obvious way would be to add it to the sort order combo box in Task Switcher KCM, but that requires a serious refactoring of the code in question which moves it far from a trivial patch.

blindvic wrote:2. How the patch should be done to be accepted? Looks like no one can answer this, because it all depends on you.

It needs to be side-effect free. I probably would require that first a unit test is added for the existing behavior to prove that it doesn't break if the option gets added.

Thanks for the clarifications.

On a quick glance, is seems adjusting FocusChain::makeFirstInChain() and FocusChain::getForActivation() (to skip minimized clients if possible) looks sufficient.

The setting would be exposed on the tabbox config, I severely doubt anyone want a window to unminimize in reaction to a closing window.

thanks Seishin!

seishin wrote:I have made a patch in the KDE/4.11 branch for this and compiled a x64 binary that may be used as replacement:

https://github.com/katakumpo/kde-worksp ... -workspace

Thanks guys for the motivation to crawl through that code, i thought i was the only one annoyed by this

the patch works right.
(in case you want a glimpse of it, here is the link: https://github.com/katakumpo/kde-workspace/commit/021ed7cf41e416ee3d93439c4f09489a38b3a35f)

it is at least working on KDE Plasma. (my env: Gentoo Linux, KDE Frameworks 5.40.0, kwin 5.10.5)

if you also run a Gentoo box, it is easy to apply this patch.
create a patch file and re-emerge kde-plasma/kwin.
(instructions on creating a patch: https://wiki.gentoo.org/wiki/Patches, on applying a patch: https://wiki.gentoo.org/wiki//etc/portage/patches)