<div dir="ltr">Hi,<div>As others said - thanks for kicking this off. I think it's pretty long overdue. The 'release roadmap' mails I guess were meant to do this in a way, but never really got anywhere ...</div><div class="gmail_extra"><br><div class="gmail_quote">On 8 December 2014 at 12:01, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">To reiterate the main points:<br>
- the reference implementation<br>
- minimal<br>
- fast (performant?)<br>
- suitable for embedded and mobile (and now automotive?)<br></blockquote><div><br></div><div>To me, 'embedded and mobile' here really just means that the user interaction requirements with the core environment are quite limited. To me, this is primarily defined by a negative goal: we are not, and never will be, a desktop environment to compete with GNOME, KDE, Cinnamon, Openbox, whatever. This turns out to be just fine for mobile, automotive, set-top box, digital signage, etc, because while they do need a really good compositor, they don't need wifi configuration, runtime-configurable favourite launchers, etc, etc.</div><div><br></div><div>So it's less a question of Weston's, and more desktop-shell's.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I believe it means, that Weston needs to implement all the important<br>
desktop-related protocol extensions, obviously starting from xdg_shell.<br>
This is the reference implementation. However, other desktop-oriented<br>
protocol extensions might not be that obvious. How would we judge them?<br>
I guess it has to be case by case, which makes it hard for any one<br>
person to do.<br></blockquote><div><br></div><div>I think this has been pretty valuable, especially whilst we didn't have any other real compositors of note. But now with Mutter being more stable and QtWayland being infinitely more sensible in 5.x, we don't have a hard requirement on that anymore.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Should we add one more goal for Weston: a simple desktop environment?<br>
But how simple? Would it include, say, a tool to do permanent video<br>
mode changes? A real screen lock? A task list? Also see the note about<br>
"camp agnostic" below, which limits the realistic possibilities a lot.<br></blockquote><div><br></div><div>A desktop environment? Please god no. A platform that people can develop desktop environments on? Sure! I guess a lot of those would be fine as Weston plugins, though ultimately we'd need something like libweston to make that workable. My biggest problem with libweston as it stands is that I think it stands to repeat the X.Org 'API' disaster: just copying all your header files into a directory somewhere and installing a library isn't an API. I'd like to have a much more serious look at what we expose, how, and why.</div><div><br></div><div>That would be quite a bit of work, but I think far more valuable if it allows us to get rid of large swathes of desktop-shell.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Then again, why was IVI-shell merged? My own opinion is that IVI-shell<br>
serves the embedded (automotive) space. The people pushing it had a<br>
strong will to see it upstreamed to Weston, and I have understood they<br>
are committed to maintaining it. It's not just a code drop, there is<br>
more to come. I hope that it will also bring new contributions and new<br>
contributors for all over Weston, benefiting also the desktop.<br>
<br>
IVI-shell is also, for a long time or maybe ever, the first non-desktop<br>
shell in Weston intended for applications and not mostly for nested<br>
compositors like the fullscreen shell. It helps to clarify the concept<br>
of shell (protocol).<br></blockquote><div><br></div><div>I think the same arguments apply to features you'd see in the environments I listed above. These don't have particularly heavy requirements on things like desktop-shell, and Weston is perfectly usable for them as a minimal, stable, reliable, and fast compositor.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Then what should we not put in Weston?<br>
<br>
So far Weston has been kept deliberately "camp" agnostic, which means<br>
that dependencies to GNOME, KDE, E or similar "camps" are not allowed.<br>
In practice, Weston should never even optionally depend on GTK+, Qt,<br>
EFL, or such. Weston does optionally depend on glib, but I suppose that<br>
is acceptable considering the features depending on it. It has been camp<br>
agnostic to not favour any particular existing DE camp, and to not<br>
alienate any other DE camp.<br>
<br>
I think walking that middle road has been good, and we should continue<br>
that.<br></blockquote><div><br></div><div>I agree. I think GLib is pretty much fine, given that Qt has been depending on it for quite some time. It doesn't handle OOM situations gracefully, but we probably don't either. I was going to suggest that this would make it unsuitable for some critical devices, but given that I know of medical devices deployed using GTK+ on Wayland, I guess that boat has already sailed. ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
What do you think what Weston should be in the future?<br></blockquote><div><br></div><div>I think where it is at the moment is pretty much fine, but we really need to look at desktop-shell. I'd like to see most of the shell gone, and instead some alternative environments spring up to take the load: environments which are actually usable, which shell.c barely is.</div><div><br></div><div><br></div><div>On 8 December 2014 at 23:26, Bryce Harrington <span dir="ltr"><<a href="mailto:bryce@osg.samsung.com" target="_blank">bryce@osg.samsung.com</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">But Weston's development processes seem to be set up more for product<br></span><span style="font-size:12.8000001907349px">development than for freeform R&D.  Namely, we have one single "true"<br></span><span style="font-size:12.8000001907349px">tree with a gatekeeper to control what gets committed, reviewers to<br></span><span style="font-size:12.8000001907349px">catch quality issues, and a growing testsuite.</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">I'm not saying this is wrong, just that this is probably not ideal for<br></span><span style="font-size:12.8000001907349px">facilitating experimentation; folks may prefer to gravitate towards<br></span><span style="font-size:12.8000001907349px">other compositor development projects where they can turn ideas and<br></span><span style="font-size:12.8000001907349px">patches around more swiftly.  And that's not necessarily a bad<br></span><span style="font-size:12.8000001907349px">thing... but it's different than considering weston as a test bed.</span></blockquote><div><br></div><div>Hmm. I think our biggest problem with review is that the one-reviewer model doesn't scale. We currently have Patchwork to address that in an ad-hoc manner, but could we do better with more tooling? Something like Gerrit perhaps? I don't want to give up on the review + gatekeeper model, because while it does have its limitations (particularly whilst we only have one of them), I really don't want to go back to the old model.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">The other option is to get weston's head and heart aligned, and<br></span><span style="font-size:12.8000001907349px">strengthen our focus on being "just" a test bed for improving the<br></span><span style="font-size:12.8000001907349px">Wayland protocol.  Give our community's primary attention not to<br></span><span style="font-size:12.8000001907349px">Weston's users but Wayland's users - Enlightenment, GNOME, KDE, and<br></span><span style="font-size:12.8000001907349px">other DEs.  Survey and study their requirements and look for things they<br></span><span style="font-size:12.8000001907349px">need across the board.  And make it easier for them to bring us their<br></span><span style="font-size:12.8000001907349px">problems/ideas/needs.  Make it convenient for people to do prototyping<br></span><span style="font-size:12.8000001907349px">and experimentation in Weston first, and then port to production<br></span><span style="font-size:12.8000001907349px">compositors, rather than vice versa.  Instead of unit testing weston,<br></span><span style="font-size:12.8000001907349px">improve the validation testing of wayland, such that the same testsuite<br></span><span style="font-size:12.8000001907349px">would run against the weston compositor, enlightenment compositor, et al<br></span><span style="font-size:12.8000001907349px">to verify that the DEs have properly implemented the protocol<br></span><span style="font-size:12.8000001907349px">requirements.  Instead of delivering a monolithic Weston package, turn<br></span><span style="font-size:12.8000001907349px">the best bits of it into specialized libraries that DEs can use too (if<br></span><span style="font-size:12.8000001907349px">they wish).  Define a clear process for 3rd parties to contribute<br></span><span style="font-size:12.8000001907349px">extensions, libraries, and driver support changes.  Finally, work to<br></span><span style="font-size:12.8000001907349px">change public perception to stop the expectations on producing<br></span><span style="font-size:12.8000001907349px">Weston-the-desktop, by vocally championing DEs that are already giving<br></span><span style="font-size:12.8000001907349px">solid Wayland-based desktops.</span></blockquote><div><br></div><div>This is definitely one of the better attempts at a mission statement I've seen. I'd like to keep the caveat that Weston as-is is perfectly suitable for the more limited environments - who usually require next to zero interactive window management - and that having a single implementation which is by-default usable for them is a good thing. This also makes it _much_ easier to do validation of, e.g., drivers. But yes, I'd like to see more parts of Weston being reused by others. It'd require a commitment to review, documentation, API stability (ha ha) and support which has not always been present, but if we can do that, then great.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">I know from looking at patchwork lately how big of a workload this is<br></span><span style="font-size:12.8000001907349px">for one person.  I would be more than happy to lend a hand with<br></span><span style="font-size:12.8000001907349px">maintenance; I do maintenance on Cairo, am release manager for Inkscape<br></span><span style="font-size:12.8000001907349px">and used to maintain the X stack for Ubuntu, so have some experience<br></span><span style="font-size:12.8000001907349px">here.  Samsung has a strong interest in Wayland right now, so the<br></span><span style="font-size:12.8000001907349px">maintenance work would be a day job priority.</span></blockquote><div><br></div><div>To add to what Pekka just said (if so, great! if not, oh well): I don't think there's any reason this needs to be a one-person thing. I found Kristian's patch-queue-status mails to be incredibly valuable, and whilst they really benefit from maintainer input, I don't think they're something which needs to be held by the maintainer, and can in fact be a huge help to a maintainer, as a signpost to bits they may have missed or need to pay attention to. Also the others: I'd definitely read it, and if I saw 'needs attention from an input person' or whatever flagged, go have a look at it. If there's anything that's blocking you in any way from doing these (Patchwork, mails, wiki, account access, patches needing review), please make noise about it until someone does something about it.</div><div><br></div><div>On 9 December 2014 at 13:40, Giulio Camuffo <span dir="ltr"><<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@gmail.com</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">This is not to say we shold not have, say, a xdg_shell implementation.<br></span><span style="font-size:12.8000001907349px">That is a very basic building block of a wayland desktop shell, so it<br></span><span style="font-size:12.8000001907349px">fits perfectly there. Stuff like expose or the broken virtual desktops<br></span><span style="font-size:12.8000001907349px">implementation, not so well, imho.</span></blockquote><div><br></div><div>As the person who merged Exposay, I'd be a big advocate for removing it. Ditto the virtual desktops. But in the absence of a strong external user, they are actually really useful: Exposay ensures our transform and animation frameworks continue to work properly, and the workspaces did a lot for, e.g., weston_view. Both of these were really useful in terms of Weston's development and how we implemented backends and renders, and I'm worried that removing the two testers would break it pretty quickly. Now, if we had people using these externally (or hey, even testcases), I would love to see both of them removed.</div><div><br></div><div>On 9 December 2014 at 19:36, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">I think that Weston's performance matters a lot in some respects and not much in others.  We don't want to overcomplicate things by prematurely optimizing or squeezing out every clock cycle we can.  However, Weston does give us the opportunity to show off some of cool performance things the Wayland protocol allows us to do.  One example of this is the planes support in the drm backend.  Weston may be the only desktop compositor around today that take a single subsurface out of a window, put it in a plane, and flip it directly to the screen.  This is fantastic for performance and power usage and is one of the advantages of the Wayland protocol.  If people come to us complaining that "you can't do that in Wayland" just because GNOME or KWin aren't doing it, we can point to Weston and say, "See, yes you can, they just aren't".  Another fantastic example of this is the way the RPi backend uses planes.  So I think showing off performance things we can do thanks to Wayland is important, squeezing out clock cycles isn't.</span></blockquote><div><br></div><div>This was the other reason for merging Exposay ... </div><div><br></div><div>Cheers,</div><div>Daniel </div></div></div></div>