More robust tool management

gd shared this idea 13 years ago
Under Consideration

The already available number and extent of tools seem to me to have grown out the current tool management mechanisms. I propose a set of enhancements which would make it more robust.


  • Edit tools. Currently once you create a tool, if you do not save the construction from which it was created, it is not possible to see or modify what a tool does (without looking at the XML file). I propose a possibility to copy the construction of a tool into the current construction, a reverse operation of the tool creation. The tool could then be modified and recreated, or even better, there could be a feature to reload the tool from the current construction, that is, reincorporate the changes made to the construction into the tool, and if the user wants, modifying the inpus and output objects too.
  • Customized toolbar stored in GGT: currently a GGB can have a fully customized toolbar but a GGT cannot specify how to organize its tools and macros (if my scripting request is implemented) on the toolbar. I propose that GGTs contain information about how its tools are grouped into toolbar "menus" (this information should be exported when the GGT is created). These "menus" should have names so that groupings of different GGTs can be merged together. (From now on, in the following proposals, what I write about tools also applies to macros if they are implemented.)
  • Separate menu entry for importing a GGT: the current method of using the Open command is pretty strange, especially when the file is modified and it asks if you want to save it, unnecessary for loading a GGT.
  • GGTs installed on the system: users should be able to install GGTs into their configuration area the tools in which will always appear on their toolbar, similarly to global macros in office software.
  • Incorporate the macros of a GGT in the GGB only when needed, if no one of the tools of a GGT are used in the construction, they should not be included in the GGB. This way having several GGTs installed on your system does not mean that all the GGBs you create will contain them.
  • GGT dependencies: Tools (and macros) sometimes use each other in their definition. I think it is good that GGBs include all the tools they use so that they can be used on any system. However if there is a general toolkit which a specific tool uses, it is not good if the GGT of that specific tool has to contain the more general toolkit e. g. because it would conflict with an enhanced version of that same toolkit. I think you should be able to export some tools into a GGT even without all of the tools they use - this would create a dependency between GGTs, meaning that if you want to use the more specific GGT, you must have the general toolkit installed.
  • GGT conflicts: If two GGTs contain tools with the same name, only one of them can be used at a time. The user should be able to choose which one.
  • GGT conflicts with files and toolkit upgrade: if the current GGB and a GGT installed on the system or a newly imported GGT contains a tool with the same name but the file does not contain all the tools of the GGT with identical definitions, it should be assumed that the GGT is probably a newer version of the toolkit which the GGB has used before. The user should be asked if they want to incorporate the GGT into the GGB (overwriting existing tools) or they want to temporarily disable the GGT during they edit this file (or cancel its importing if it is not a GGT installed in the system but a GGT loaded for use with this file).
  • Make tools belong to either the file or to the system. Tools of a file should be removed when a new file is created since they belong to that file and they should not be incorporated in the new file.
  • This is less important but it would be great: Central toolkit repository with a client in GeoGebra (that is, you could browse categorized GGTs from within GeoGebra and install them on your system). This, with appropriate dependency listings, would be good for automatic dependency resolution too.


(Don't be surprised if you notice similarities between the system I propose and Linux package management systems. :))

© 2022 International GeoGebra Institute