<div dir="ltr"><div><div><div><div>> "Are they stacked like regular windows, where they're raised to the top
when you click on them or are they always stacked below application
windows? Can you alt-tab to them? Do they appear in any taskbar?"<br><br></div>They set the hints "skip_taskbar" and "skip_pager"; therefore their position on the stack is usually fixed, like always on top or on the opposite always below. For instance, I like to have a clock widget always on top and transparent to click.<br>
<br>> "it sounds like what you want is not for the desklet to tell the
compositor where it should be placed, but for the compositor to remember
where to place specific windows like desklets."<br><br></div>Why not, that can be a solution, although it will break the behavior of the existing applications.<br></div>Currently though, each time I launch some desklets under Weston they are placed randomly (and by randomly I mean at a different place each time, even out of the screen).<br>
<br></div>By the way they don't need to be aware of the current transformation matrix, nor if the Exposé view is active or not. Of course, the interesting parameter here is the position on the desktop at a normal time.<br>
The compositor places them wherever it wants, like with any window.<br>Really, just like it works now with any WM that have some desktop effects (so almost all).<br><div><br><div><div>Now, I see your point, but will the compositor really be able to place them correctly ?<br>
Say I positionned a desklet to be on the bottom-right corner of the screen; each time the resolution is changed, the desklet can reposition itself accordingly to stay in the corner. How will the compositor fill the same role ? I'm afraid when the resolution goes higher, it will just let the desklet at its current position, which will become somewhere on the screen.<br>
</div><div><br></div><div>About letting know the position, which is in my opinion more important, because I can't see a workaround like for the previous feature: I don't think adding the position in the Configure events would complicate things (the application that doesn't need it can just ignore it).<br>
It also doesn't add a new event to the API, and all toolkits already provide the (wrong) information anyway. As a developper, I find this lack of information quite inconvenient.<br></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014-06-29 18:50 GMT+02:00 Jasper St. Pierre <span dir="ltr"><<a href="mailto:jstpierre@mecheye.net" target="_blank">jstpierre@mecheye.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="">On Sun, Jun 29, 2014 at 12:41 PM, Fabrice Rey <span dir="ltr"><<a href="mailto:fabounet03@gmail.com" target="_blank">fabounet03@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 dir="ltr"><div dir="ltr"><div><div><div><div><div>> "xdg-shell is between desktop applications and the compositor, not
between some concept of "desklets" and the compositor. I don't even know
what a "desklet" is."<br><br></div></div></div><div>Well, a desklet is a desktop widget, for instance a clock or a weather widget.<br></div></div><div class="gmail_extra">They
are a bit particular in the sense that they should be placed at a given
position and have no decorations, but that's all, and as far as I know,
they have always been implemented using standard normal windows.<br></div></div></div></div></blockquote><div><br></div></div><div>Are they stacked like regular windows, where they're raised to the top when you click on them or are they always stacked below application windows? Can you alt-tab to them? Do they appear in any taskbar?<br>
<br></div><div>These things will need to be extensions. Maybe they belong inside xdg-shell, maybe not.<br></div><div><br></div><div>Really, it sounds like what you want is not for the desklet to tell the compositor where it should be placed, but for the compositor to remember where to place specific windows like desklets. I am of the opinion that the compositor is in a much better position to remember where windows go than every single application.<br>
<br></div><div>The reason we omitted global window positioning is that it over-complicates things considerably, has security issues, and doesn't work too well with dynamic multimonitor setups. Not to mention that in some cases, like remote window display or an expose-like view, you're effectively lying to the window, unless you allow them to be in multiple places or give them a full transform matrix of how they're currently displayed on the screen. And at that point, why even bother?<br>
<br>Constraining popup menus is indeed something that we need to solve. Our current thoughts is that you give the compositor a parent window and a rectangle, and the compositor will hand you back an adapted rectangle clipped to the coordinates of the screen, allowing you to figure out where the screen edges are with a single round-trip.<br>
<br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div>
2014-06-29 18:26 GMT+02:00 Jasper St. Pierre <span dir="ltr"><<a href="mailto:jstpierre@mecheye.net" target="_blank">jstpierre@mecheye.net</a>></span>:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Sun, Jun 29, 2014 at 12:21 PM, Fabrice Rey <span dir="ltr"><<a href="mailto:fabounet03@gmail.com" target="_blank">fabounet03@gmail.com</a>></span> wrote:<div>
<div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>> "By the application and the compositor they're designed for having a specific
extension that they use to negotiate the position. The compositor may allow
this extension only to known applications it launches. Or maybe not at all:
the compositor may want to do that only via plugins running on the compositor
itself."<br><br></div></div>Plug-ins are not portable, it would mean a complete fragmentation of the desktop, I hope we can avoid it.<br></div>What would be this "specific
extension" ? Isn't xdg-shell the place where such feature should be ?<br></div></blockquote><div><br></div></div></div></div><div><div><div>No. xdg-shell is between desktop applications and the compositor, not between some concept of "desklets" and the compositor. I don't even know what a "desklet" is.<br>
</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>> "Either way, as far as I know, the process is not going to be standardised."<br>
</div></div><div>Ok, but this is going to be fixed, right ? I mean, if something is missing, it's probably the time to think of it, before the protocol is written into the rock.<div><br>
<br>> "This should be solved for
all kinds of popups, including menus."<br></div></div><div>Yes, I guess you can place a window relatively to its parent. That's good, but still not enough for the use-case I presented. Since the client doesn't know where it is on the desktop, it will act as if it's in the top-left corner (by default), which will be wrong most of the time.<br>
</div><br><div><div class="gmail_extra"><div class="gmail_quote">2014-06-29 17:55 GMT+02:00 Thiago Macieira <span dir="ltr"><<a href="mailto:thiago@kde.org" target="_blank">thiago@kde.org</a>></span>:<div><div>
<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Em dom 29 jun 2014, às 17:44:46, Fabrice Rey escreveu:<br>
<div>> Hi,<br>
> First thank you for hard work on Wayland/X.<br>
><br>
> As I understand, there is no window placement on the client side in Wayland.<br>
> Because of that, a desklet application can't place its desklets on the<br>
> desktop. Currently in Weston, they are automatically placed (randomly, each<br>
> time at a different position).<br>
> How is this going to be addressed by Wayland ?<br>
<br>
</div>By the application and the compositor they're designed for having a specific<br>
extension that they use to negotiate the position. The compositor may allow<br>
this extension only to known applications it launches. Or maybe not at all:<br>
the compositor may want to do that only via plugins running on the compositor<br>
itself.<br>
<br>
Either way, as far as I know, the process is not going to be standardised.<br>
<div><br>
> Another similar problem is that when receiving a Configure event, the<br>
> position is not in the event. So for instance in GTK the coordinates are<br>
> always (0;0).<br>
<br>
</div>That's expected. Any application knows only about its own windows and never<br>
knows about the global position.<br>
<div><br>
> This is problematic, because the application might want to display things<br>
> differently depending on where it is.<br>
> For instance, on right-click, the desklet would pop the menu above it if<br>
> it's in the bottom half of the screen, and vice-versa.<br>
<br>
</div>This kind of issue should be solved on the particular use-case, as opposed to<br>
telling the application about its global position. This should be solved for<br>
all kinds of popups, including menus.<br>
<div><div><br>
> It seems that xdg-shell is to bring answers to these kind of<br>
> desktop-specific problems, so is this planned to be added in this interface<br>
> ?<br>
><br>
> Fabounet.<br>
<br>
</div></div><span><font color="#888888">--<br>
Thiago Macieira - thiago (AT) <a href="http://macieira.info" target="_blank">macieira.info</a> - thiago (AT) <a href="http://kde.org" target="_blank">kde.org</a><br>
Software Architect - Intel Open Source Technology Center<br>
PGP/GPG: 0x6EF45358; fingerprint:<br>
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358<br>
<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</font></span></blockquote></div></div></div><br></div></div></div></div>
<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div></div></div></div></div><span><font color="#888888"><br><br clear="all"><span><font color="#888888"><br>-- <br> Jasper<br>
</font></span></font></span></div></div>
</blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br> Jasper<br>
</font></span></div></div>
</blockquote></div><br></div></div>