[Scilab-users] question on graphic children order
Stéphane Mottelet
stephane.mottelet at utc.fr
Wed Apr 10 08:47:02 CEST 2019
Le 10/04/2019 à 01:24, Federico Miyara a écrit :
>
> Antoine,
>
> Thank you for your suggestion. It's a good one, but I still don't know
> the reason why the index of the current entity is 1 (my question was
> not really about workarounds but reasons). Stéphane said it was a
> stack, but as far as I could find, there is no stack structure in
> Scilab 6.
It was an image. The graphics objects tree is not built at the
interpreter level but internally with, at the end, Java objects. In
modules/graphic_objects/src/java/org/scilab/modules/graphic_objects/graphicObject/GraphicObject.java
you can see that the set of children of a graphic object is a (Java) list
/** Child objects list. Known by their UID */
private List <Integer> children;
When a children is added to a graphic object, the the method "addChild"
is invoked. In the source you can see
public void addChild(Integer child) {
children.add(0, child);
}
Which is coherent with the actual behavior i.e. news children are pushed
on the top.
What you would like is simply (without the 0)
public void addChild(Integer child) {
children.add(child);
}
If I have time I can see if it breaks other things, but I am almost sure
that it will...
S.
>
>
> On 09/04/2019 04:22, Antoine Monmayrant wrote:
>> Hello,
>>
>> As Stéphane said, using a tag and findobj is a possibility that I use
>> for complex layouts.
>> Here is another one: build your own vector of handles that you order
>> the way you want:
>>
>> as=[];
>> subplot(221)
>> plot(1,2)
>> as=[as,gca()]
>> subplot(222)
>> plot(1:2,2:3)
>> as=[as,gca()]
>> subplot(223)
>> plot(2*[1:2],2:3)
>> as=[as,gca()]
>> subplot(224)
>> plot(2*[1:2],-[2:3])
>> as=[as,gca()]
>> as.foreground=color('gray');
>> as.background=color('lightgray');
>> as.thickness=2;
>> as.font_size=4;
>>
>> Cheers,
>>
>> Antoine
>>
>> Le 09/04/2019 à 08:30, P M a écrit :
>>> Federico...thanks for asking the question.
>>> I was wondering about it myself for quite some time.
>>> Once recognizing the fact, I just accepted that new entities are
>>> placed at the first position.
>>> However, it might be interesting to get some insight of why it is
>>> like this....for now I guessed it has to do with how to handle memory.
>>>
>>> Philipp
>>>
>>>
>>> Am Mo., 8. Apr. 2019 um 23:01 Uhr schrieb Stéphane Mottelet
>>> <stephane.mottelet at utc.fr <mailto:stephane.mottelet at utc.fr>>:
>>>
>>> Le 08/04/2019 à 22:56, Federico Miyara a écrit :
>>>
>>>>
>>>> Stéphane,
>>>>
>>>> Sometimes one just needs to extract some parameter from an
>>>> entity and indexing is a valid way to access it.
>>>
>>> So what is your problem since you know that the order of
>>> entities is, though not natural, reproductible ? If you really
>>> need to recover a deeply hidden entity, use tags and the
>>> findobj() function.
>>>
>>> S.
>>>
>>>>
>>>> Federico
>>>>
>>>>
>>>> On 08/04/2019 12:18, Stéphane Mottelet wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Le 07/04/2019 à 10:13, Federico Miyara a écrit :
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I would like to know if there is a reason for the fact that
>>>>>> whenever new graphic objects are added to an axes, the last
>>>>>> one that has been created is always the one with index 1
>>>>>> instead of n+1 (where n is the number of objects prior to new
>>>>>> one).
>>>>>>
>>>>>> Example:
>>>>>>
>>>>>> scf(1)
>>>>>> clf(1)
>>>>>>
>>>>>> // Plot a simple two-point graph
>>>>>> plot2d([0,1],[0,1])
>>>>>> ax=gca()
>>>>>>
>>>>>> // Colect plotted data
>>>>>> a=ax.children(1).children.data
>>>>>>
>>>>>> // Plot a simple two-point graph
>>>>>> plot2d([0,1],[0.5,1.5])
>>>>>>
>>>>>> // Colect plotted data corresponding to index 1
>>>>>> b=ax.children(1).children.data
>>>>>>
>>>>>> // Colect plotted data corresponding to index 2
>>>>>> c=ax.children(2).children.data
>>>>>>
>>>>>> After the first plot we get
>>>>>>
>>>>>> a =
>>>>>> 0. 0.
>>>>>> 1. 1.
>>>>>>
>>>>>> After the second plot we get
>>>>>>
>>>>>> b =
>>>>>> 0. 0.5
>>>>>> 1. 1.5
>>>>>>
>>>>>> c =
>>>>>>
>>>>>> 0. 0.
>>>>>> 1. 1.
>>>>>>
>>>>>> I would expect that b = a, i.e, once a children object has
>>>>>> been created on the axes, it would be reasonable that its
>>>>>> index were kept constant. The current behavior is as if each
>>>>>> new object were inserted in the structure before the previous
>>>>>> one instead of after it.
>>>>>
>>>>> I would say that the set of children is a stack, i.e. each new
>>>>> child is "pushed" on top. Anyway, relying on child order
>>>>> seems, to me, a bad idea. For example, legend takes as
>>>>> (optional) first argument an array of handles, and not an
>>>>> array of child numbers.
>>>>>
>>>>> S.
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Federico Miyara
>>>>>>
>>>>>>
>>>>>> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>>>> Libre de virus. www.avast.com
>>>>>> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>>>>>
>>>>>>
>>>>>> <#m_-570024488477070350_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>>>
>>>>>> _______________________________________________
>>>>>> users mailing list
>>>>>> users at lists.scilab.org <mailto:users at lists.scilab.org>
>>>>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> users mailing list
>>>>> users at lists.scilab.org <mailto:users at lists.scilab.org>
>>>>> http://lists.scilab.org/mailman/listinfo/users <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
>>>>
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users at lists.scilab.org <mailto:users at lists.scilab.org>
>>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.scilab.org <mailto:users at lists.scilab.org>
>>> http://lists.scilab.org/mailman/listinfo/users
>>> <https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users>
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.scilab.org
>>> http://lists.scilab.org/mailman/listinfo/users
>>
>>
>> --
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> Antoine Monmayrant LAAS - CNRS
>> 7 avenue du Colonel Roche
>> BP 54200
>> 31031 TOULOUSE Cedex 4
>> FRANCE
>>
>> Tel:+33 5 61 33 64 59
>>
>> email :antoine.monmayrant at laas.fr
>> permanent email :antoine.monmayrant at polytechnique.org
>>
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/users
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190410/d228af9b/attachment.htm>
More information about the users
mailing list