--- Fred Kiefer <fredkiefer@gmx.de> wrote:
There was also the problem that some apps had their windows "outside"
the screen. Actually, at the moment
the windows' positions are encoded in the gorm files... and imho that's
a bit wrong ! with wmaker it's not that much
of a problem, because you can move the windows with alt-clicking... but
that's only true if you know that trick :-)
Frankly, the windows' position shouldn't be encoded in Gorm; it's just
wrong.
Not wrong, when the window is placed on the sceeen by gui, it should not place
it outside of the existing screen. If it is doing this, that is the wrong
behavior.
This sounds like it needs to be changed. Perhaps we could use similar
code as is applied for default settings (see below). We would need to
archive the screen rectangle along with the window frame. Gregory, as
window encoding is very much Gorm related, I would like to get your
opinion on this first.
Window positions are, and will continue to be, encoded in .gorms as they are
also encoded in .nibs. If we don't have a starting position where should the
window be placed the first time the app starts? :) What is needed here is
something akin to what IB under MOSX has currently which is a way to specify a
"dynamic position" for the window much like you specify how a view resizes
itself.
There also should be code added to NSWindow which prevents an app from
positioning a window outside of the existing screen and this is a modification,
if it's not already in NSWindow, I'll add it.
In case you need further proof.. to demonstrate the preceeding to yourself,
start a project under MOSX Cocoa and use IB and set the position of the new
app's window. Then build the app and watch that the window shows up exactly
where it was positioned in IB. Additionally, if you go to the NSWindow size
inspector in IB, you will see the width, height, x, and y information for the
window in addition to the "Auto position" portion which I just described. So,
this is not a case of information being encoded "by accident". :)
Another related problem (not specific to the live cd) is that apps save
their windows position in the defaults
database -- that's good, but there's a slight problem: If the user
change resolution to a lower one...
One solution, perhaps, would be to associate the positions with the
actual resolution -- so you'd save the positions
for each resolution...
Again, there should be code which reconciles the screen size with where the
windows are placed, as above. :)
No, this should not cause any problem, the code already adopts the
window position to the screen size, just as you did suggest
(setFrameFromString:). It does not try to change the size of the window,
though.