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
Hence, I still believe it would be a useful project that would
generate pieces of code useful to Octave in the future.