[prev in list] [next in list] [prev in thread] [next in thread]
List: scilab-dev
Subject: Re: [Scilab-Dev] get(h_matrix, prop) changed from 5.5.2 to 6.0.0, inconsistent in both cases
From: Samuel Gougeon <sgougeon () free ! fr>
Date: 2019-02-06 7:48:22
Message-ID: 5b22e838-a36d-77f8-3086-d3b88dad451b () free ! fr
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 06/02/2019 à 08:14, Stéphane
Mottelet a écrit :<br>
</div>
<blockquote cite="mid:1cfe9b24-bc40-3204-6233-1f4923cca1f9@utc.fr"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<p>Hello,<br>
</p>
<div class="moz-cite-prefix">Le 06/02/2019 à 04:16, Samuel Gougeon
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:3f1bdf43-dbc7-e12b-6694-ddec1fb53170@free.fr">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<p>Hello,</p>
<p>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:<br>
<br>
test_run graphics plot2d_demo show_error<br>
test_run graphics plot_demo show_error<br>
test_run graphics bug_14042 show_error<br>
test_run gui layer show_error<br>
<br>
The first fixes simply propose to update the .dia.ref with the
transpose of properties values<br>
(e.g. <a class="moz-txt-link-freetext"
href="https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/20768"
moz-do-not-send="true">https://codereview.scilab.org/#/c/20768</a>
)</p>
<p>However, the analysis shows that the behavior of get(), that
is also called from %h_e(),<br>
changed from Scilab 5.5.2 to Scilab 6.0.0. <br>
<br>
In both cases, and up to now, the size of the <b>get(h, prop)</b>
output is not consistent when h is a vector of handles.<br>
</p>
<p>In <b>5.5.2</b>:, the output is always a row:<br>
<font size="-1"><tt>-->plot();</tt><tt><br>
</tt><tt>-->f = gcf(); Axes = f.children</tt><tt><br>
</tt><tt> Axes = <br>
2 by 1 matrix of handles:<br>
=========================<br>
Axes <br>
Axes <br>
</tt></font></p>
<p><font size="-1"><tt>-->get(Axes, "visible")</tt><tt><br>
</tt><tt> ans =</tt><tt><br>
</tt><tt>!on on !</tt><tt><br>
</tt><tt>-->get(Axes</tt></font><b><tt>'</tt></b><font
size="-1"><tt>, "visible")</tt><tt><br>
</tt><tt> ans =</tt><tt><br>
</tt><tt>!on on !</tt></font><br>
<br>
In <b>6.0.0</b> and up to now (6.0.2-), the output is always
a column:<br>
</p>
<p><font size="-1"><tt>--> f = gcf(); Axes = f.children</tt><tt><br>
</tt><tt> Axes = </tt><tt><br>
</tt><tt> 2 by 1 matrix of handles:</tt><tt><br>
</tt><tt> =========================</tt><tt><br>
</tt><tt> Axes </tt><tt><br>
</tt><tt> Axes </tt><tt><br>
</tt><tt> </tt><tt><br>
</tt><tt>--> get(Axes, "visible")</tt><tt><br>
</tt><tt> ans =</tt><tt><br>
</tt><tt>!on !</tt><tt><br>
</tt><tt>!on !</tt><tt><br>
</tt><tt>--> get(Axes</tt></font><b><tt>'</tt></b><font
size="-1"><tt>, "visible")</tt><tt><br>
</tt><tt> ans =</tt><tt><br>
</tt><tt>!on !</tt><tt><br>
</tt><tt>!on !</tt></font><br>
<br>
To me, the default size of the output should match the size of
the matrix of handles.<br>
</p>
<p>Shouldn't it?</p>
<p>When the value of the property is not scalar, it is the
user's responsability to<br>
reshape the matrix of handles in a way that is compatible with
the purpose.<br>
</p>
</blockquote>
<p>Sometimes the user does not even know how to resize if the
values do not have the same size:<br>
</p>
</blockquote>
<br>
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. <br>
But many properties have a scalar value. <br>
For instance, gcf() has 27 scalar properties over 33. gca() has 35
scalar properties over 61. etc<br>
This is why imho, <i>by default</i>, concatenating ouputs
according to the H size would be more handy.<br>
<br>
Best regards<br>
Samuel<br>
<br>
</body>
</html>
_______________________________________________
dev mailing list
dev@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic