Hello !! In this post I will be describing my latest progress in the Geogebra Filter that we are creating for Kig.
After a lot of hiccups, it finally seems that we have found a proper implementation which smartly handles both Geogebra worksheets and Geogebra tools.
Although the planning had been done a long time ago and a draft implementation which successfully read geogebra’s tools into Kig had been done, David (David Narvaez , my mentor ) was not happy with it ( and neither was I .. ) since the code looked dirty ( with a lots if-else’s scattered everywhere. Reading Geogebra worksheets and tool-files both require very similar XSLT manipulation and parsing and the challenge was to smartly create an implementation which could handle both ( Geogebra worksheets and Tools ) with the least code duplication and with a flexible and sensible design.
A lot of attempts were made by both David and me in reaching the implementation that we have today. In my first attempt I was able to create an implementation which read tools correctly but the tool file ( .ggt file ) had to be opened from the open-file Dialog ( and not from the Types Dialog in Kig ) . Again in my second attempt I was able to enable the opening of tool files from the Types Dialog instead of the file dialog. This was more accurate in behaviour since in Kig ( and also in Geogebra ) tools are maintained from a separate dialog and not from the file dialog.
Previously we had just one class to handle Geogebra files- KigFilterGeogebra class which inherited from both KigFilter and QAbstractXMLReceiver class. The problem that created was that if we extended the class to read tools, a lot of complicacy was introduced in the functions. Then we separated the QAbstractXMLReceiver part of the KigFlterGeogebra class and moved it to a new class – GeogebraTransformer class which reads the transformed XML file and generates the object-tree of the document. Both The GogebraFilter and the GeogebraToolFilter classes use an instance of this Transformer class to get the object-tree. This way the code duplicacy issue was solved and also simplified the Filter classes.
After just a little polishing, our filter will enable Kig to read Geogebra tools !!
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 🙂 .