Please, reply-to-all so CC's do not get dropped. On Sun, 29 Jun 2014 19:25:04 +0200 Fabrice Rey <[email protected]> wrote:
> > "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?" > > 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. You are thinking in X11 terms now. It is not certain we will have all these in a Wayland desktop shell protocol (xdg-shell) as there might be better Wayland style solutions to the actual use cases, rather than just replicating X11-related APIs. Do you want every single application to be able to screw up those hints individually, or do you want the compositor to just do the right thing for everything? A lead idea here is, that a client tells the compositor the intent or purpose of the window, and the compositor then lays it out in the best possible way, that the app itself might never know how to do. > > "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." > > Why not, that can be a solution, although it will break the behavior of the > existing applications. > 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). That is right, because they are just normal top-level application windows. You are not telling the compostor they are desklets, because we have no way of doing that yet. Each DE will cook up its own way, and if a common standard emerges, it emerges and allows "DE-agnostic" desklets. This way every DE can do what is right for them rather than being restricted by some designed-by-committee protocol mandated from above. We are not simply copying all mechanisms like global coordinates from X11, because we want to do better: let the compositor be in charge, have interactions be well defined, avoid glitches, etc. > 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. > The compositor places them wherever it wants, like with any window. > Really, just like it works now with any WM that have some desktop effects > (so almost all). http://people.collabora.com/~pq/menu-rotate.png http://people.collabora.com/~pq/rotate3d-pixman-more.png Those are not just temporary effects, I can actually leave the windows be like that, and interact with them *correctly*. That means things like mouse cursor position being relayed right for each window, which cannot be done if using global coordinates. If we had any global coordinates in the protocol, that would be practically impossible. (While the screenshots above are using 2D-projective matrices, nothing prevents you from doing completely non-linear transformations, and everything will still work right without any fixing in apps.) Weston also already can present one window in several places (as in several copies), we just do not take much advantage of that feature yet. Each copy of a window is roughly equivalent, they all will (if the compositor wants) respond to input etc. In all these cases, at least I would have great difficulty in defining what "window position" even means. There is no "normal time" vs. "not normal time". > Now, I see your point, but will the compositor really be able to place them > correctly ? The compositor will have *much* better chances than the app: the compositor will know about all windows, an app only knows about its very own windows and _nothing_ else. IOW it will be very difficult for the app to e.g. avoid obscuring or being obscured by some other window, if it manipulates its global position. > 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. No. The compositor is changing the resolution, the compositor can move any window at any time. It will Just Work. Even better, when the resolution is changed, the desklet will be immediately in the correct new position. No glitches, no jumping after the fact. Btw. what if you start two desklets? Both go in the same corner? On top of each other? Do you need to manually configure each desklet to go in a different corner? > 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). See all above. It is a very deliberate decision to not include global position in the protocol, and we have worked hard on that. > 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. You have to start thinking in a new way. The compositor is no longer under the mercy of every single app like in X11. In this new world, the compositor decides. First, figure out what the use case is. An application does not want to "put this window at 100,150 always-on-top not-focuseable". Rather, the application wants to, say, show a clock widget on the side of the workspace for instance. Then you start figuring out what information does the compositor need to make that window interact with all the other windows and the desktop space properly, and that leads to a protocol extension definition. If the extension is good, generic and re-usable, then it might suit more than one DE, at which point it may become a desktop standard. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
