Re: Polarplot Axes

[Rik]

On 01/11/2018 09:00 AM, address@hidden wrote:

Subject:

Re: More GSOC projects

From:

Pantxo <address@hidden>

Date:

01/11/2018 05:08 AM

To:

address@hidden

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

quoted-printable

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=UTF-8

Message:

2

Rik-4 wrote

Nir,

I added three good ideas (at least I think so) to the GSOC Project List

http://wiki.octave.org/Summer_of_Code_Project_Ideas#GUI_Variable_Editor_and_Property_Inspector
http://wiki.octave.org/Summer_of_Code_Project_Ideas#SPQR_Interface
https://wiki.octave.org/Summer_of_Code_Project_Ideas#_PolarAxes_and_Plotting_Improvements

Haven't some of the projects already been completed in the last GSOC
cycle?  I'm thinking of the Special Functions and ODE projects.


--Rik

Rik,

I don't think this polar axes project is a step in the right direction.
Matlab has split the complicated tasks of axes objects into single objects:
lines, text (graphics primitives), ticks (ruller objects) etc ... and the
classdef "axes" objects is built from an aggregation of those objects.

ATM, our classdef support is not sufficient to go the HG2 graphics system
route (I can extend on this if necessary), but IMO what we need is to
disentangle the current axes object mess and try to mimic Matlab (at leat
formally) *not* to add new super-complicated low level objects.

I don't disagree with you, but I think timing is important.  As you say, the classdef system in Octave is not up to supporting Matlab's HG2 implementation.  Backing up further, no one has even made a list of what features would be necessary in classdef to support HG2, then how long each feature would take to implement, then who would actually do the coding.  And that would just get one a classdef implementation that is effective.  After that, we would need to convert the legacy graphics objects to the new system which is a chore in itself because we would still need to support the legacy get/set schema-based approach.  If we can only make progress on polaraxes after classdef and HG2 have been finished it might be two or more years before this feature is added.

On the other hand, polaraxes wouldn't be that hard to implement today.  The principal work would be in gl-render.cc, and I expect large chunks of the code would continue to be useful when the object is converted to HG2.  Besides the rendering, there is adapting the graphics scripts to recognize both "axes" and "polaraxes" as axes objects.  For example, isaxes() should return true for both of these primitive types.  The work that is done here will continue to be useful regardless of how the polaraxes object is actually implemented.

Hence, I still believe it would be a useful project that would generate pieces of code useful to Octave in the future.

--Rik