> However, I believe you hardly ever have a real use for that. I want to make a cross-platform API that has well-specified behavior. An underspecified API that behaves differently for even the most basic tasks it's not very useful. I don't wanna say "don't expect events to fire in any order or always, don't expect commands to always work or to exhibit predictable behavior" and call that a good job. That's not a good job, that's just low standards :)
> For your specific case, why are you calling restore() twice in a row? See above, but please note that the question is a slippery slope (i.e. next you might ask why I need a restore() method at all and so on). But to answer your question: I've put restore() on the Esc key for a certain window. I was used to hitting Esc twice to get to normal state. In Linux that didn't work. I hit many little annoyances like that in the course of development which made for an awful dev experience so naturally I want to plug in as many of these little behavioral holes as I can. Apps break at the seams, not in the middle :) > But if you only talk to the WM you would never be able to render anything > into the client area of your window. WM is maybe not the right term. "WM/shell" might be better? The WM/shell should provide the _entire language of interaction _ with the user from opengl contexts to input methods to open/save dialogs. Just like the Windows API :) > Do you really think this is a good idea? It would mean that if you write > your application for Unity, it will only work on Unity. You want to make > it work with Gnome, you will have to provide a separate implementation > for that. And then another one for Kde. And another for fvwm. And > another for ion3. And another for xmonad. Etc. Yes but there wouldn't be that many because the requirements for a good WM/shell would be much higher then. You would have to make an actual value proposition to the app dev to make her target your WM. Right now your WM is just an annoying "test target" (i.e. I have to test my app on your WM because I can't be confident that my app won't misbehave just because I followed EMWH or because I use Qt or whatever). Once you have a few stable and popular WM/shells, not too many, the incentives for abstraction would then appear. Right now abstraction stems from recommendation-grade paper standards (ICCCM etc) that cover a very small portion of functionality, instead of being actual software that abstracts existing actual software. It's completely backwards. Behavioral standards are a dead-end IMHO. > Right. And if you try to force your policy on the user against the user's > wishes and the WM's design, it will be hard to make that work. I'm not sure I can link that to what I said. But anyway, this is interesting because I keep hearing that. This general distrust of the GUI developer, where does that come from? Do you think that a GUI dev should have _less_, rather than _more_ power in order to be able to do a good job at making a good UI? > And it mostly works. Descriptive standards tend to have that "mostly" effect :) Imagine if the ARM spec would be like that, we probably wouldn't have smartphones :) > Or to put it another way: If X had defined policy, we wouldn't have any > Gnome, Kde, awesome or ratpoison. We would have only mwm. If we were > lucky. Freeing the WM from the display server has enabled the > development of alternative policies. Exactly my point -- X should stay mechanism-only, but apps should not connect to it. But they shouldn't bring their own toolkits either! Instead, there should be a stable (i.e. forever backwards compat) DE+WM+everything shell API that's always on the user system like WinAPI is. It's really the only way to shave any market share from MS and to bring app devs to Linux. It looks like Canonical is kinda starting to get it, I'm not sure how seriously though :) > I think the infrastructure should not itself focus on programmer-friendly > APIs. I agree. Which is why I think X should not be visible to apps but should only be the compositing+input API of WM/shells. _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
