[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-edu
Subject:    Re: Review Request 119621: Support for Geogebra's intersections, constrained points and Loci in kig 
From:       Maurizio Paolini <paolini () dmf ! unicatt ! it>
Date:       2017-09-07 15:10:08
Message-ID: 20170907151008.GC21656 () euclide ! dmf ! bs ! unicatt ! it
[Download RAW message or body]

I do not follow reviewboard.kde.org, and possibly I received this information
now only because I used it only recently regarding an issue with kig.

That said, it seems to me a pity that the effort done on the mentioned implementation
gets lost all of a sudden.

Given that geogebra appears to be the most used dinamic geometry software, and
that kig (I suspect) has only a quite small user-base, we should improve as much
as possible integration between the two.

That said, it is true that the implementation of loci in kig is problematic; for
example I was not able to include loci in "pykig", which is a pity.

Please let me know if I can be of any help on the subject.

Maurizio

On Wed, Sep 06, 2017 at 09:21:29PM -0000, Aniket Anvit wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119621/
> -----------------------------------------------------------
> 
> (Updated set. 6, 2017, 9:21 p.m.)
> 
> 
> Status
> ------
> 
> This change has been discarded.
> 
> 
> Review request for KDE Edu and David Narváez.
> 
> 
> Repository: kig
> 
> 
> Description
> -------
> 
> Line-Line intersection is perfect and simple to implement with the existing model. \
> Other Intersections are a bit challenging since they output more than one object \
> (point) unlike the other commands ( which output just one object). LineConic, \
> Circle-Circle intersections seem fine to me but I have some trouble in \
> understanding whether my approach is correctly assigning the output-label to the \
> obtained intersection points ( while filling the m_objectMap). Please check whether \
> the IntImp parameter I am passing to the IntersectionTypes is correct or not. \
> ConicConic Intersections produce 4-points sometimes and they have been implemented \
> as Line-Conic intersections in Kig. So, we have to find the Radical-Lines of the \
> conics first before finding the intersection-points. Currently , there is an issue \
> that the Radical-lines are also added to the document ( while they should not be ), \
> but this should be simple to take care (If you give the go-ahead to this approach). \
>  
> Constrained points are must for Locus. I have implemented them , but the \
> extra-handling required is making things a little ugly. Locus is under progress...
> 
> 
> Diffs
> -----
> 
> geogebra/geogebra.xsl c1e4749 
> geogebra/geogebratransformer.h 5f36827 
> geogebra/geogebratransformer.cpp aee8669 
> 
> Diff: https://git.reviewboard.kde.org/r/119621/diff/
> 
> 
> Testing
> -------
> 
> I ran some basic tests for all the intersection cases which have been implemented. \
> Seem ok. Only issue is with the conic-conic intersection case where we get the \
> additional ConicRadical Lines which should be visible in Kig. However, this should \
> be easy to take care of if this implementation survives. 
> 
> File Attachments
> ----------------
> 
> locus_working_1
> https://git.reviewboard.kde.org/media/uploaded/files/2014/08/10/9559b469-3c24-41d8-b9ba-809e68f86fbe__locus_working_1.ggb
>  locus_working_2
> https://git.reviewboard.kde.org/media/uploaded/files/2014/08/10/fce5bd47-794b-4ae3-aa21-4cd7c688c6fe__locus_working_2.ggb
>  locus_working_3
> https://git.reviewboard.kde.org/media/uploaded/files/2014/08/10/8cc09d1b-ff42-4a99-b2ad-7d7b403c92ad__locus_working_3.ggb
>  locus_crashing
> https://git.reviewboard.kde.org/media/uploaded/files/2014/08/10/c5c142eb-9542-4c2b-b6f8-0250ccdfb3fd__locus_crashing_parabola.ggb
>  
> 
> Thanks,
> 
> Aniket Anvit
> 


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic