On Sun, 21 Aug 2016 17:39:08 +0200 Armin Krezović <[email protected]> wrote:
> Hi everyone! > > As you know, I worked on this project during the Google Summer of > Code this year. > > Now that GSoC is comming to an end, it's time to present what I've > done so far. > > I've written a blog post to summarize my work during this summer, > you can find it at: > > https://armin-gsoc.blogspot.com/2016/08/summary.html > > Thanks to Wayland project for accepting me for GSoC! Hi Armin, that is an excellent write-up of your work! Kat, Quentin, IMO this is a very satifactory explanation as the "Work Product". Project comments I agree the "let's refactor a huge bunch" came as a last minute idea, but given the already done refactorings to let libweston finally become a real thing, there really was no room to have more complicated output layout algorithms inside libweston - adding it would have just complicated the output config API of the time, just to be ripped out eventually anyway. Therefore I preferred we proceeded to the ripping out phase first. Someone was bound to do that work, and I am glad I got you doing it. :-) Adding the zero-output and output hotplug testing to the test suite would have been a equally great task, so completing both was not possible. I now understand, that we will probably need the headless backend to expose Wayland test interfaces allowing direct control of outputs (and input devices for input testing) before proper tests for these things can be written. Future work Btw. do think about the output layout API a bit before you go rewriting the big refactoring series once again. Does offering an output layout API cause big parts of the refactoring you already have patches for to be rewritten, or is it just small bits of the previous work that needs tuning? If most of the pending patch series is still valid also after adding the output layout API, then adding the output layout API can (and should) be done incrementally. I have a feeling it might be better to make the output layout API with incremental patches. The refactoring you did is about moving the existing output configuration from libweston to the compositor. Adding an output layout feature is a whole new feature. From semantical point of view, they should already be separate patches (patch series). The only thing to be wary of is having one patch put some code in place and then the very soon following next patch removing or rewriting the just added code completely. Each patch should be a step towards the foreseeable goal. Side-steps are sometimes necessary and that's ok depending on the cost/benefit. Stepping backward is not ok if you can predict it. But, a step forward can be just an API, even if the implementation will need a rewrite later. Setting up API is actually more important than the implementation, since it sets up the agreement between the user and the provider of the API. Ok, that was hard to explain and it came out longer than I intended. Just saying that needing small changes to the API you drafted already does not necessarily mean you have to rewrite the old patches if they haven't landed yet. If the old patches have already taken serious review effort (and they have), it might be better to push them through as is, and push the small changes to it separately later. "Perfect" is the worst enemy of "good enough", a truth that I, too, tend to forget. Thanks, pq
pgpiSv9y7AwAB.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
