get(h_matrix, prop) changed from 5.5.2 to 6.0.0, inconsistent in both cases

classic Classic list List threaded Threaded
3 messages Options
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

get(h_matrix, prop) changed from 5.5.2 to 6.0.0, inconsistent in both cases

Hello,

In preparation to Scilab 6.0.2, some unitary or non-regression tests about graphics and GUI show some changes about the format of some properties:

test_run graphics plot2d_demo show_error
test_run graphics plot_demo show_error
test_run graphics bug_14042 show_error
test_run gui layer show_error

The first fixes simply propose to update the .dia.ref with the transpose of properties values
(e.g. https://codereview.scilab.org/#/c/20768 )

However, the analysis shows that the behavior of get(), that is also called from %h_e(),
changed from Scilab 5.5.2 to Scilab 6.0.0.

In both cases, and up to now, the size of the get(h, prop) output is not consistent when h is a vector of handles.

In 5.5.2:, the output is always a row:
-->plot();
-->f = gcf(); Axes = f.children
 Axes  =
2 by 1 matrix of handles:
=========================
Axes
Axes

-->get(Axes, "visible")
 ans  =
!on  on  !
-->get(Axes
', "visible")
 ans  =
!on  on  !

 
In 6.0.0 and up to now (6.0.2-), the output is always a column:

--> f = gcf(); Axes = f.children
 Axes  =
2 by 1 matrix of handles:
=========================
Axes
Axes

--> get(Axes, "visible")
 ans  =
!on  !
!on  !
--> get(Axes
', "visible")
 ans  =
!on  !
!on  !


To me, the default size of the output should match the size of the matrix of handles.

Shouldn't it?

When the value of the property is not scalar, it is the user's responsability to
reshape the matrix of handles in a way that is compatible with the purpose.

Regards

Samuel


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: get(h_matrix, prop) changed from 5.5.2 to 6.0.0, inconsistent in both cases

Hello,

Le 06/02/2019 à 04:16, Samuel Gougeon a écrit :

Hello,

In preparation to Scilab 6.0.2, some unitary or non-regression tests about graphics and GUI show some changes about the format of some properties:

test_run graphics plot2d_demo show_error
test_run graphics plot_demo show_error
test_run graphics bug_14042 show_error
test_run gui layer show_error

The first fixes simply propose to update the .dia.ref with the transpose of properties values
(e.g. https://codereview.scilab.org/#/c/20768 )

However, the analysis shows that the behavior of get(), that is also called from %h_e(),
changed from Scilab 5.5.2 to Scilab 6.0.0.

In both cases, and up to now, the size of the get(h, prop) output is not consistent when h is a vector of handles.

In 5.5.2:, the output is always a row:
-->plot();
-->f = gcf(); Axes = f.children
 Axes  =
2 by 1 matrix of handles:
=========================
Axes
Axes

-->get(Axes, "visible")
 ans  =
!on  on  !
-->get(Axes
', "visible")
 ans  =
!on  on  !

 
In 6.0.0 and up to now (6.0.2-), the output is always a column:

--> f = gcf(); Axes = f.children
 Axes  =
2 by 1 matrix of handles:
=========================
Axes
Axes

--> get(Axes, "visible")
 ans  =
!on  !
!on  !
--> get(Axes
', "visible")
 ans  =
!on  !
!on  !


To me, the default size of the output should match the size of the matrix of handles.

Shouldn't it?

When the value of the property is not scalar, it is the user's responsability to
reshape the matrix of handles in a way that is compatible with the purpose.

Sometimes the user does not even know how to resize if the values do not have the same size:

plot(1:2,sin(1:2));plot(1:3,cos(1:3));
h=gca().children.children.data

 h  =

   1.   0.5403023
   2.  -0.4161468
   3.  -0.9899925
   1.   0.841471
   2.   0.9092974

a cell array would be more handy:

 ans  =

  [3x2 constant]
  [2x2 constant]

S.


Regards

Samuel


_______________________________________________
dev mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: get(h_matrix, prop) changed from 5.5.2 to 6.0.0, inconsistent in both cases

Le 06/02/2019 à 08:14, Stéphane Mottelet a écrit :

Hello,

Le 06/02/2019 à 04:16, Samuel Gougeon a écrit :

Hello,

In preparation to Scilab 6.0.2, some unitary or non-regression tests about graphics and GUI show some changes about the format of some properties:

test_run graphics plot2d_demo show_error
test_run graphics plot_demo show_error
test_run graphics bug_14042 show_error
test_run gui layer show_error

The first fixes simply propose to update the .dia.ref with the transpose of properties values
(e.g. https://codereview.scilab.org/#/c/20768 )

However, the analysis shows that the behavior of get(), that is also called from %h_e(),
changed from Scilab 5.5.2 to Scilab 6.0.0.

In both cases, and up to now, the size of the get(h, prop) output is not consistent when h is a vector of handles.

In 5.5.2:, the output is always a row:
-->plot();
-->f = gcf(); Axes = f.children
 Axes  =
2 by 1 matrix of handles:
=========================
Axes
Axes

-->get(Axes, "visible")
 ans  =
!on  on  !
-->get(Axes
', "visible")
 ans  =
!on  on  !

 
In 6.0.0 and up to now (6.0.2-), the output is always a column:

--> f = gcf(); Axes = f.children
 Axes  =
2 by 1 matrix of handles:
=========================
Axes
Axes

--> get(Axes, "visible")
 ans  =
!on  !
!on  !
--> get(Axes
', "visible")
 ans  =
!on  !
!on  !


To me, the default size of the output should match the size of the matrix of handles.

Shouldn't it?

When the value of the property is not scalar, it is the user's responsability to
reshape the matrix of handles in a way that is compatible with the purpose.

Sometimes the user does not even know how to resize if the values do not have the same size:


It is always possible to split get(H,prop) with an external loop in case of heterogeneous sizes of the set of  H(i).prop. This is still the user's responsability.
But many properties have a scalar value.
For instance, gcf() has 27 scalar properties over 33. gca() has 35 scalar properties over 61. etc
This is why imho,  by default, concatenating ouputs according to the H size would be more handy.

Best regards
Samuel


_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev