|
From: | Alex Perez |
Subject: | Re: [bugs #11713] Windows resizable when they shouldn't be |
Date: | Sun, 30 Jan 2005 11:14:09 -0800 |
User-agent: | Mozilla Thunderbird 1.0 (Windows/20041206) |
Fred Kiefer wrote:
I would use it if it wasn't a gigantic pain in the ass, which it is. See below.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.
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?Alex Perez wrote:Fred Kiefer wrote: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.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 andimplement it, no additional function calls will be needed. So here the rephrased questions: - Are NSPanels always expected to be non resizable?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).
- Is a window (or panel) without the NSResizableWindowMask flag expected toThey 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 WMsbe non-resizable?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
[Prev in Thread] | Current Thread | [Next in Thread] |