Hi, On 29 September 2015 at 14:05, Benoit Gschwind <gschw...@gnu-log.net> wrote: > Maybe my thought is insignificant, but I would like to share it anyway, > as young window manager developer.
It's fair enough, and I see what you have to say. All I really have to say in return is two things: - if we add global co-ordinates back now, we can never remove them: people will rely on them, and removing them will break peoples' apps. As the kernel's regression policy has shown, it's better not to break things that work already. - certainly neither of those things have happened yet, but that doesn't mean they can't ever happen; if we exposed global co-ordinates, people would just use those and _never_ work on these sensible replacements, thus removing all incentive to work towards a better protocol For those reasons, I'm holding out personally. (FWIW, the XWayland integration picks one 'master' view of a surface for positioning purposes, and ensures that XWayland positions its windows at the same point, to account for X's dependence on a global co-ordinate system.) Cheers, Daniel > I think all your arguments (both side) are valid. But I will defend the > point of view of Jasper. While technically I agree there is no need of > absolute positioning and many solution are available to solve issues of > no-absolute position. I will submit 3 arguments. The first one is that > current proposed solution of no-absolute position case are not existing, > i.e. only marginal, experimental or not at all implemented, but there is > many running software out there that rely on legacy absolute position. > Jasper (as I understood) propose to add a layer to make the transition > smoother and easier. This doesn't hurt too much, imo. > The second one is that most of main stream software transition follow > this rules, having a transition period (or "mercy" period), I will take > three examples. Within gcc architecture that are not maintained fall in > deprecated state for few release cycle, if no one maintain it during > this "mercy" period, they get removed. The developers have few release > cycles to adapt. GTK use a similar policy by deprecating APIs. And the > last exemple, I still be able to run 32 bits apps on my shiny new > laptop. I think it's no hurt to give the opportunity to the developer to > have a "mercy" period, within they can learn Wayland and adapt their > software. > The third one is that even if you try you best to have a clean protocol, > I'm sure developers will find ways to abuse or exploit your protocol in > a way you never thought. In those case I think the best choice is to > manage those exploits and not trying to _enforce_ you protocol (I do not > cover security with this sentence). > > All in all, I think that having a dedicated "compatibility to X11 > legacy" extension is useful, this extension can be deprecated and > removed over time, until solutions proposed are effectively implemented. > I also agree that this layer should be smallest as possible. With this > kind of extension, old X11 developers can get used with Wayland > philosophy and learn. If you put a tall fence between old developers and > wayland, you will be in lose-lose case, application developers will hate > you for your unshakable church and you get less people that use your > work. I also want to recall that old software have also a lot of > experiments behind them and this is them that will have the most hard > work: migrating to Wayland. In his side, Wayland is a small peace of > code (and the protocol is even smaller). > > Best regards. > > -- > Blocage > > "The most secure network protocol is no-network at all". > > > On 28/09/2015 20:55, Daniel Stone wrote: >> Hi, >> >> On 28 September 2015 at 16:54, Jasper St. Pierre <jstpie...@mecheye.net> >> wrote: >>> To be honest, the more I think about it, the more likely I am to just >>> want to add back in a global coordinate system. There's too many >>> problems that GNOME is having by omitting it. For starters, menu and >>> tooltip positioning that works correctly. >> You don't need a global co-ordinate system for that: >> http://lists.freedesktop.org/archives/wayland-devel/2013-April/008665.html >> >>> Saving and restarting window >>> positions is something that I've desperately missed ever since I >>> started using Linux on my multimonitor desktop rig again. >> You don't need a global co-ordinate system for that: the consensus for >> save/restore has long been for a cookie-based system, which would >> allow the compositor to store position, workspace, and any other >> attributes. >> >>> I don't see many of the advantages of omitting a global coordinate >>> system anymore, and I don't see many downsides, and a lot of issues >>> we're having seem to be predicated by this. I want Wayland to succeed, >>> and that might mean that we go back to a simpler idea. >> Those are two problems, both of which are well understood and >> relatively easily solved. >> >> Omitting a global co-ordinate space does solve a great deal of >> problems, particularly in the input space, and opens up a whole array >> of possibilities that X's communication of a flat global co-ordinate >> space precluded us from ever pursuing. Rowing back on that because of >> two problems which can be better solved elsewhere would be a real >> waste, and not something I've seen any appetite for amongst the >> others. >> >> Cheers, >> Daniel >> >>> On Mon, Sep 28, 2015 at 2:13 AM, Daniel Stone <dan...@fooishbar.org> wrote: >>>> On 25 September 2015 at 18:46, Bill Spitzak <spit...@gmail.com> wrote: >>>>> On Fri, Sep 25, 2015 at 1:37 AM, Pekka Paalanen <ppaala...@gmail.com> >>>>> wrote: >>>>>> It is a design decision in Wayland/desktop to not expose absolute >>>>>> window positions to clients at all. This means that you simply cannot >>>>>> know where a top-level window is precisely, you can only know which >>>>>> outputs it overlaps with. >>>>> This is an interesting experiement but I believe it is doomed in the long >>>>> run. I would try it >>>> We have, ever since Wayland's creation. It works. >>>> >>>>> but I think the end result is that every single desktop >>>>> environment will add this as an "extension" >>>> None of them have: not GNOME, not KDE, not Enlightenment, not IVI, not >>>> digital signage, not video walls, not set-top boxes, not smart TVs, >>>> not Weston/Maynard on Raspberry Pi, not phones/tablets, not anything. >>>> >>>>> because so much software will not work without it. >>>> It does. >>>> >>>>> You have to realize that X and Windows and OSX all use >>>>> 2 numbers to describe the location of a window >>>> Yeah, I'm well aware of how the X input stack works. >>>> >>>>> and thus getting software to >>>>> stop assuming that is probably a Sisyphean task. >>>> It hasn't been. >>>> >>>>>> Windows that are not top-level can often be placed relative to another >>>>>> wl_surface. This is the only form of precise positioning supported on >>>>>> desktops. >>>>> This is correct and could make it work in the vast majority of cases, but >>>>> supporting portable programs is going to be difficult and hacky. Qt code, >>>>> for instance, calculate QPoint objects (which contain 2 numbers) and >>>>> assume >>>>> the result fully defines where a menu will pop up. Now they usually >>>>> calculate these by asking for the position of existing widgets and adding >>>>> offsets, so if the returned coordinates are in a space such that the >>>>> future >>>>> parent is at 0,0 then this will work acceptably. But I fully expect Qt to >>>>> first look for the window-position extension and use that if possible, >>>>> with >>>>> this hack as a rarely-used fallback. >>>> Your expectations are wrong. Look at how Qt has worked just fine (and >>>> shipped in many environments) without it for years. >>>> >>>> This is another dead end of a thread. It's been this way for years >>>> because of very valid reasons, it works (despite you being convinced >>>> that it could never work) fine, and it's not changing. >>>> >>>> If you'd like to productively contribute to this, perhaps you could >>>> pick up the surface position negotiation protocol, which would allow >>>> clients to guarantee that menus would not be positioned off-screen. >>>> >>>> Cheers, >>>> Daniel >>>> _______________________________________________ >>>> wayland-devel mailing list >>>> wayland-devel@lists.freedesktop.org >>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >>> >>> >>> -- >>> Jasper >> _______________________________________________ >> 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
