On Saturday 27 October 2012 00:45:14 Ryan C. Gordon wrote: > > What if there are two windows which want the exclusive state? Maybe a > > manager selection is a better solution? > > The spec currently says that the newest window gets the screen...since users > can alt-tab (or whatever) between them, this means the user can control > which one they want to deal with at any given moment. > > The intent is that multiple fullscreen windows--which I expect to be rare, > but possible--can coexist, but I'm okay with whatever people agree is > appropriate behavior for managing them. > > Maybe the window manager just set a root window property if the resolution > > is "temporarily" changed for a window? That would allow other parties to > > ignore the resize event. E.g. a desktop shell adjusting itself to randr > > events could look up the root window properties and ignore the randr > > event. > > To be clear, KWin (or krandr?) is getting an XRRScreenChangeNotifyEvent, and > then resizing windows in response to that, and not the various application > windows responding directly to this event. Is that right? In KDE we don't go down to the events directly, but listen to signals screenCountChanged and resized of QDesktopWidget [1]. But KWin is clearly not the only one listening to these signals. I just searched our codebase and found usages of that in the various desktop shells and even applications. So yes applications listen directly to these events - that's what I meant with "moving to the window manager won't solve the problem" in my first reply to this thread. Here for KDE usage we need to somehow tell the applications to ignore the screen changed event. We can do that with a properietary hint, but that won't solve the problem if people run a different WM in a KDE session or use a KDE application listening to the events in a non KDE environment. Best Regards Martin Gräßlin [1] http://qt-project.org/doc/qt-4.8/qdesktopwidget.html
Attachment:
signature.asc
Description: This is a digitally signed message part.