[kig] /: Make SegmentAxisType Equivalent to the Previous Macro

[Maurizio Paolini]

I am not sure if I can "reply" to this mail... however here I am :-)

Just one note: in order to implement interaction with (e.g.) geogebra
it is not *imperative* that there is a one-one correspondence between
geogebra objects and kig objects.  If a geogebra "perpendicular
bisector" of points A and B is the axis of the segment AB, then
there is nothing wrong in implementing it just that way:
- construct the segment AB
- use the propery "segment-axis" of the constructed segment

Of course I know nothing about geogebra gb files, so perhaps I am missing
something...

Adding a new construction that is essentially already there seems only an
added confusion for the user.

On the other hand one could indeed modify the "Constructor" in order to allow
the user to construct the "segment axis" *also* by clicking on the two points.
In this way we shall have new functionality and maintain full compatibility.
The kig save files will have an extra object (the segment AB), that during
runtime will be present as an "internal" object.

This is *exactly* the way that now the "midpoint" is created (misc/specialconstructors.cc
and misc/builtin_stuff.cc).

Let me imagine a session of a user with a version of kig with such an Constructor
that "clicks" on the "segment axis" button:

1. If the user only created two points A and B, and the segment is not present,
then when the mouse hovers on point A (e.g.) a tip would appear with something
like "select this end-point", by clicking on it then as soon as the mouse hovers
over B a preview of the axis would appear.

2. I the user created the segment *and* the points A and B, as soon as the mouse
hovers on the segmen, a preview of the axis would appear, suggesting the user to
create the axis as a property of the segment, rather then an object depending
on two points (it seems fine to me, and even quite economic in terms of the object
hierarchy).  The user can still click on the two points if he/she has reasons to
work that way.

=======

Of course there can be different points of view about what actions should/should not
be implemented, and I am not contrary "by principle" to the new "perpendicular
bisector" action (it would be better to speak of "Type" instead of action),
however I would be very careful about doing something that forces the user to change
the way he/she is accustomed to act in order to create some object.

On the same line of though: it is *essential* that support for the segment axis
property is not removed, otherwise kig would not be able to load old
saved files.

Maurizio

On Wed, Jun 25, 2014 at 12:32:08PM -0400, David Narvaez wrote:
> On Tue, Jun 24, 2014 at 1:57 PM, David E. Narvaez
> <david.narvaez at computer.org> wrote:
> > Git commit 494629177ae9360ffd33fd84ae12403f20b920db by David E. Narvaez.
> > Committed on 24/06/2014 at 17:55.
> > Pushed by narvaez into branch 'master'.
> >
> > Make SegmentAxisType Equivalent to the Previous Macro
> >
> > As pointed out in https://git.reviewboard.kde.org/r/118785/, the new
> > SegmentAxisABType took two arguments instead of one like the old macro,
> > so this fixes compatibility with the previous behavior.
> 
> Aniket,
> 
> As you pointed out in the private e-mail, the final goal is to have a
> way to be able to create a perpendicular bisector from either a
> segment or two points, but the feature freeze for KDE 4.14 is today[0]
> so I decided to commit the least intrusive patch that honors the old
> behavior and leave the rest of the design and implementation to you
> since you will know better how this will interact with the
> constructions in Geogebra.
> 
> In terms of design, I would expect a Segment Axis object to deal with
> segments, not with two points, so I would think of a separate object
> called Symmetry Axis or something like that (I'm terrible with names
> so if anybody has a better idea please chime in) and a separate icon
> that we can group with Segment Axis like we group the conics. The
> implementation would essentially be your previous work on
> SegmentAxisABType.
> 
> You can continue your work on this implementation in the geogebra
> branch, since it would be mostly independent from what we have in
> master now.
> 
> David E. Narvaez
> 
> [0] http://techbase.kde.org/Schedules/KDE4/4.14_Release_Schedule
> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu