Enhance GeoGebra slates

[Alex-Jordan]

Read the relevant sample article subsection, both source and HTML output for an explanation of what this does.

I am thinking of interactive[platform="geogebra"]/slate[surface="geogebra"] as the thing for drawing something yourself, including appending more onto an existing material, .ggb, or base64.

Therefore I am thinking of interactive[geogebra] (with no slate) as what to use when you are just loading a pre-existing applet and you won't modify it. Right now it only supports material ID, but it could support .ggb or base64 too. If this first commit is good, I could extend this PR to also do that.

[Alex-Jordan]

A quick story. I'm eager to get a "model" section up for the second edition of ORCCA. I'd like it to include a GeoGebra. Not wanting to wait for this slate enhancement, I went on to the GGB Course Materials site and tried to build an applet there using the GUI. If you want to do anything even mildly complicated with text (combining LaTeX and dynamic variables) it is a huge PITA. In part because MathQuill (or something similar) constantly wants to "fix" what you type in. And then after a long time figuring out how to control it and getting my applet built, the GUI lost all my work.

I know I could open GGB desktop and build there with less chance of losing my work. But having a sequence of API commands in plain text will feel more secure.

[rbeezer]

OK, finally, a chunk of time to review. Looks good. Notes, etc.

• Typos: alrady, viwing, stray quote mark at end of Rosoff path.
• It appears that no GGB API call has HTML as an argument. So let's provisionally try placing as content of a slate, as you have done. Defer decisions.
• Figure 14.21 has scrollbars. I saw the 98% scale device. This is a problem all over, and I thought I once understood it, maybe a stray newline in HTML, introduced by xsltproc. Anyway, a more general solution would be greatly appreciated!
• This work is all independent of the iframe discussion, no? That still needs to be settled. If you want to remove the copy of the app loaded on the page, that can be included with this. N, not N+1.
• I don't like the conditioning on the length of the source. I'd prefer a variety of attributes, such as the following. We can make them exclusive/disjoint in the schema.
  • material
  • geogebra; deprecate, but keep its current meaning active
  • source; pointer to a *.ggb file
  • ggb64; or similar name, maybe base64
• Tevian Dray app moving to 15.1 and maybe some clean-up there?
• The full base64 string in source as an attribute is ugly. Just like the long URL query strings for CalcPlot3D. At a minimum, discourage? Is there an alternative? Not critical, just suboptimal to my eye.

Thanks for doing this, the ability to adjust is great, especially since we need to fit in a width most applet-authors don't think about.

I have not checked LaTeX, it should be OK, but you'll need to make new snapshots. A force-push is fine, I've not made any changes.

Rob

[Alex-Jordan]

I have a suspicion about the width and scroll bars. The javascript inserts many things, including a div that looks like this: <div class="GeoGebraFrame jsloaded applet-focused" style="width: 448px; height: 598px; border-width: 1px; border-style: solid;">

The outer iframe is 450px wide, because PTX told it to be that wide. To make that 1px border, this div is set to be only 448px wide. I wonder if this is somehow at fault. That's just a guess.

* This work is all independent of the iframe discussion, no?  That still needs to be settled.  If you want to remove the copy of the app loaded on the page, that can be included with this.  N, not N+1.

Yes, this is independent. In the case of GGB, I believe it is common to have multiple applets on a page, and when I get to it I will read about how that is managed. I think that it's clean with no opportunity for unintentional variable contamination. There's a unique id for each div containing the applet, and the variables are all local, used to build stuff that then gets inserted into the designated div by id. So I'm optimistic that with GGB, we will be free from that reason for iframes.

I want to do the GGB calculator in the right panel too. That will need the page's GGB deployment, but things will get complicated if the page also has applets if we want to engineer only loading once. I think I will leave the "1" (from N+1) where it is for now until I work on that calculator.

I'll return to this PR soon-ish. But local issues at work are piling up.

[Alex-Jordan]

Hmm. Say you have a ggbBase64 string you found on the internet somewhere. You can paste it into a base64 decoder, like this one. And then this one conveniently lets you download the result as a file. You can change the extension to .ggb.

Seems to work just fine. I was able to do this with the base64 string I had for Dave's file, and then load the resulting .ggb file in desktop GeoGebra.

So I'm guessing we document this pathway (in case someone has their hands on a base64 string) and then there is no need for @base64. Just store the .ggb file. With straight API commands in source, you can see them, edit them sensibly. But not so with a base64 string. So I can't see a need to support this. Does that sound good?

