Pekka, Thank you for your response. To clarify it, I am not developing another windowing interface that will compete with Weston or QT Compositor. My application is completely different and the open source graphics driver stack is the likely bottleneck. I'm not even sure that Mesa/Gallium can give me the rendering speed that I need. Based on the responses I've received so far I think I understand now that the client interface is a much bigger concern for the Weston developers. I will simply clone my own copy of Weston as it exists today and will commit bug fixes only as needed. And yes, I want to keep it relatively "dead" because one man's dead fork is another man's stable source. ;) Thanks, Nick <div class="gmail_quote">On Thu, Jul 12, 2012 at 5:20 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, 11 Jul 2012 23:03:06 -0700 Mikalai Kisialiou <<a href="mailto:kisialiou@gmail.com">kisialiou@gmail.com</a>> wrote: > Juan, Jonas and Christopher, > > I appreciate your feedback! Small additions to shells are indeed not a > problem. It was not a right example to make my point. As it is now, Weston > can be considered barebone since the code base is small. The question is > how long it will stay that way, given some interest from Canonical to > integrate it into Ubuntu QQ or RR (hopefully QQ) and potentially other > distros. > > Please, let me give you another example of what I'm trying to do (without > going into application specifics that you are unlikely to be interested in). > > Suppose that you want to develop your own Wayland compliant server > (W-server) that can render in 3D. Due to renderer's complexity you > anticipate that the compositor will grow quite a bit and that will pose > significant problems for future testing. > > So, before you start out, you want to set up another very simple compositor > whose job is _not_ to composite but to _test_ functionality and speed of > the graphics driver stack, X as a client, some other hardware, client's > compliance to Wayland protocol, and so on. The purpose of such a W-server > is to have a regression system that checks dependent > _libraries_and_drivers_ rather than your 3D compositor. If something goes > wrong with client's rendering (e.g. too slow, visual artifacts) you can use > that "regression compositor" to quickly identify if the problem stems from > some upgraded or buggy drivers. This will save you a lot of debugging > effort and time. > > The barebone version of Weston is the perfect candidate for the "regression > compositor". It doesn't need several full featured clients or shells to > minimize risk of injecting bugs. It only needs to include the minimal > architecture plus a set of driver/library test codes. It does need to be > relatively stable and up-to-date with the latest Wayland protocol changes > and some critical bug fixes though. > > I hope the above example illustrates one of several potential applications > for the barebone compositor. The point here is not to get rid of useful > features from Weston. They are surely needed when I use Weston as a _user_. > The above example uses the compositor as a _tester_ with predefined > composite screen objects. </div></div>End user features seems to be the ones that need most testing and are the hardest to test, especially interactions with the desktop-shell plugin. To get a bare-bone Weston, you simply don't load the desktop-shell plugin, but something else (granted, which doesn't exist yet). No need to fork anything, just write a new shell for testing the core features. Weston already has a testing framework, too. There are few tests, where an additional plugin is loaded into Weston, test clients interact with Weston, and then a fail/pass result pops out. It just needs a lot more and better tests. You run the tests by 'make check'. Once someone decides to make a software compositing version of Weston, they will probably abstract compositing into the backend or some new plugins. Then it's easy to add a dummy compositing plugin for testing everything but graphics. Forking Weston would only lead to an unsynchronized, dead fork, IMHO, if the only purpose of the fork is testing. And then, it wouldn't test Weston, it would test the fork. Thanks, pq </blockquote></div>