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
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
