Re: The state of KWin
Well then I'm very glad to know that there are chances :) Anyway, you should have some projects planned, like great code transitions similar to those in KWin (see the original post) or something else, which you _definitely_ want to do and look for the manpower to accomplish those. It's like the variant with the highest probability to get into GSOC, I think :) Anyway, I _may_ be coming back for a very small period of time during winter holidays, but not sure yet. But that's OT anyway. Going to do mostly UI papercuts hunting, though. (The kind of contribution that takes the most time to investigate and the least amount of lines to submit after solving the problem, don't you think.) Cheers, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The state of KWin
On Sunday, December 26, 2010, Ignat Semenov wrote: > So here's hoping to get involved on a regular and official basis from a awesome :) great to see your name around again ... > Is it possible to get into GSOC reliably in this or other way? Who decides > that anyway, you or some GSOC committee? we pick the best proposals for our projects, and then together as a group KDE people divide up the number of slots we get amongst the various teams within KDE according to need, demand, quality of proposals, etc. > You might say that it's too early, not at all; i like to see that kind of initiative. we can't promise anything, but being involved before GSoC is a great way to increase your chances. > but it's better to do things earlier that later anyway, don't you think? yep :) > And mind you I'm from Russia, but that should not be a problem anyway, your country of origin doesn't matter at all when it comes to this :) all that matters is that you are enrolled as a student in a university at the time of GSoC and that you have a good idea for your project. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The state of KWin
Hello guys and plasma-devel! You might still remember me from the summer days, a guy most of the time hanging out in #plasma and #oxygen as thorgt. ATM I've got a job, essentially an internship, here in Russia which most likely is going to continue at lest till summer, when... well when I'm finally free. So Martin is talking about known KDE developers or near-developers (at least I hope they're included as well :)), especially students. I'd like to say you already have one, looking to find a GSOC application and maybe (in the long-term) something in the area of full-time or part-time KDE developer, sorta what you call a sponsorship or something, hope that's not too dire, but that's what I'm aiming for. So here's hoping to get involved on a regular and official basis from a Russian tech guy, C++ fan and Qt/KDE fanboy as well, although not an expert nor a pro yet, and definitely a Linux fan, as well as a long time Fedora user :) Just so you could possibly look forward to one more unit of manpower in summer. Is it possible to get into GSOC reliably in this or other way? Who decides that anyway, you or some GSOC committee? You might say that it's too early, but it's better to do things earlier that later anyway, don't you think? And mind you I'm from Russia, but that should not be a problem anyway, hope so at least. Cheers, Ignat Semenov aka thorGT ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The state of KWin
On Sunday, December 26, 2010, Martin Gräßlin wrote: > let me break the Christmas silence by writing a long post about the current > state of KWin and where we are heading towards in 2011. As this also is thanks for sharing; these kind of "look ahead" communications are so useful to ensuring things stay on track and to encourage renewed energy and commitment. so: thanks :) > Sorry that it is that long. compared to my average "where we are" emails, you are a study in brevity and clarity. ;) > *Plasma and KWin* > I consider Plasma and KWin as the integrated product of the KDE workspaces. > Both products depend on each other and do not make much sense without the > other. i'd word this slightly differently: they make the most sense when used together, and we shouldn't be afraid to get more benefits out of that relationship. i do think it makes complete sense to use kwin without plasma-desktop, and plasma-desktop without kwin. i also think that when people do that, it's acceptable that there will be a degredation of features. the basics should all still work, something that will keep us honest as developers and not start taking shortcuts that violate principles of encapsulation and focus, but i am completely fine with the idea of charging ahead with great integration to bring all the really great features we can imagine to the front. > This is also reflected when looking at our developer base: we have > almost a 100 percent match. We currently see great improvements on the > syncing of our working procedures. Using reviewboard, having common > processes for git and so on. I hope with the switch to kdelibs coding > style (scheduled for directly after import of KWin-GLES) and removing bug > mails for KWin mailinglist to have improved the situation for Plasma devs. this all fills me with great hope for the future of our projects. this is so obviously the best path we can hope for and it is so great that we have found ourselves a way to get onto it. :) > If there is anything from a Plasma perspective to improve it even more, > please let me know, I am open to all suggestions. and the other way around from the plasma perspective, too. having the input of kwin on plasma is just as valuable to us as hopefully our input is to kwin. :) > *GSoC* you're going through the same pains we have in plasma and reaching very similar conclusions :) i think it's useful to have a few speculative projects, but keep most of them focused, building on what's already there and with people who have had some interface with the project already. > *Manpower* > Manpower is in my opinion the biggest problem of KWin. We are just three > developers + Chani and Ivan working on activity related code. I would like > to get more Plasma developers working on KWin. It should be a natural > thing to touch KWin code and to add new features in KWin if it makes > sense. Here I would like to know from the developers sometimes working on > KWin what needs to be improved. from my perspective, it's all the things you already touched on: modularity so it's easy to get moving, code readability (i find the current style very difficult to read, tbh) and in some places documentation (even just basic outlines, hand holding isn't strictly necessary :) > Where are things missing to grab the code more easily. we really need projects.kde.org to ship xml descriptions and for those to be referencable from kdesrc-build. once we have that, we can bang the drums repeatedly to the testing+developers audience about how easy it is to get a KDE build up and running. that remains one of the most daunting tasks to date. > I am currently trying to recruit a new developer and I would like to see i have found that the easiest (though not necessarily "easy" ;) way to do this is to have an intriguing story for people which gets them interested and a set of concrete tasks they can dive right into. we could as a combined kdebase- workspace dev community start in on a subtle developer recruitment campaign in our blogs and elsewhere in 2011. we all need more and new blood :) > With Wayland many things have to be moved into the compositor, like what's > today kdm, screensavers, etc etc. So we really need to get Plasma devs > starting working on KWin ;-) before we hit kdm and screensavers (widening the scope even further), i'd like to see us get our plasma-desktop house in order. the presentation of the dashboard and wallpapers, screen edge handling and effects (e.g. the panel glow), etc. we've done great work to date with pushing more and more into kwin, but we have a few remaining "great ideas, just shouldn't be in the plasma shell" features :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-de
Re: The state of KWin
On Sunday 26 December 2010 19:13:17 Aaron J. Seigo wrote: > kwin itself is likely more resistent to needing current kdelibs, so it > could be possible to just provide that + some libs from kdebase-workspace. I was running kwin trunk with everything else from 4.5 till something like two weeks before beta1. The only problem was Oxygen, which I just did not build (kwin used happily oxygen from 4.5) and two weeks before beta1 some additional dependencies to workspace was introduced. So it was almost possible to run a complete cycle on just kwin from trunk. And like Aaron I have a local installation of trunk and current branch. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The state of KWin
On Sunday, December 26, 2010, Markus Slopianka wrote: > On Sunday 26 December 2010 14:19:37 Martin Gräßlin wrote: > > I > > just cannot understand that problems like slowness of Present Windows > > with NVIDIA is reported by users in the beta phase several month after > > the code hit trunk! > > I would be cool if there was a separate "kwin-test" (or so) package that > depends on the latest stable Platform/Workspace and whose KWin binary also > has a different file name and whose settings are stored in different > files. this is primarily a packaging issue: when you build from sources, you can already have a different target install directory and keep different version builds separate (i have the default suse 4.x install and my svn trunk install, for instance; from time to time, i use apps from the suse packages that i haven't built from sources myself) the catch is that plasma-desktop/netbook often relies on kdelibs of the same age, so it can be difficult to have just current plasma without also having current kdelibs. since kdelibs is forwards compatible, this doesn't pose a problem for other apps aready on the system. kwin itself is likely more resistent to needing current kdelibs, so it could be possible to just provide that + some libs from kdebase-workspace. what i am hoping is that once we have falled into a working routine with git that we will have a branch that is used for release only that remains pretty darn stable, getting updates every couple of weeks only, making it reliable enough for daily usage by testers in your situation. this doesn't solve if for the rest of kdelibs and kdebase, at least not yet, but perhaps it's a step in the "right" direction. even now, svn trunk is only very occassionally in a bad state (most people overestimate the troubles of it), so i don't think we have all that much further to go with git to really get to a "can be used for testing in a daily manner" place. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The state of KWin
On Sunday 26 December 2010 14:19:37 Martin Gräßlin wrote: > I > just cannot understand that problems like slowness of Present Windows with > NVIDIA is reported by users in the beta phase several month after the code > hit trunk! I would be cool if there was a separate "kwin-test" (or so) package that depends on the latest stable Platform/Workspace and whose KWin binary also has a different file name and whose settings are stored in different files. I have only one PC available for personal use and as long as the stable/unstable choice is exclusive, I simply can't afford to switch to a SC version that is not at the very least in RC stage. That would also enable me to occasionally use kwin-test on the PC at work (for which I have root rights) and leave all the others of its users with the stable KWin version. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
The state of KWin
Hello, let me break the Christmas silence by writing a long post about the current state of KWin and where we are heading towards in 2011. As this also is about Plasma I sent it to both lists. I have been thinking a lot about the last year and the state of kwin over the holidays and here is the summary. Sorry that it is that long. *Plasma and KWin* I consider Plasma and KWin as the integrated product of the KDE workspaces. Both products depend on each other and do not make much sense without the other. This is also reflected when looking at our developer base: we have almost a 100 percent match. We currently see great improvements on the syncing of our working procedures. Using reviewboard, having common processes for git and so on. I hope with the switch to kdelibs coding style (scheduled for directly after import of KWin-GLES) and removing bug mails for KWin mailinglist to have improved the situation for Plasma devs. If there is anything from a Plasma perspective to improve it even more, please let me know, I am open to all suggestions. *Driver situation* We had a very bumpy ride with the 4.5 release. We introduced new (optional) hardware requirements which just failed with free drivers. We noticed too late that we had a problem and shipped with the broken setup. The last minute adjustments like the blacklist did not solve the issue at all. 4.5 showed that we have no way of testing KWin on a various set of hardware. I was able to test KWin on just one NVIDIA system at the time of 4.5. Nowadays it increased to three and soon will be four, but it's nothing. There are houndreds of combinations and we cannot even try to test them all. We need to raise the awareness that at least all KDE developers who run trunk have to report new introduced problems ASAP. I just cannot understand that problems like slowness of Present Windows with NVIDIA is reported by users in the beta phase several month after the code hit trunk! Nowadays it looks better. The reports on broken drivers decrease and we have platform detection code and can now disable features for cards we know that they don't provide a feature even if the driver tells us it does. We do not make use of it, but I hope to see it used everywhere in 4.7 where we check for available features. For 4.7 we will see a new rendering path which has been developed using Gallium3D, so here we will also see more hardening and I want to submit our complete rendering engine as piglit tests. *Elegance* In the second half of the year the development focused on what Aaron would call Elegance. We were able to increase the performance significantly in many different areas. The new effects like dashboard, screenshot or startup feedback clearly fall into this category. I want to see this continued in the next year. KWin is a great window manager, let's smooth the rough edges and get the desktop use the advantages of OpenGL compositing. *GSoC* During the last two years we had two GSoC and one SoK projects. While they add great functionality they are a complete failure from a maintainance point of view. None of the developers stayed, the code is partly buggy and even crashy and in case of the JavaScript bindings we do not even have any documentation on techbase how to write scripts. For the next GSoC I will not accept projects adding new features and I would prefer having students known to the KDE community (I am thinking about some members of the Plasma team here). We need projects which increase our code quality and not adding more problems. *Manpower* Manpower is in my opinion the biggest problem of KWin. We are just three developers + Chani and Ivan working on activity related code. I would like to get more Plasma developers working on KWin. It should be a natural thing to touch KWin code and to add new features in KWin if it makes sense. Here I would like to know from the developers sometimes working on KWin what needs to be improved. Where are things missing to grab the code more easily. I am currently trying to recruit a new developer and I would like to see KWin having a fulltime developer - we have enough to work on. I at least plan to look into that topic in 2011. *GLES* The port to OpenGL ES is nearing completion. I will finish the port of cube (almost done) and leave out the remaining unported effects at the moment (mostly shader based effects like blur which need some more thoughts). I will switch back to desktop GL to ensure that everything is still working and then call for testers (depending how much spare time I will find next week it will be the next or the second next weekend). GLES gives us a much more modern rendering backend which I expect to perform much better and gives us the chance to add more elegance to the desktop ;-) The improvements through GLES will also benefit desktop users using a modern enough driver. Unfortunately the decision whether ES or desktop GL is used, is
