Menu
▾
▴
#84 openWindow chokes on small second arg
This works as expected:
openWindow -n OK -g {366.0 67 370.0 425.0}
But this gives a default-geometry window.
openWindow -n OK -g {366.0 66 370.0 425.0}
The problem is with geometries whose second
coordinate (horizontal offset) is less than 67.
The other coordinates do not have a minimum.
This is supposed to be a (nice?) feature. The window geometry is adjusted to the screen dimensions and takes the dock dimensions into account. This is implemented in the method -[adjustRectToScreen:] defined in AlphaAppController.m.
So the second coordinate (which is the y-coordinate) is adjusted if the window is going to be overlapped by the dock. Probably your dock is currently 66 pixels high.
The same kind of adjustment occurs when you try to move a document window out of the visible frame. This is done via the method [constrainFrameRect:toScreen:] which is automatically invoked by Cocoa when necessary and which is implemented (subclassed) by Alpha in the file AlphaWin.m.
Of course we are free to return anything we want from [constrainFrameRect:toScreen:] but circumventing the current mechanism might be challenging.
Hi, thanks for the explanations.
My dock is always hidden, so it should not be allowed to interfere with Alpha windows. (It does not have this effect in AlphaX.)
Second, I could understand if the second coordinate were then moved up on the screen to 67, and then the last coordinate could be truncated if necessary, but what actually happens is that the whole window then snaps back to default geometry.
In fact, this default geometry is lower on the screen than 67, actually at 4. So it seems strange to impose rules on margins if the default does not itself respect them.
Finally, if I put the dock on the left of the screen, nothing changes what the win geometry is concerned: a first coordinate (hoffset) of 0 is still accepted, whereas a second coodinate less than 67 'chokes' as described.
I should add that Bug #80 is a consequence of this bug.
(There seems to be no bug dependency facility on this bug tracker, like we had in the old Bugzilla.)
I'm puzzled. I just checked again: with my dock along the left edge, I tried to create a new window with x-coord equal to 0 and it was automatically moved to the right. I then tried manually to move this window under the dock and this was rejected (the window was bounced back to the right).
I don't understand why you have a different behavior there. Weird. Is there a stale preference in one of the prefs files? Or are you working on a secondary screen (all Alpha's calculations are made using the main screen)? Or did you set the global preference windowGeometry to something and the proc win::SetProportions might be interfering (try typing
set windowGeometryin the Tcl shell) ?Hi, both 10.10.1 and in 10.11.5: when hiding is turned ON, all applications freely use the space that the dock sometimes occupies. There are no constraints -- and clearly that is the whole idea of dock hiding.
I have no secondary screen, and pristine AlphaCocoa prefs.
Independently of whether the dock is on the left or the bottom, it is the y-offset that is not treated correctly. It should allow values all the way down to 0.0 just like the x-offset does. (And even if it had to respect a dock which is not there, the correct way would be to adjust or move, not just to jump back to Alpha's default geometry.
To see if we can get a specific set of test conditions: with dock hiding turned ON, and with a completely fresh AlphaCocoa, try to open the Tcl Shell as the first action ever, and issue the commands
<> getGeometry
4.0 0.0 570.0 729.0
<> openWindow -n OK -g {0 35 400 400}
OK
<> getGeometry -w OK
4.0 0.0 570.0 729.0
I see the following: although the shell window is clearly (and correctly) allowed to occupy dock potential territory, the new OK window, specified to occupy less dock territory, actually ends up with eactly the same geometry as the shell, simply because the y-offset is specified less than 67.
At last I found the culprit! The unwanted resizing takes place in AlphaTcl in the proc alpha::openHook (in alphaHooks.tcl). It depends on the global preference called Force Main Screen. If this preference is on, then it calls the proc defaultSize which indeed resets the geometry to the default values (defOrigX, defOrigY, defWidth, defHeight).
Now before I start fixing this, I'd like to open a discussion about what is expected from the core (and/or from AlphaTcl) regarding adjustments to screen dimensions. May be we should make the distinction between what is set programmatically and what results from user actions (moving a window with the mouse). What about the status bar ? What about the dock ?
A common situation where adjustments from the core can be useful happens when you record some window geometry after working on a large screen then reopen the file on another computer with a small screen, so the recorded values do not fit in the smaller screen.
Suggestions welcomed...
Great -- I see that it is just because the Tcl code thinks the vertical
dimension is still counted from top to bottom like in AlphaX, not from
bottom to top like in AlphaCocoa. I have just experimented with a
minimal fix, and indeed it solves the problem.
Now I discover something better: it seems that OSX takes care of
all this automatically, independently of the forceMainScreen flag, and
this includes giving space to the status bar and any non-hiding dock!
All the desired behaviour is obtained just by removing the
whole if {$forceMainScreen} clause in alpha::openHook
and let OSX take care of the whole thing. (And remove the prefs
flag from Alpha.)
(To be precise: I think the good behaviour should be (and now is):
if a window has some part outside the main screen or under the
dock or under the statusbar, first try to move it without resizing,
and if that is not enough, resize it. (Note that the second condition
occurs only if the size is too big; in this case it is resized as little
as possible, which means that it will have maximal size in the
dimension in question, and therefore it is unambiguous how to resize it).
Concerning the difference between setting the geometry programmatically and by user dragging, this difference already exists, and makes good sense: it is not possible to set an off-screen geometry programmatically, but the user has the right to drag the window partly off screen. If the window is closed with window state remembered, then next time it is opened, it is
moved on-screen. I think it all makes sense as taken care of by the system.
Is it a good thing at all to have this preference forceMainScreen ? Or is it just Yet Another Useless Global Setting ? I did not know about its existence until yesterday... OTOH I see also that the WWW menu (in proc WWW::createNewWindow) goes to the trouble of temporarily setting it to 1 in order to force the window.
Another questionable point is the fact that, if the pref is set to 1, the code just invokes defaultSize: it could be more clever and, as you say, first try to move without resizing and then resize if necessary.
A solution might be to introduce an -adjust (0|1) option in the core commands openWindow and openFile. By default it would be 1, but if the programmer really wanted to create an offscreen window, he would set this option to 0.
Note that the current behaviour - taking care of the status bar and the dock - is not provided by OSX but by the core (see the method [adjustRectToScreen] in class AlphaAppController) so we have complete control on this.
I think this is fixed now. Here is what I did:
Changes committed to the repository (rev. 1231). The core must be rebuilt and AlphaTcl must be updated.
Good work by the core, then!
The window geometry now behaves well.
I would still propose to improve the handling of unfitting windows by moving them rather than resizing them, as far as possible. The reason being that most often a window has a size depending on its contents, whereas the position could originate in a bigger screen on another computer, and things like that. Here is an algorithm that does that:
set xoffset [expr{max($xoffset,0)}]
set width [expr{min($width,$screenWidth)}]
set xoffset [expr{min($xoffset,$screenWidth-$width)}]
set yoffset [expr{max($yoffset,0)}]
set height [expr{min($height,$screenHeight)}]
set yoffset [expr{min($yoffset,$screenHeight-$height)}]
Done.
Changes committed to the repository (rev. 1241). The core must be rebuilt.