<div class="gmail_quote">On Sun, Nov 4, 2012 at 10:53 AM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 11/03/2012 10:31 PM, Scott Moreau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patch series implements several new features for the shell. The focus is<br>
a window list for the panel. There are a decent amount of protocol additions<br>
required but fortunately most of them are local weston desktop-shell protocol.<br>
The wayland protcol patch is needed for 5/7 on.<br>
</blockquote>
<br></div>
Is there a way for a panel entry to control more than one window?<br>
<br>
I think there has to be an "entry in the panel" object which is not a surface, and windows have an item saying which they belong to. The maximize/minimize events would be sent to this entry object.<br>
<br>
Since this would replicate a lot of api for shell surfaces, perhaps it should be one. I'm not sure how hard it is to make a shell surface that does not itself have a real surface. If this is possible, then this combined with a "parent surface" in all shell surfaces would allow an arbitrary tree to be associated with a panel entry. Surfaces with no parent would be panel entries.<br>

<br>
It is a requirement that the client be able to change the "parent surface" of a surface at any time and the panel correctly update on all changes that do not produce a loop.<br>
<br></blockquote><div><br>You seem to be talking about some sort of grouping algorithm which doesn't fit in the scope of this patch series. The purpose here is to have a simple way to test the new protocol. We do not want to immediately complicate things with advanced assumptions but instead, take it one step at a time. There are plenty of missing features and patches are welcome.<br>
<br><br>Scott<br></div></div>