Re: [bugs #11713] Windows resizable when they shouldn't be

[Alex Perez]

Fred Kiefer wrote:
> Hi Alex,
>
> would you mind to put further replies into the Savannah entry? This will 
> make it a lot easier to track a bug report later on.
I would use it if it wasn't a gigantic pain in the ass, which it is. See 
below.

> Alex Perez wrote:
>
> > Fred Kiefer wrote:
> >
> > > Follow-up Comment #2, bugs #11713 (project gnustep):
> > >
> > > Perhaps I did not ask my questions in the last comment clear enough, 
> > > so I
> > > started to test them myself. I tested with the standart KDE window 
> > > manager.
> > >
> > > Leaving out the NSResizableWindowMask doesn't have any effect on the 
> > > window.
> > > Setting the min and max size of a window makes it, as expected, 
> > > un-resizable.
> > >
> > > > From this I would say we only need to understand the expected 
> > > > behaviour and
> > >
> > >
> > > implement it, no additional function calls will be needed.
> > >
> > > So here the rephrased questions:
> > > - Are NSPanels always expected to be non resizable?
> > >  
> > I have no idea, but you are being needlessly overanalytical about 
> > this. Find an app in which panels are NOT resizable (say, Gorm or any 
> > other) and open it while using the default GNOME window manager 
> > (metacity?) The windows are then resizable, and should not be. This is 
> > a gnustep-back/atom problem, nothing more.
>
> No, I don't think my questions where overanalytical. We first have to 
> agree on when we expect a window to be non resizable and than agree on 
> the way to implement it.
>  From what I understand from your mail your position on the first 
> question is that a window should be non-resizable when you think it 
> should not be resizable. This is a bit hard to implement. You probably 
> mean that some other window manager (perhaps Window Maker?) treats this 
> windows as non-resizable and you would like other window managers (the 
> one from Gnome) to do the same. But this just brings us back to my first 
> question: Why does the first window manager know that the window is not 
> resizable? As far as I can tell window managers treat windows with 
> minSize and maxSize both set to the window size as non-resizable. If you 
> find a window manager where this is not the case, we should analyse the 
> behaviour and find a workaround.
> Now Gorm panels are resizable for me (on KDE) and I think this is 
> because maxSize is not set there (and actually I am glad that this is 
> the case).
Yes, I was incorrect in citing this as an example. The perfect example, 
however, is info panels, which are almost always a fixed size. 
WindowMaker honors whichever hints are used to define "non resizable" 
and the default GNOME WM does not. End of story, you don't need to know 
any more. Please stop this incessant clarification process; it's getting 
us nowhere, and you clearly already understand the problem, so why this 
little game?
> > > - Is a window (or panel) without the NSResizableWindowMask flag 
> > > expected to
> > > be non-resizable?
> > They are resizable no matter what. You are not listening. This is a 
> > -back problem, not a GUI problem, since it clearly works properly 
> > under WindowMaker and some other WMs
>
> Sorry, this was a real question. Are windows with the flag missing 
> expected to be non-resizable?

No. Only windows which are non-resizable under GNUstep when using 
WindowMaker are expected to also be so under the default GNOME wm.

> The Apple documentation is not clear on 
> this (it just talks about resize hints not being displayed). If this is 
> an expected behaviour, we need to implement it. But there are at least 
> two ways to do so. Either we make sure that for windows without this 
> flag, minSize and maxSize (on NSWindow) always stay the same as the 
> frame size (which would happen in GUI) or we leave these values alone, 
> but pass on the actual size as max and min size as window manager hints 
> in the backend. Both ways are very easy to implement, but we should make 
> an educated decisson first.
This is what I think needs to be done, but I don't think it's done that 
way right now.

> That's why I started asking questions. Implementing something that seems 
> to work in some conditions is fairly easy, but implementing the correct 
> thing may require some testing. Actually I prefer to have the correct 
> thing implemented.

And that's fine, but I think it's pretty clear from my original 
bugreport how I said it should have been implemented, according to 
people who know about the spec in gruesome detail, which I cited in the 
original bugreport.

Alex Perez