Re: Live CD and others general GNUstep remarks

[Gregory John Casamento]

Fred,

--- Fred Kiefer <fredkiefer@gmx.de> wrote:

> Hi Greg,
> 
> looks like I did not express myself clear enough. I should rather learn 
> from Andrew and only reply to mails when I am sober enough. But who 
> would want to wait that long?

Hehe. :)

> One more try, although the conditions aren't any better: The current 
> code for stored defaults of window frames, stores the screen size (or 
> rather the screen rectangle) along with the window frame. This allows to 
> adjust the window position when reloading it. What I wanted to suggest 
> was to do something similar in Gorm, store the screen size (or rect) 
> beside the window frame and adjust the window frame, when the loaded 
> screen size (or rect) does not fit the current one.

After much experimentation creating apps and then starting them on a machine
with a smaller display or using Xnest to make the display much smaller, I find
that the windows are being constrained to the screen area, although not very
elegantly.   

I have had trouble in the past when I copy my defaults from another machine
(with a different display geometry) and then start apps on the machine with a
smaller display geometry and the windows appear outside.

> All the code is there, we just need to extract it to a separate method 
> and add the archiving and unarching of the screen size to the NSWindow 
> class (or should we move all that code to the window template as Cocoa 
> did?).

I believe that we want to do something like this, yes.  I believe that the
ultimate solution is to implement something similar to the window "auto
position" which is currently in Cocoa.  I am going to start looking into this.

GUI persists window placement information in defaults.  I believe the problem
with respect to the LiveCD is that the screen resolution for the user trying it
 may or may not match the resolution which was used for those applications when
the CD was created so, as stated previously, there might be an issue there.
 
We, however, do seem to have a problem either way.  I will look into
implementing something to make the placement of windows on smaller displays
more elegant.

> Hope this is a bit more understandable.

I didn't misunderstand what you said before. :)
 
> Fred
> 
> 
> Gregory John Casamento wrote:
> > --- 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.
> >>
> 


=====
Gregory John Casamento 
-- CEO/President Open Logic Corp. (A MD Corp.)
## Maintainer of Gorm (IB Equiv.) for GNUstep.