Attributes for Geogebra interactives by material-id

[D. Brian Walton]

In responding to the pretext-support query from Teresa Magnus about Geogebra interactive, I saw that in principle it should be easy to make the appearance of different features optionally available and still use the simpler @geogebra="material-id" implementation with some additional attributes.

Every iframe implementation using direct material-id use the simple URL:

https://www.geogebra.org/material/iframe/id/{@geogebra}/width/800/height/450/border/888888/smb/false/stb/false/stbh/false/ai/false/asb/false/sri/false/rc/false/ld/false/sdz/false/ctl/false

[xsl/pretext-html.xsl: 9897]

The tags seem to match Geogebra App parameters (I haven't verified—just rational guessing here) (https://wiki.geogebra.org/en/Reference:GeoGebra_App_Parameters):

smb = showMenuBar

stb = showToolBar

stbh = showToolBarHelp

ai = showAlgebraInput

asb = allowStyleBar

sri = showResetIcon

rc = enableRightClick

ld = enableLabelDrags

sdz = enableShiftDragZoom

ctl = ???

Is this something worth implementing? I can see how this would be implemented fairly easily, but don't want to commit to something that is of little value to anyone. It isn't on my own radar of needed features.

- Brian

[Rob Beezer]

On 9/12/23 10:15, D. Brian Walton wrote:
> Is this something worth implementing?

Yes, I think that is a great idea (and I think maybe I had the same thought when
doing this - like I'd get back to it someday?).

Let's ease the burden on authors and not just 1-1 mimic whatever GeoGebra
exposes. Such as in the current case, maybe PreTeXt

geogebra/@toolbar = "yes"

turns on the toolbar *AND* turns on the toolbar help (if it is not too
intrusive). And maybe some GeoGebra options don't make much sense in this
context? Err on teh side of too little, we can always add later if requested.

There is not comprehensive documentation to adjust, I don't think. But if you
made a simple list (description list?) for the sample article, I could cut it
into eventual "real" documentation.

Thanks,
Rob

[Rob Beezer]

Thanks again, Brian, for your work with Terri, and for stepping up when you can
see that some relatively straightforward additions will convert this from a
periodic support question into an easy-to-use feature.

Your contribution frees me up to work on items where maybe I'm the best person
to be doing the work since it is part of a long-range plan.

Rob

[D. Brian Walton]

Okay, I need some advice about choices of which features to implement. It would be easy to support all of them, but my opinion is that for the typical use case several are undesirable because they open too much of the under-the-hood details to the user. Also, it is currently hard-coded to be a single iframe size. That probably also should be adjusted while I'm at it.

Reminder: This is a use case where there are pre-made GeoGebra activities hosted on the GeoGebra website with a material id. The user wants to include the activity in their PreTeXt document to add interactivity by referencing the material id.

In the XSL I have created and kept, I have implemented the following additional attributes.

• @toolbar="yes": the toolbar showing various GeoGebra tools the user can select is visible (above the main panel). As recommended by Rob, I also use this to turn on toolbar help, which are pop-up floating panels when a new tool is selected that explains the tool and has a link to the help page.
• @algebraInput="yes": a entry field appears (below the main panel) where a user can type an algebra equation or formula of a graph or type in GeoGebra commands to create new graphics objects.
• @resetIcon="yes": A reset control appears in the top-right of the main panel that when pushed resets the state to the original loaded state.
• @shiftDragZoom="yes": Enables ability of user to pan and zoom the field of view using a mouse or keyboard. (Otherwise the field of view is locked)

There are other possible options that I tentatively decided should not be available, and this is where I seek advice on whether we should make them possible. My thought is that these extra options make it too easy for a reader/user to modify the interactive such that it might no longer work. If an author really wants to make such features available, they can implement it directly using the javascript interface.

• @menubar="yes": This basically turns on super powers for the GeoGebra app and the user has access to all of the editing features.
• @styleBar="yes": This would make it so the user can change the appearance of the panel (axes, grid, color, etc.) as well as access different perspectives.
  
• @rightClick="yes": Turns on a pop-up menu for any right-clicked object to change its visibility, label visibility, rename, or delete.
• @labelDrag="yes": Allows the user to move the location of the labels for objects away from their default position.
  
• @clickToLaunch="yes": Shows a "play" button that means you need to click before the app actually loads.
  

Should I add any/all of those extra features?

In terms of sizing, would it make the most sense to just add @width and @height to the interactive itself? There is no slate to work with.

Brian

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDA0OS5iZWV6ZXI.1694618992%40quikprotect.

[D. Brian Walton]

I forgot to mention one side effect of the style bar being present is that it covers up the reset icon. And turning on the menu bar automatically turns on the style bar, which again covers the reset icon.

[Rob Beezer]

On 9/13/23 11:51, D. Brian Walton wrote:
> but my opinion is that for the typical use case
> several are undesirable because they open too much of the under-the-hood details
> to the user.

Right - that's how it looked to me. I think you have struck a good balance
below. Let's err on the side of not adding something, we can always add it
later. Much harder to take something away. And as you note, there are commands
that can be added ala what you did for Terri.

Reset icon: since it is going missing, let's skip it and just assume a reader
can reload the page if they want to reset the widget.

> Also, it is currently hard-coded to be a single iframe size. That
> probably also should be adjusted while I'm at it.

We never specify a height. ;-) (I think.) But that's a bit of a dodge. A
width, and when necessary an aspect ratio. As percentages, for use in *all*
conversions. Look around at other interactives and you will find
general-purpose templates which convert those into pixels, which is what I
suspect you want.

It'd be good to support @width and @aspect.

Thanks,
Rob

> Reminder: This is a use case where there are pre-made GeoGebra activities hosted
> on the GeoGebra website with a material id. The user wants to include the
> activity in their PreTeXt document to add interactivity by referencing the
> material id.
>
> In the XSL I have created and kept, I have implemented the following additional
> attributes.
>

> * @toolbar="yes": the toolbar showing various GeoGebra tools the user can

> select is visible (above the main panel). As recommended by Rob, I also use
> this to turn on toolbar help, which are pop-up floating panels when a new
> tool is selected that explains the tool and has a link to the help page.

> * @algebraInput="yes": a entry field appears (below the main panel) where a

> user can type an algebra equation or formula of a graph or type in GeoGebra
> commands to create new graphics objects.

> * @resetIcon="yes": A reset control appears in the top-right of the main panel

> that when pushed resets the state to the original loaded state.

> * @shiftDragZoom="yes": Enables ability of user to pan and zoom the field of

> view using a mouse or keyboard. (Otherwise the field of view is locked)
>
>
> There are other possible options that I tentatively decided should not be
> available, and this is where I seek advice on whether we should make them
> possible. My thought is that these extra options make it too easy for a
> reader/user to modify the interactive such that it might no longer work. If an
> author really wants to make such features available, they can implement it
> directly using the javascript interface.
>

> * @menubar="yes": This basically turns on super powers for the GeoGebra app

> and the user has access to all of the editing features.

> * @styleBar="yes": This would make it so the user can change the appearance of

> the panel (axes, grid, color, etc.) as well as access different perspectives.

> * @rightClick="yes": Turns on a pop-up menu for any right-clicked object to

> change its visibility, label visibility, rename, or delete.

> * @labelDrag="yes": Allows the user to move the location of the labels for

> objects away from their default position.

> * @clickToLaunch="yes": Shows a "play" button that means you need to click

> <mailto:pretext-dev%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-dev/MTAwMDA0OS5iZWV6ZXI.1694618992%40quikprotect <https://groups.google.com/d/msgid/pretext-dev/MTAwMDA0OS5iZWV6ZXI.1694618992%40quikprotect>.

>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com

> <mailto:pretext-dev...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-dev/CAH7VRoLWqZTS4YP%3DpkFH9O_An%2BwKk%2B9B%2BUjQ407%2BHbCbrYUCog%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CAH7VRoLWqZTS4YP%3DpkFH9O_An%2BwKk%2B9B%2BUjQ407%2BHbCbrYUCog%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[D. Brian Walton]

See PR #2070.

Note that I opted to keep the reset icon. The only place it was going to be obscured was if the menubar or style options were included, and those were both intentionally NOT implemented because it would be too easy for a user to manipulate the interactive to a point where it wouldn't work.

- Brian

To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyOC5iZWV6ZXI.1694704022%40quikprotect.

[William Haynes]

I would recommend keeping @labelDrag="yes".  It's basically harmless, but the automatic placement of the labels can be poor, especially on randomly generated diagrams, so it's nice to have the ability to manually tidy up the label positions.

Will Haynes

On Wednesday, September 13, 2023 at 2:51:24 PM UTC-4 dbrian...@gmail.com wrote:

Okay, I need some advice about choices of which features to implement...

[Rob Beezer]

On 9/16/23 11:06, William Haynes wrote:
> I would recommend keeping @labelDrag="yes".  It's basically harmless, but the
> automatic placement of the labels can be poor, especially on randomly generated
> diagrams, so it's nice to have the ability to manually tidy up the label positions.

That sounds good. All the other options have been merged already. Which means
it could be a pretty easy PR to insert one more, and update the "documentation"
in the sample article.

To get caught up, see

https://github.com/PreTeXtBook/pretext/pull/2070

(Which reminds me that maybe I should update the "dev" version of the schema for
these additions?)

Rob