Re: sheets in GNUstep

[Ivan Vučica]

We should be doing this for anything window-modal anyway; even though the framework still has to take care of handling input events against main window as "switch focus to sheet and play NSBeep()", KDE's window manager decorates this nicely.

I think it's not window manager's duty to actually block events (GNUstep apps want to play GNUstep's NSBeep() for example), and I think I have witnessed KDE's WM not doing so. WM may help in blocking focus change, but I'm not sure if even that is the case. (*sigh* I guess a test program is in order :-))

Sheets are interesting compared to usual modal dialogs precisely because they also follow the window around. I went again through the EWMH spec, and it doesn't seem to specify a hint that would say "this window should be attached to this other window". I may be wrong, and some WM may interpret the hint atom you mentioned (_NET_WM_STATE_MODAL) as "please follow the WM_TRANSIENT_FOR window around".

I would suggest that GNUstep sheets should still be special compared to other GNUstep window-modal items by not having decorations, by being placed just below titlebar of the parent, and by following the parent around, even if that means having ugly framework code in absence of WM support. And a WM that comes out of GNUstep or is related to it could introduce an additional GNUstep-specific window property that would kindly ask the window manager to assist in moving the sheet around (once it has been placed).

On 20 Mar 2015, at 18:59, Eric Wasylishen <ewasylishen@gmail.com> wrote:

Hi,

Just to give my 2c: the EWMH spec has window-modal dialogs:

"_NET_WM_STATE_MODAL indicates that this is a modal dialog box. If the WM_TRANSIENT_FOR hint is set to another toplevel window, the dialog is modal for that window; if WM_TRANSIENT_FOR is not set or set to the root window the dialog is modal for its window group." - http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html

Not sure how widely that is implemented in WM's. But I'd vote for keeping sheets as windows in the backend, and passing the information to the backend that it is a sheet and which window is the parent.

There would still need to be emulation of "window-modalness" in gui since not all WM's (including win32) will implement it.

I'm not sure how close this is to what we currently have!

Cheers,

Eric

On Fri, Mar 20, 2015 at 5:45 AM, Riccardo Mottola <riccardo.mottola@libero.it> wrote:

Hi,

Doug Simons wrote:

I think you make a good point that resizing the window's content may lead to problems. With a bit of finagling it should be possible to keep the size of the contentView unchanged while resizing the window. Even though that's a bit of extra work, my guess is it will work better than trying to link two windows together. Given what I've seen in the past (e.g. with drawers), linking windows doesn't really work too well and is highly susceptible to platform-specific issues. Implementing sheets as views would avoid all of that.

imagine you are running a standard window manager and have  it draw the window decoration (the most common setup).

I the case of a sheet being bigger, how would you imagine it looking? I fear it would look like crap, e.g with an over-sized title-bar and, depending on the window manger, decorations around the box containing both.

A non-square window? complicated.

I understand your concerns.

My first question is: how do we want sheets in GS?

Right now I have apps where I have two code tracks: one for mac, one where the sheets (and drawers) are just NSPanels.

Following this reasoning, we could have just Panels, however it is probably still difficult to have them act modal only to the right window, which is the real peculiarity of sheets. Linking the sheet to the window is only a visual clue and could be avoided.
I'd follow this path: if the windowmanager supports linking it will work: think about menus. If supported, these window would be title-bar less looking just quite fine.

Second instead we could try to implement them "Mac like", where however all the questions about linking and sizing remain.

Riccardo

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep