-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance GeoGebra slates #993
Conversation
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. |
082546d
to
f665461
Compare
OK, finally, a chunk of time to review. Looks good. Notes, etc.
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 |
I have a suspicion about the width and scroll bars. The javascript inserts many things, including a div that looks like this: 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.
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. |
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 |
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 |
f665461
to
a53f1c6
Compare
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. |
Base 64:
|
App options:
|
c55a251
to
ca35721
Compare
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. |
Looking good. Comments in no particular order, maybe easier first.
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). |
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
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 "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. |
So maybe I did not understand:
Suggesting
Sleep all day, code all night. |
Current status: an interactive with no slate could have a 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 Now for an 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:
and the other is responsible for:
It is a problem that "onLoad" is used twice. We can change things so that we get
and the other is responsible for:
and things will be OK. The author is only providing the internal guts of what the
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 |
David's comments in an email about the GGB calculator have me wondering about the event that injects the applet. A |
Thanks for the long careful reply. Very helpful on both accounts. I had not chased through to the conclusion that |
ca35721
to
36bd45c
Compare
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:
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? |
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.
|
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 |
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:
|
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
<#993 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABy2cmqFE3EIsP-wBl9m2QJbSj9WTtYkks5vQtkYgaJpZM4akm4H>.
|
Famous last words :) |
In making preview images, I am getting an unrelated new image file:
Does it help if I include that in this PR? (A force push is coming, to resolve the conflict and other things.) |
I suspect I may not understand preview image production. I had written this into the sample article about file paths to .ggb files.
|
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
<#993 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABy2cn6Zduiwn8wUbirwyalVTs3zHtojks5vRac6gaJpZM4akm4H>.
|
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:
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. |
I think you only need to say the path needs to be relative. There's no pressing reason to give a reason. |
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 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. |
36bd45c
to
c63b7ca
Compare
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. |
c63b7ca
to
1d4c769
Compare
Just did one more force push. I had the new images files in the wrong folder. |
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
<#993 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABy2cv90RyA5xcF2kbcNe7kGAg_J-Ybjks5vRil3gaJpZM4akm4H>.
|
Yes. I expect there are some places to make XSL tidier and anything else you might note. Campuses closed here for the day. |
1d4c769
to
13df823
Compare
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. |
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.
|
Dunno. I want to say that |
@Alex-Jordan did you ever make an issue of this, or did it turn out not to need to be done? |
@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. |
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 😄 |
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.