Glulx graphics window do not accept "mouse" input

[GoogleCodeExporter]

Glulx graphics windows are capable of receiving single mouse clicks. However, 
clicking anywhere on the screen in Frotz, including on a Glulx graphics window, 
only brings up the keyboard for text entry. (When it does so, the cursor can 
also be placed inappropriately.)

The demo linked in Issue 131 contains hotspots in the graphics window that 
could be used for initial testing, including each of the rooms drawn in the 
map, and the +, -, and ? buttons at the bottom of the window.

Original issue reported on code.google.com by Ek.Temple@gmail.com on 30 Apr 2011 at 12:05

[GoogleCodeExporter]

Actually, it appears the demo linked to issue 131 uses glk hyperlinks, not 
mouse input, to do its thing.
(I implemented mouse input and this demo did not start working, so I 
disassembled the file to check.)
I'll be implementing hyperlinks as well, though, so no worries.

If you do know of another game file which definitely uses mouse input, I would 
like to find test cases for the support I'm working on.

Original comment by spath...@gmail.com on 13 May 2011 at 5:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

No, that demo file definitely does use mouse input (I wrote the extension that 
provides the automap and the response to mouse input). Glk hyperlinks act only 
on text and are not legal in graphics windows.

Original comment by Ek.Temple@gmail.com on 13 May 2011 at 12:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Oops.  You're right, of course.  Turns out I fooled myself into thinking it 
wasn't using mouse input because it never did a request for mouse input while I 
was debugging it, but the reason it never did is was because I was using an 
autosaved game and the byte that marked a window as having had a mouse event 
request was not being saved, and it doesn't request again until it successfully 
gets an event.

But by the way, Glk hyerlinks DO work on images and in graphics windows, 
according to the Glk spec, which is why I jumped to the wrong conclusion that 
this is what was going on.

      [Section 9.1]  "If the library supports images, they take on the current link value as they are output, just as text does. The player can select an image in a link just as he does text. (This includes margin-aligned images, which can lead to some peculiar situations, since a right-margin image may not appear directly adjacent to the text it was output with.)"

Original comment by spath...@gmail.com on 13 May 2011 at 6:33

[GoogleCodeExporter]

Cool, glad that there was a clear reason why mouse input seemed not to be 
working.

The text you quoted refers only to text buffer windows, not to graphics 
windows: Glk does allow for images to be "printed" to text windows, and it's 
these images that can be hyperlinked--because they are part of the linear 
stream of data in the window, it makes sense to bracket them with hyperlink 
"tags". Mouse input, on the other hand, is grid-based, with rectangular shapes 
defined using x-y coordinates, and only makes sense in gridded windows (i.e., 
graphics and text-grid windows).

Original comment by Ek.Temple@gmail.com on 13 May 2011 at 7:34

[GoogleCodeExporter]

Gargoyle interpreted the text the same way I did and implemented hyperlinks for 
clicks on images in graphics windows, so I assumed that was correct.  Unlike 
grid windows which lookup based on x,y coords, it just remembers the hyperlink 
number attribute with the image when it is displayed, and a click anywhere on 
the image triggers a hyperlink event.

But it certainly seems ambiguous whether this was intended, so I won't bother 
to implement it.

Original comment by spath...@gmail.com on 13 May 2011 at 7:56

[GoogleCodeExporter]

Wild. I suppose that that is the most expansive way to interpret the spec, but 
it still confuses me, since hyperlinks are written to a stream (usually 
referred to in the spec as holding text) whereas images are drawn to a window. 
But I guess graphics windows have streams too (the spec says "every window has 
a stream"), though on the other hand there doesn't seem to be much to do with 
data from graphics window streams. Confusing.

I may be unduly influenced by the chart on this page:

http://www.iffydoemain.org/glkdunces/glkdunces3.htm

Whatever Zarf actually intended, thanks for the info about Gargoyle's treatment 
of hyperlinked images in graphics windows.

Original comment by Ek.Temple@gmail.com on 13 May 2011 at 9:38

[GoogleCodeExporter]

Mouse inputs (taps) is now supported in 1.5.3.
I decided to not implement hyperlink images.

Original comment by spath...@gmail.com on 9 Jun 2011 at 11:44

• Changed state: Fixed