KIG currently has filters for various formats ( Cabri, Dr-Geo, KGeo, KSeg ). I have been working on implementing the Geogebra-filter for KIG. Here’s some introduction about the Geogebra-filter that we are trying to implement :
The Geogebra filter that we are developing is based on XSLT ( eXtensible Stylesheet Language Transformation ). With XSLT one can transform one representation of some XML data to another ( i.e. the contents between some tag or value of some attribute can be extracted and put between some different tag or as value of some different attribute, as per the requirements of the user ). In our filter we first read and transform the XML data of the Geogebra worksheet/tool file and then use the callback interface provided by the QAbstractXmlReceiver class to carry out appropriate action on encountering specific elements or attributes.There are various objects that Geogebra ( and KIG ) allow the user to construct ( i.e. line, parallel-line, conics, circles ) with different types ( i.e different inputs. For example one can construct a circle if the center and the radius are known, or three points lying on it are known … ). In our filter we have to handle different object-types separately which requires some smart XSLT handling. Currently we have one major XSLT template ( called argsTemplate ) with which most objects which are of the same ‘type’ ( i.e require the same arguments for construction ) in both KIG and Geogebra, can be easily be KIG. We need to classify from the XML representation of the Geogebra worksheet that which object is of which type and suitably put that object in the KigDocument maintaining proper parent-child relationship ( or dependencies ). However there are many objects which are represented in slightly different way in Geogebra than they are in KIG. That requires handling with either a different XSLT template or at the callback level.
Support for points, various lines, circles, conics, some trasnformations, angles, vectors has been added. Document properties (like whether to show axis/grid or not, Euclidean or polar coordinate system, precision) and Graphic properties of objects ( like line-style, point-style, line-thickness, point-thickness, color) of Geogebra files can be read by KIG now ( will be pushed soon ). Currently I am trying to add a new object – perpendicular bisector ( which will take two points and construct the perpendicular bisector of the segment obtained by those points ) in KIG. Similar functionality exists but it is done through a built-in macro and can only construct the perpendicular bisector of segments. We are also trying to enable the Geogebra-filter to also read the .ggt files ( i.e. Geogebra tool files ). In KIG, loading ( or deleting ) a macro is done through the Types Dialog. With my current approach however, to load Geogebra tools, the user will just have to open them like a normal worksheet file ( from the open-file Dialog and not from the types dialog). The approach to read the tool files is simple – The KigDocument is created just like in case of normal Geogebra worksheet and then we create a object-hierarchy ( which contains the input and output objects of the macro ) and finally we construct a macro with this object-hierarchy and add it to the appropriate menu/subMenu.
One difficult thing to do is to support Geogebra Loci in KIG since the way they are represented in Geogebra is very different from that of KIG. I haven’t been able to figure out a plan for the Loci yet. Constrained Points, Tangents to the curves, Intersection and some arc and sector types are threatening to disturbing the uniformity of the filter. Support for Text-labels is yet to be added. The challenge is to sort out a way of supporting all the Geogebra objects in a way which stays as uniform and simple as possible throughout. If you find this interesting or have any question/suggestion feel free to contact me 🙂 .