[Alex-Jordan]

What are your thoughts on defaults for the app parameters? For example, enabling zoom. And 100 other things. We could just go with whatever GGB's defaults are. And if you want to override them, you have to provide the corresponding API commands for that.

One counter argument is that I feel some of GGB's defaults are not good, and I can see myself toggling them every time I use this. So I could set what are (imho) more sensible defaults for PTX users.

Another thing to understand is that not all of the app parameters seem to have corresponding API commands. Like, there is the app parameter showZoomButtons which defaults to false. So no + and - buttons, even if you have enabled zoom using the mouse wheel. But there is no API command like, say, I'd imagine it to be applet.showZoomButtons(true). So this is one (of only a few) app parameters where our choice will stick. Unless we also give PTX authors separate control over those too.

[Alex-Jordan]

Made some changes. Rebased. Force pushed. Ready for another review, including last two comments here in the PR thread. Not ready for merge, at least until the rest is green lighted and then I'll make the screen shots.

Oh, and for a slate-free GGB interactive, I think let's leave it at only able to handle material id~s. As opposed to supporting .ggb files. Because of the simple embedding the materials site uses, and (I think) more clean licensing. If someone wants to use their .ggb file, it has to be via the app anyway, not the materials site. So they could just use a slate.

[rbeezer]

Base 64:

• Definitely document the route to a *.ggb file
• Easy enough to keep support for base64, but discourage use? One advantage is for a small project (single worksheet, one day's worth of lecture notes) the file can be self-contained, and no extra steps. I just find it ugly, not technically inferior. Big serious project, make and use *.ggb, small one-off project, base64 could be desirable.

[rbeezer]

App options:

• Choose values that make for a good out-of-the-box experience for a new author. Use "imho" carefully. Zero-configuration needed then at first in PTX.
• Document a few API calls as examples (for "obvious" first choices to change.). Cite API reference, so don't be comprehensive.
• Easier to add options than take them away. Be conservative and see what people ask for.

[Alex-Jordan]

Ready for another look.

It seems to me that the unwanted scroll bars are a byproduct of using iframes. If you visit the non-iframe page for each one, where the applet is directly inserted, you don't have scroll bars. So if there is the possibility of not using iframes for geogebra, I think we can not care about the scroll bars right now.

Build the HTML. Read the sample article and see what you think. Examine the code in mathbook-html.

Static images need building, but it looks like things are set up so that you would first upload the iframe-free files to the pretext site, then have mbx script make the images? I could hack around that, but I thought not to bother. Unless you think I should.

[rbeezer]

Looking good. Comments in no particular order, maybe easier first.

• Typo: opeing
• Please put @xml:id on new interactive and new slate (Jack Green's and "from scratch"). It'll be easier to see which files go where, and manufactured JS vars will be less cryptic.
• 4-way choose on attribute
  • please put each <xsl: onto its own line, I've been trying to eradicate how I used to do this
  • for deprecation maybe put double quotes around literal element names, might need "
  • for deprecation, make clear material is an attribute. Try to make deprecation message as clear and helpful as possible
• This will need snapshots for the LaTeX side. Find the docinfo/html/baseurl element, change it to a site you control, upload, build images, then change the baseurl back.
• Deprecating @source on interactive? In favor of @source on a slate? Do I have that right? If so, we need to warn authors. This is not in the schema yet, but the routines in -common are the best place to locate and manage these messages.
• Important question: does applet need to be hard-coded? If we free these from iframes this is exactly the sort of thing which I think can cause problems. And we might even want to have two slates in one interactive and they "talk" to each other (there is a demo like this at the GGB site). If I have a slate with xml:id="cycloid" can we use cycloid_applet or similar instead? We'll need to alert authors to the "internal-id-no-dash" template which converts dashes to two underscores (or think of some other device for dealing with dashes in JS identifiers).

When you are done, it'd be nice to have a code commit and a sample article commit. I can do it if you don't want to, but it is a fiddle for me to keep your name on them (but not impossible).

[Alex-Jordan]

Deprecating `@source` on `interactive`?

I don't think so, but does something suggest that? Going back to my "tablet" of slates analogy, I think that there can be times when the tablet has @source that is the puppet master over multiple slates. It's all a bit abstract to me without more examples.

Important question: does applet need to be hard-coded? If we free these from iframes this is exactly the sort of thing which I think can cause problems.

I don't think that is quite right, but you do make me realize where that is a real issue. "applet" is the proverbial "x" in defining f(x). It's a dummy variable in the definition of the function onLoad. But that (onLoad) is the thing whose name really should be unique. Instead of var onLoad, it should be var internal-id-onLoad or something like that.

"applet" could be something else, but I don't think it is a problem to reuse the same string. And it will agree with lots of documented GGB examples.

I'm a bit under the weather. If I can't sleep tonight (after sleeping all day) I may do revisions tonight.

[rbeezer]

So maybe I did not understand:

Oh, and for a slate-free GGB interactive, I think let's leave it at only able to handle material id~s. As opposed to supporting .ggb files.

Suggesting applet for every such situation will become part of an author's source, so I want to be convinced we won't have to backpedal on that. And for other slate the @xml:id is used as the id of a div, or similar. So suggesting authors always use applet will be exceptional. If that is used in GGB documentation is not a selling point with me - examples are not built with the idea that there might be several on a page. Right now, an iframe will protect one from interfereing with another. But I understand some people want to get rid of them. ;-)

I'm a bit under the weather. If I can't sleep tonight (after sleeping all day) I may do revisions tonight.

Sleep all day, code all night.

[Alex-Jordan]

So maybe I did not understand:

Oh, and for a slate-free GGB interactive, I think let's leave it at only able to handle material id~s. As opposed to supporting .ggb files.

Current status: an interactive with no slate could have a geogebra attribute, which we are deprecating in favor of attribute material. An interactive with no slate has no way to deal with a .gbb file.

At one point I proposed that we could let an interactive with no slate handle a .gbb file. I know how to do that now. But my comment above is saying never mind, it's not worth it. If author wants a .gbb file, use a slate.

So I don't think we are deprecating anything right now (except the name geogebra to material).

Now for an interactive with multiple geogebra slates, I suspect that source will make sense in some situations, where the source could be some javascript that is allowing the multiple slates to interact. Or maybe we will realize that is unnecessary and all such javascript can live inside the slates' sources. Unclear yet.

---

I'm not sure if I made the point well about "applet". Imagine two geogebras on a page, no iframes. One may be responsible for this being in the HTML:

var onLoad(applet) {
   applet.command;
   ...
}

and the other is responsible for:

var onLoad(applet) {
   applet.differentCommand;
   ...
}

It is a problem that "onLoad" is used twice. We can change things so that we get

var onLoad_cycloid(applet) {
   applet.command;
   ...
}

and the other is responsible for:

var onLoad_spiral(applet) {
   applet.differentCommand;
   ...
}

and things will be OK. The author is only providing the internal guts of what the onLoad function does.

var onLoad_spiral(applet) {   // XSLT template makes this
   applet.differentCommand;   // author makes this
   ...                        // author makes this
}                             // XSLT template makes this

This function is passed as one of the applet's parameters. The function will be applied to that applet itself, which I guess is some complicated javascript data type, not some generic "applet".

This approach is different from say the jsxgraph examples of source, which are self-contained chunks of javascript (although not self-constrained, as you are aware). We could make the geogebra have to be similar self-contained javascript if that is better. It would mean the author is writing a lot of stuff that this PR currently just templates for them. What I mostly do not like about that is the steep learning curve it takes to understand the GeoGebra embedding javascript. If the author only supplies API commands, especially if they only need applet.evalCommand(), it is pretty easy for anyone to build things this way having only familiarity with the desktop GeoGebra.

[Alex-Jordan]

David's comments in an email about the GGB calculator have me wondering about the event that injects the applet. A window.onload event does it. If we stop using iframes (later, after this PR is settled) then we should not use separate window.onload for each GGB (or other interactive). I believe the last one would overwrite earlier ones. We will want a single window.onload that injects all such things all at once. So, a template that is run at a higher level of the page construction.

[rbeezer]

Thanks for the long careful reply. Very helpful on both accounts.

I had not chased through to the conclusion that applet was isolated within a var. So it seems safe to always use applet or we could choose to act like the @xml:id should be used as the identifier, as in other cases. This is source/author level, so we want to get it right now. The other pieces are hidden from the author (good!, keep it that way), so we have latitude to change that if necessary without any deprecations.

[Alex-Jordan]

I force pushed some things. Still no static images. I might as well wait until everything else is squared away, in case some detail changes that changes an image. Unless I lost track, I think the only other thing is deciding if the author write "applet" or if the author writes some predictable string unique to the slate.

We will be using (via the template) the internal id for several things, as you can see in the diff. The id for the div, a convenience javascript variable storing the params, and the name for the function that is applied to the applet as soon as it loads to do whatever the author has designed.

I prefer "applet" for a few reasons, all about author convenience. It's shorter than an xml:id. It means the author would not be forced to make an xml:id. And the author doesn't have too much to worry about with typing and misspelling.

I thought of a third option. Authors could just do like:

setAxisSteps(1, 1, 5, 1);
setCoordSystem(-0.7, 8, -6, 56);
enableShiftDragZoom(false);

with one thing per line, and we prepend the "applet." (or something based on internal id). It's kind of nice with the source looking less cryptic; just a sequence of commands. What I don't like is that it would look so different from examples of GGB applets out there that we'd need a good independent tutorial. And authors must do one command per newline. Actually I have no idea if XSLT can do that, do you? Can XSLT (limited to 1.0) prepend something to every line of a multiline string? After clearing leading white space?

Your call. Door 1, 2, or 3?

[rbeezer]

On 2/22/19 11:02 PM, Alex Jordan wrote:

I thought of a third option. Authors could just do like:

I really like Door 3. Now you are really thinking. Excellent idea.

Anything repetitive or arcane that we can do for an author is definitely in the spirit of PreTeXt. And it gives us flexibility and future-proofs author's source (GGB will only change the API itself carefully?). Prefix would be consistent, short and hard to mis-spell. ;-)

I'd bet you could even write the var as the argument of the function and get rid of applet entirely? Not pretty, but the code is not meant for humans.

I'm not worried about instructions. Anybody who can decipher the API commands can follow clear instructions and can look at good demos inside the sample article for further guidance. And experiment until they stop messing up.

Actually I have no idea if XSLT can do that, do you? Can XSLT (limited to 1.0) prepend something to every line of a multiline string? After clearing leading white space?

In -common see named template prepend-string There should be others to clear leading whitespace. Definitely do-able (if not already done), and I'm happy to help on this part.

[rbeezer]

I force pushed some things. Still no static images. I might as well wait until everything else is squared away, in case some detail changes that changes an image. Unless I lost track, I think the only other thing is deciding if the author write "applet" or if the author writes some predictable string unique to the slate.

I'd like to take just one more look at this. With, or without, images. So let me know when you think it is final and I'll do a last review. I have not looked at the latest forced-push.

Rob

[Alex-Jordan]

That message from me is before we started talking about prepending the "applet." (or whatever) ourselves. So there's more to do now.

Plan is:

1. Accessibility review/edits of ggb-calculator.
2. Open PR for ggb-caclulator.
3. When 2 is resolved, complete this work for ggb-slate.
4. When 3 is resolved, enhance ggb-calculator so that there too, you could "prep" the calculator with some GGB commands (probably somewhere in docinfo/html)
5. Complete some started work for a ggb interactive inside a webwork.

[rbeezer]

Sounds good. Looking forward to teh calculator. Should be able to review/merge fairly quickly this coming week, not too much happening.

On 2/24/19 10:25 AM, Alex Jordan wrote:

That message from me is before we started talking about prepending the "applet." (or whatever) ourselves. So there's more to do now.

Plan is:

1. Accessibility review/edits of ggb-calculator.
2. Open PR for ggb-caclulator.
3. When 2 is resolved, complete this work for ggb-slate.
4. When 3 is resolved, enhance ggb-calculator so that there too, you could "prep" the calculator with some GGB commands (probably somewhere in docinfo/html)
5. Complete some started work for a ggb interactive inside a webwork.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/pull/993#issuecomment-466802394, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy2cmqFE3EIsP-wBl9m2QJbSj9WTtYkks5vQtkYgaJpZM4akm4H.

[Alex-Jordan]

this coming week, not too much happening.

Famous last words :)

[Alex-Jordan]

In making preview images, I am getting an unrelated new image file:

images/wolfram-cellular-automata-preview.png

Does it help if I include that in this PR?

(A force push is coming, to resolve the conflict and other things.)

[Alex-Jordan]

I suspect I may not understand preview image production. It looks like we are not using headless browsers, since I had to change the baseurl and upload standalone interactive files. Do we plan to use a headless browser and let people off the hook for PDF production? (Meaning, they don't first have to put stuff up where the HTML book lives?)

I had written this into the sample article about file paths to .ggb files. I suspect now that it is incorrect. Can you advise on what this bit should really say?

<p>
  The path to the file is relative. 
  That path needs to be valid for both output HTML and <pretext/> source files. 
  The latter is so that <pretext/> can generate an image 
  of the applet's initial state for use in static output such as PDF. 
</p>

[rbeezer]

Let's not include unrelated stuff. The MMA stuff is not really behaving and has an uncertain future.

On 2/26/19 1:29 PM, Alex Jordan wrote:

In making preview images, I am getting an unrelated new image file:

|images/wolfram-cellular-automata-preview.png|

Does it help if I include that in this PR?

(A force push is coming, to resolve the conflict and other things.)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/pull/993#issuecomment-467621332, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy2cn6Zduiwn8wUbirwyalVTs3zHtojks5vRac6gaJpZM4akm4H.

[rbeezer]

We use pageres, whatever it does. I think it relies on some headless browser (phantomjs?), but the details are not important to me.

Yes, you have to place your HTML files on a server first. Maybe you change your "baseurl", maybe you don't.

Really not sure what you mean by:

let people off the hook for PDF production

These are HTML-only objects. You build automatic snapshots with HTML files and tools. They get included in your PDF output. I don't see any hooks.

[rbeezer]

I had written this into the sample article about file paths to .ggb files. I suspect now that it is incorrect.

I think you only need to say the path needs to be relative. There's no pressing reason to give a reason.

[Alex-Jordan]

Really not sure what you mean by:

let people off the hook for PDF production

Sorry. What I mean is, suppose I want to make a PDF. And I am not in a position to easily upload something to the URL where the eBook lives. At Lane and Mt Hood, at first the faculty involved in their projects did not have this ability. Unsure if they were not given permission by their school, or just were uncomfortable with it. But some local IT person was handling the uploading of fresh HTML.

To get a PDF with new preview images, are they supposed to temporarily turn baseurl to something starting with file://?

An alternative is when using the mbx script, you would need to provide a path to where the standalone interactive html files are. Which you may be storing locally. In scratch. Or like I do in an output subfolder of the project.

[Alex-Jordan]

OK, force pushed, ready to review. Two new GGB image files. Two altered image files because of the onload commands to the app. And one altered image file just because now I have the app leaving out the toolbar (the default).

No more "applet.". Author just gives a sequence of easy to understand commands.

[Alex-Jordan]

Just did one more force push. I had the new images files in the wrong folder.

[rbeezer]

Ready for final review, and presumed merge? Maybe I can look this afternoon, once I do a snow-day makeup.

On 2/26/19 10:45 PM, Alex Jordan wrote:

Just did one more force push. I had the new images files in the wrong folder.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/pull/993#issuecomment-467744135, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy2cv90RyA5xcF2kbcNe7kGAg_J-Ybjks5vRil3gaJpZM4akm4H.

[Alex-Jordan]

Yes. I expect there are some places to make XSL tidier and anything else you might note.

Campuses closed here for the day.

[Alex-Jordan]

Force pushed after making one small edit to the sample article. A caption was saying the GGB came from base64 when it actually came from a ggb file. That is all that was changed, along with rebasing from dev.

[rbeezer]

Really nice. Thanks for cleaning up my rough-cut implementation. Four minor changes, all just incorporated into your commits. And I see now I forgot to tag the commits with the PR number - dang. I'm sorry. They do have your name on them.

Work at 125329a9a3dcf69fe04c9ee0fd9877aa17dc4152 and 24b0500df706f64768c45ad91c92001dafe7febe!

• Split into code and sample article.
• Sentence about always using applet, reversed its meaning.
• I really confused myself parsing the inserted period after the applet identifier. Thought it was a naked dot, hence the context/conent of something. Added a sentence to help anybody else similarly blinded.
• Removed the sentence in -common saying prepend-string is not used.

[rbeezer]

To get a PDF with new preview images, are they supposed to temporarily turn baseurl to something starting with file://?

Dunno. I want to say that pageres needs a "real" server. How about making a new issue? And if you are inclined, try testing some local way of doing this?

[kcrisman]

To get a PDF with new preview images, are they supposed to temporarily turn baseurl to something starting with file://?

Dunno. I want to say that pageres needs a "real" server. How about making a new issue? And if you are inclined, try testing some local way of doing this?

@Alex-Jordan did you ever make an issue of this, or did it turn out not to need to be done?

[Alex-Jordan]

@kcrisman I do not think I made an issue of it.

Separately, I think that geogebra preview images can have a clean, different route than via pageres, etc. Of course that does not nullify the need for something like pageres in general, or the issue raised here.

[kcrisman]

I guess I don't 100% understand what the issue is in any case but just was trying to find things that could use followup 😄