On Mon, 11 Aug 2014 18:05:42 -0400 "Jasper St. Pierre" <jstpie...@mecheye.net> said:
> Rotated windows are not the only reason, but they do contribute. The > ability to do an arbitrary transformation on the window is a very useful > feature, for e.g. HiDPI support, and we'd like to expose as little data to > the client as possible so we can enable better use cases. > > The client cannot get or set any transformations on its windows. And it > will never be able to, as long as Kristian, Pekka, Jason, and I are writing > the protocols and the code. totally agree with you on this. there is a danger though. other wl compositors may add it as an extension of their own and then one toolkit breaks rank and uses/needs it and before you know it - all toolkits do this and you have a problem on our hands. the best is education - for developers and toolkit devs. why manual absolute positioning is bad. (your hidpi example is a good one- auto scale "lo dpi" apps up to 2x2 size or whatever). > On Mon, Aug 11, 2014 at 5:59 PM, Bill Spitzak <spit...@gmail.com> wrote: > > > I don't think rotated windows are the reason they are not supporting > > window position. > > > > Also the corner of the bounding box is a really awful control. Best to > > just use on of the corners, or the center. Assume the client can either get > > or set the rotation so it knows the actual bounding box. > > > > > > On 08/11/2014 09:49 AM, Nils Chr. Brause wrote: > > > >> On Mon, Aug 11, 2014 at 12:57 PM, Giulio Camuffo > >> <giuliocamu...@gmail.com <mailto:giuliocamu...@gmail.com>> wrote: > >> > >> The problem is that windows don't always have a meaningful position. > >> If a window is shown on two outputs at the same time, maybe one of > >> which a remote one, what is the window position? And what is the > >> position of a window rotated 45 degrees? > >> > >> > >> Since the question about absolute positioning of windows comes up every > >> now and then (and probably will continue to do so for the next few > >> years), I thought about a possible way to fix this. > >> > >> We could create a new interface, that puts an unrotated rectangle around > >> a window (which could be transformed in whatever way), that is just big > >> enough to fit in the whole window. The upper left corner of this > >> rectangle could then be defined as its "position", which could be read > >> and set by the user. The size of this rectangle could also be of > >> interest of the user, but of course not be set. > >> > >> Since a window could be on multiple outputs, there would be the need for > >> one instance of this interface for every output and every window. These > >> could maybe be created and destroyed with events (whenever a window > >> appears or disappears on an output). > >> > >> This is not 100% thought through, but maybe a starting point. > >> > >> > >> > >> _______________________________________________ > >> wayland-devel mailing list > >> wayland-devel@lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel > >> > >> _______________________________________________ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > > -- > Jasper -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel