Code
I have uploaded a dummy program that resembles the format we would like the screen hot spots to be saved.
Code
Summary:
Discuss code that has been implemented.
We feel that these methods will be what we need…..
SJMSU methods, parameters, and return values
April 1, 2009
constructor(String filename) filename identifies a screen-sized image and
the corresponding hotspot definition for that image
string get_next_screen(x_coordinate, y_coordinate)
return filename that the (x,y) coordinate is associated with. If no
filename is associated with the (x,y) coordinate, null is returned.
string get_image()
return filename of the current image displayed on the screen
int get_delay()
return delay length (seconds) that the current screen should be displayed
before display of a user prompt to either retain the screen or return to
the splash screen (used to continue reading a text-intensive screen image).
-1 means that no timeout will be implemented for this screen
This concept assumes a set of splash screens in a cycle with known, hardcoded
names, that lead to user-controlled screens which do NOT have known hardcoded
names (the names of those screens are provided by the interface from the splash
screens and other user-controlled screens). That is, some filenames are known
and some are not.
Looks like both groups were talking about this interface at about the same time. This post is a little late to the wiki (beginning of a new quarter is always hectic to say the least). Here is the interface that we came up with. Comparing the two, the methods look fairly similar.
/*
*intfproto1 has three methods accessible from the front end:
*String executeEvent(String s, MouseEvent e): Given a String filename and a MouseEvent object, execute the assigned trigger and return the resulting String filename (next image).
*
*List<HotSpot> getKnownHotSpots(String s): Give a String filename, provide a list of the registered HotSpot objects.
*
*List<String> getScreens(): Returns all registered image filenames.
*/
public interface intfproto1{
String executeEvent(String s, MouseEvent e);
List<HotSpot> getKnownHotSpots(String s);
List<String> getScreens();
}
Text file is made up with hotspots associated with that screen that follow this:
(int x, int y, int width, int height, screenName)
- x : Left-most x-coordinate of the HotSpot
- y : Upper-most y-coordinate of the HotSpot
where (x,y) is the ordered pair for the upper-left corner of the HotSpot.
- width & height : define the resulting rectangle when combined with x and y
- screenName : is the name of the screen to go to when that hotspot is pressed
I uploaded an example text file that has the format we're working with, as Josh mentioned. While it is only a sample, I believe it has all the parts that are needed to get the main points across. File is located under "files" on main page, Example-Configuration-file.txt I believe. It is conceivable that the file extension will change, but that should not be a big deal. Hope this helps.
Alright guys, looks like we've come up with a pretty good definition to work from. Here's the details:
The interface is going to be centered around "TouchMap" objects. These objects have as their interface:
/*
- Returns the TouchMap object that will need to be processed next, responding to a MouseEvent triggered by the display.
*/
TouchMap executedEvent(MouseEvent me);
/*
- Returns the necessary filename for the .jpg (image file) to be displayed.
*/
String getImage();
/*
- Returns the associated timeout delay for the current TouchMap object.
*/
int getDelay();
The display component will be responsible for obtaining the first desired config file to be displayed and creating a new TouchMap object with the following constructor:
TouchMap(String cfgFile); //cfgFile will need to be the full path of the file to be opened.
Subsequent TouchMap objects will be created in the background using the "executedEvent" method provided through the TouchMap interface.
Even though the display will not need to parse through the config file, it may be beneficial to see the overall structure of it. I have replaced the initial "Example-Config-File.txt" with the newest version to include all the details specified in this post.
With this, SJMSU should be able to proceed with the display component.
Seems like there is one thing missing from the interface that might be useful. Thought I'd throw out the suggestion and see what everybody thinks:
/*
- Called to initiate a timeout, if applicable, on the current TouchMap object. Returns the next TouchMap object to be processed.
*/
public TouchMap triggerTimeout();
Seems like this may be useful with "int getDelay()"
Just to make sure we're all on the same page: the origin of the TouchMap coordinate system will be upper-left corner, right?
I'm thinking back to this 1999 news item: "NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency's team used the metric system for a key spacecraft operation…"
Be prepared to make TouchMap compatible with Java 1.4, in case that's the version that SJ-MSU installs on the DC machines. The only problem I see is the List<String> and ArrayList<String>. Parameterized types were not introduced until 1.5 (5.0). Basically, just remove the <String>, and be prepared to typecast the return value of any "get()" calls — I only saw one. Should only take a couple minutes.
Does anyone know the native resolution of the touch screens? They're LCDs and therefore very resolution-sensitive. If you don't know, I have two of them in my office you can experiment with. The touch map JPG images should have same dimensions as the screen to completely fill it without distortion and for optimum viewing quality.
SJMSU is planning on presenting the app to some people from the Discovery Center next Wednesday afternoon. Just took a look at the GUI stuff that SJOC posted earlier this week, and it looks great!… We were just wondering if you guys had any type of users manual that we could present to the Discovery Center during our presentation next week? I think it'd be good if we could show them how to use the whole thing when we present it. I guess just let us know, so we can learn how to use the admin tool before then.
- Brandon
There seems to be an error in the file TouchMap.java. The hotspot recognition does not seem to work correctly in circumstances. We believe it is a logical error on lines 88 and 90. We replaced the two if statements with the following code:
if(corner_x <= clicked_x && (corner_x + width) >= clicked_x && corner_y <= clicked_y && (corner_y + length) >= clicked_y)
this seems to fix the problem.
Also the resolution of the touch screen is 1024X768.
/forum/t-143320/code#post-
