In last years GSoC scripting capabilities have been added to KWin and have been shipped with 4.6. Unfortunately the student did not stick around so far which results in a situation that during the complete 4.7 releasy cycle there have only been two commits to the scripting component: one to fix some Krazy issues and one to change the coding style. With other words: the development of the component is dead.
For a new component this is very bad as it is unlikely that it is bug free and feature complete. There are probably many usecases where scripting integration might be useful and which is just not yet implemented. It also shows us that the core development team is not able to also maintain this new component. In fact due to lack of provided documentation the core team does not have the knowledge to further extend it.
This unfortunate development raises questions for the future. Currently we have a GSoC to modularize KWin core and it is likely that such a refactoring will break the scripting component at some day. Given that no core developer is knowledged about the scripting component, we are not able to see this in review requests (and we don’t have unit tests for it and cannot add them due to the lack of knowledge about the component). We are also not using the component so we won’t notice a breakage. My expectation for 4.8 is that scripting will be no longer functional and even if bug reports arise we would not be able to fix them.
The GSoC project is preparing KWin core to properly add support for multiple windowing system backends. I have already started to add support for a new windowing system and all the code so far does not integrate scripting. In the far future we want to be able to switch to this new windowing system which has also implications for scripting. Due to the current lack of scripting integration in the new written code it would mean that scripting no longer functions in future.
Overall this does not look good for the scripting component and I am currently considering various options. One of them is to remove scripting support again in 4.8. This is something I don’t want to do and I would feel very bad about it. Lots of work has gone into the code and it is a pity to remove it. Especially given that it was a successfully finished GSoC project and the slot might have been used in a better way for KDE if we remove the code after a year again.
I don’t want to do that! But I need your help to prevent that from happening. Step up and share scripts on kde-apps.org, provide a way to exchange scripts through GHNS, maybe add support for writing scripts to Plasmate and most important get in touch with the development: ensure that the code does not get broken in master, add support for further parts, help to document scripting in techbase, fix some glitches in the scripting related code.
I will keep the code at the moment and look how it evolves over the next months. In case the situation has not improved till soft-feature-freeze of 4.8 I see no other solution than to exclude the code from building 🙁
=-=-=-=-=
Powered by Blogilo
This kwin GSoC project with no documentation and no test units doesn’t look successfully finished to me. It’s more like half finished and that does not look good on that student’s resume. Granted, it is all written by students who are inexperienced they should possess the knowledge for such basic things for at least documentation, that would ease the burden for someone new to step up.
The fact that there are no unit tests cannot be counted against the student as KWin does not have any unit tests.
The lack of documentation is nothing I can judge as I was not the mentor and it is possible that the knowledge had been transferred to the mentor (who was the maintainer at that time).
@Bender: It’s unfortunately quite a bit more complicated than that.
If it is the (uncomfortable) truth, that nobody develops scripts and (nearly) nobody uses this component for me it sounds like to say “We thought it is useful to many, that was a mistake, nobody maintains it, so we remove it” is better than “Hey every decision we make is correct, so we keep it” (Dont get this word by word, so no offense here). Even it may leave a bad reputation for KDE because of accepting that GSoC project, for me it would be worse to keep such component.
If there is noone maintaining it, and there seems so few interesst in it why keep it?
I think Kwin script are very usefull. I`ve wrote a script for Skype chat dialogs grouping. I`ll post it this evening on kde-look.org.
looking forward to it. I checked out the methods in qdbus but couldn’t come up with something useful myself.
So far the most useful has been klipper and kactivitymanagerd.
http://kde-look.org/content/show.php?content=143543 – this is the script 🙂
@lydia you are unfortunately wrong and sorry i cannot explain why because it’s complicated.
Yes, KWin scripting is really useful, but unfortunately it does not yet support activities, tiling etc. (however, other components do not support it, too, e.g. there are not yet desktop effects considering activities, and too few shortcuts etc.)
I think the code is quite clear, what should be the problem with not breaking it?
This is why I don’t like GSOC. Every year it is pitched as a way to get new contributors into FOSS projects but more often than not students go in for the money, then leave, and occasionally the next year finish the job they started and didn’t complete.
One of the problems seems to be that either the mentors or Google are too soft and “in good faith” hand out the money for incompleted projects anyway. Nobody can force a GSOC participant to stay but at the very least the result should be shipable and maintainable or no money will be paid out.
Yes, I agree with your analysis. We have seen this behavior unfortunately too often. This year KWin does not have a project which adds functionality (which afterwards is then unmaintained) but to restructure KWin core. Even if the student doesn’t stay our code base benefits and we do not get another maintainance burden.
true .. but sometimes it is really great.. without the initial work of george (who still works on that project) we wouldn’t expect a release of kdetelepathy right now !
http://gkiagia.wordpress.com/2010/09/20/what-is-telepathy-kde/
I mean, most of it is just boring wrapping code, will all the classes change after the restructuring?
The refactoring includes moving code out of the big Workspace class into own classes, the ownership of some pointers is changed, the compositor is separated from the window manager, the class Client will get a new X-free parent, Toplevel should become X free, all X related code should become a “backend”. Yes there is lots of potential to forget to move one signal or to forget to emit one signal.
I read somewhere that kwin scripting and qml is going to be used in plasma active. As I can remember for e.g windows exposition effect replacement.
Am I wrong? If I’m not there should not be a problem. 🙂
It was considered to use JavaScript in the effects library and that’s still a big item on my todo list. But it would not depend on KWin’s other scripting capabilities.