Raul, Thank you for your thoughtful response, as always.
Let's start with (1). I am pretty sure I do want to change the locale in jijx, unless there is a better way. At least changing the locale there has been my current practice: cocurrent'tgsj'. The reason I have needed to do that is that there are some commands that control things like whether their pen is up or down, that do not involve movements or turns; and there can be new j parts of speech the user could write which combine the turtle moves/turns, Such user actions do not result in a J verb named paint being executed, but only the paint verb contains the jhrajax command. You see, some of the user inputs could be multiple lines, like an explicit definition, so I thought providing the 3-frame browser page would work satisfactorily. Now back to (0), if I could and knew how to save the last state of each turtle move/turn in the browser or in javascript, then I think this problem would disappear and some efficiency might be gained. No, maybe another easier idea would be to produce the path information and the turtle states in J also for an arrow key (in addition to for a turtle move/turn). That should be something I can figure out how to do and although it would add some processing time, it should work. That was easy <grin>. Well that does not completely deal with (0) because the arrow key still interferes with the text field entry, But, I think your idea of using onfocus() to turn off the arrow keys and require a distinct action by the user to reinstate the arrow key function might work fine. And although that last idea works counter to the "efficiency" of (3), unless I notice really bad performance results, it is worth a try. So, thanks, again. You are not known for giving less than "enough". I may have to get back with you and the list on this, but I think I have a direction to start working. The lighting question in (2) is not a deal breaker, and I'll keep thinking about possible fixes. On Mon, Mar 17, 2014 at 2:11 PM, Raul Miller <[email protected]> wrote: > I would not worry about efficiency, preserveDrawingBuffer has warnings on > it - that it is notoriously inefficient. (It's just an easy way of copying > content forward from previous renders.) > > And I suspect that your vanishing turtles problem is also a result of > misplaced concerns about efficiency. > > Mind you, efficiency can and will be important, but it needs to take back > seat to correctness. > > And, when using webgl, you need to somehow do a complete render of the > entire webgl scene every time you draw something. But without looking at > your code I cannot be more specific. > > (0) The arrows get a bit involved because of browser compatibility issues. > But basically you'll probably define a window variable that says whether > arrow keys are on or off, and have your arrow key handler do nothing if > they are off. Next, you need to define (a) the mechanism for turning it on > and turning it off, and (b) the visual feedback for the user. For example, > you might turn off arrows with the onfocus event for your input box or text > area. But how to turn them back on? You'll want to turn them back on when > the user hits enter, but you'll also want to define a "cancel" mechanism > (maybe just a button on screen, maybe the ESC key, perhaps both) so the > user does not have to execute a turtle command to have the arrow keys work > for opengl. > > It's tempting to think about using focus or mouseover to have arrow keys > work again, and that introduces other problems (like what if the user moves > their mouse habitually before typing - it's a visual obstacle... and also, > the focus and blur events probably aren't quite what you want.) > > (1) You probably do not really want to change the locale of jijx. Instead, > you probably want to emit html along the lines of: <a href="/tgsj" > target="_tgsj">turtle graphics</a> > > (2) I do not have enough information to reason about this issue. I need > more detail. > > (3) turtle graphics paths? You might use html5 local storage. This has some > limitations (browser support, and of course some students might use > multiple browsers or different machines - lots of potential issues there, > trading security and usability along with ease of access and time to build, > and at some point you have to tell them to just deal with whatever you've > choosen). Another approach stores them on the server - J can write them to > disk if you want them to survive server restarts (but this requires some > sort of naming mechanism and if you're doing this for students that might > introduce other issues). Another approach involves copy and paste (student > can store wherever). Another approach involves generating bookmarkable > urls. > > If you are generating urls, they might be javascript: urls (a function call > with arguments, perhaps), or data: urls or urls into jhs (which pass query > string parameters, maybe). It's probably worth a few moments thinking about > the failure modes of each and deciding what you are comfortable working > with. (A javascript url has to assume you are in the right context, while a > reference to jhs will to some degree force the right context but still > requires the server is running). > > I hope this is enough. > > Thanks, > > -- (B=) ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
