I see two different "locale" issues here. There's cocurrent (which is independent of the browser window you are interacting with), and there's the locale being used to handle http requests from javascript (which is determined by the url - jijx urls will be handled by the jijx locale). I guess I am not sure which of the two concepts you are reasoning about.
Beyond that, you'd have to walk me through setting up a working example (or as close to working as you can get) along with a description of what you want different (both in terms of user experience and J queries) for me to sort out how to get your queries working. That said, maybe I can also offer you some advice on how to get it working on your own? I'd try installing Charles (http://www.charlesproxy.com/) and use that to study how the http requests to jhs (and your tgsj), and their responses. Once you see how those work maybe you'll find it easier to reason about what it is you want to be doing. This stuff isn't really all that hard, once you understand it, but you sort of have to see something similar in action before you can get anywhere. Thanks, -- Raul On Mon, Mar 17, 2014 at 7:05 PM, Brian Schott <[email protected]>wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
