[comp.windows.news] Canvases in negative space

andy@ecrcvax.UUCP (Andrew Dwelly) (10/19/88)

Oh dear, oh dear, oh dear.......

Suppose I wanted to draw a picture, where some of the elements are selectable
by the user (e.g. they have canvases over them, or are drawn on canvases).
Because this is a fairly big picture I want the user to scroll around it.

The manual is a little obscure about movecanvas (NeWS 1.1 by the way) but
it had always seemed to work in the past. Well opening, locating and moving
canvases around parents with transfomed spaces is so odd, that I can't believe
that no one has ever run into it before.

It is all somehow connected to the fact that if the parent has 0,0 in the
bottom left hand corner, any children can not be moved or opened in negative
space - try moving a window off the frame buffer left and up, as opposed
to right and down. This applies to abitary windows, not just the framebuffer. 
This may be a design 'feature', but it makes it difficult to
write a window manager, where the framebuffer represents only a small amount
of window space that the user can scroll around.

A collegue of mine spent an unhappy weekend creating a family of oddly behaving
programs showing this sort of thing (thanks johng), I've simplified one,
removed the four letter words :-) and posted it at the end of this message.
It opens a canvas with 0,0 in the middle, and trys to open a child in the
lower left hand corner, that is, entirely in negative space. 

Now then :-
Given that johng and I aren't misunderstanding something, in which case could
someone show us (well me anyway) the error of our ways.

1) Is there any way to fudge this ? writing programs that allow scrolling
   behavior is quite difficult at the moment.

2) Is there any way of getting Sun's attention so that it might be fixed
   at some point in the future, we haven't had much luck in the past with
   this sort of thing (rotated fonts for example). I realize that it's
   traditional to flame Sun at this point, but for all the good it's done
   you may as well be flaming a lump of granite. A pity as well, as they
   should be feeling the hot breath of display postscript on their necks
   after the NeXT roll out.

Andrew Dwelly                 
E.C.R.C.                                       UUCP: mcvax!unido!ecrcvax!andy
ArabellaStrasse 17 			       or    pyramid!ecrcvax!andy
D-8000 Muenchen 81, West Germany 	       UUCP Domain:  andy@ecrcvax.UUCP

[Bump, Crash ......
 Listen; who swears ?
 Christopher Robin has fallen down stairs.]

-------------------------------------------------------------------------------
#! /usr/NeWS/bin/psh
% Make a canvas

/can framebuffer newcanvas def

% Make path with 0,0 at the centre

150 150 translate

newpath
-100 -100 moveto
200 200 rect
can reshapecanvas

% express an interest for the canvas

createevent dup begin
	/Name /RightMouseButton def
	/Action /DownTransition def
	/Canvas can def
end expressinterest

can /Transparent false put
can /Retained true put
can /Mapped true put

% Draw cross hairs through 0,0

can setcanvas
1 setlinequality
1.0 fillcanvas
0 setgray
newpath
0 -100 moveto
0 200 rlineto
stroke
-100 0 moveto
200 0 rlineto
stroke

% Open child in lower left hand corner

/child can newcanvas def
child setcanvas

newpath
-100 -100 moveto  % <--- This is the lower left hand corner, right ?
50 50 rect
child reshapecanvas
child setcanvas

% express an interest for the canvas

createevent dup begin
	/Name /RightMouseButton def
	/Action /DownTransition def
	/Canvas child def
end expressinterest

child /Transparent false put
child /Retained true put
child /Mapped true put

% Then what the #$@!!! is it doing here

0.5 fillcanvas

can setcanvas
(\nThis is where the child thinks it is now: % % \n) [child getcanvaslocation] printf

% ArGH!!!!!!, getcanvas location manages to be wrong in both child and parent
% coordinate spaces, how do they do it....

(\nJust to prove that the parent is correct, let's draw two more crosshairs.\n) print

(\nClick Right button.\n) print
{awaitevent exit} loop

0 setgray
-100 -100 moveto
200 200 rlineto
100 -100 moveto
-200 200 rlineto
stroke

(\nClick to quit.\n) print

{awaitevent exit} loop

% And this is just with translation. You won't believe what rotating does
% to the situation.

msc@canth.SGI.COM (Mark Callow) (10/26/88)

There are two problems here:

1.	movecanvas moves the current canvas to x y relative to its parent.
	The problem is that x & y are in the coordinate system of the
	canvas being moved but are relative to the parents origin.  This
	is very tricky.
	
	This is fixed in xnews.  A new movecanvas operator takes an
	extra argument, the canvas, and moves it to an absolute x, y
	in the canvases own coordinate system.

2.	The second problem is that the underlying pixrect code does
	not understand how to make region pixrects that are to top
	or left of the primary pixrect.  The underlying code called
	by movecanvas as tests to prevent -ve x or y values.  It
	sets them to zero.

	I don't know if this is fixed in xnews.  We fixed it in our
	NeWS server.

--
From the TARDIS of Mark Callow
msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc
"There is much virtue in a window.  It is to a human being as a frame is to
a painting, as a proscenium to a play.  It strongly defines its content."

sjs@jcricket.ctt.bellcore.com (Stan Switzer) (10/26/88)

In article <21066@sgi.SGI.COM> msc@canth.SGI.COM (Mark Callow) writes:
> 2.	The second problem is that the underlying pixrect code does
> 	not understand how to make region pixrects that are to top
> 	or left of the primary pixrect.  The underlying code called
> 	by movecanvas as tests to prevent -ve x or y values.  It
> 	sets them to zero.

I'm glad you guys fixed this problem, and I hope Sun does the same.
Some things would be quite a bit simpler without this restriction.

But ...

As with any other "feature," nice or not, changing its behavior will
lead to some interesting effects.  An funny one comes to mind:

Closing a window for the first time places the icon at the upper left
corner of the window.  If the window were placed such that the upper
left corner were off-screen (currently an impossibility) then the icon
would materialize off-screen and there would be no way to open the
window again!

Myself, I have already hacked a window subclass (based on Don Hopkins
neatwin.ps) that initially places the window at the mouse cursor.  In
addition, pushing the "close button" with "Middle" causes an "iconize
and slide icon" behavior.

Stan Switzer  sjs@ctt.bellcore.com