[Scilab-users] question on graphic children order
Federico Miyara
fmiyara at fceia.unr.edu.ar
Wed Apr 10 18:05:27 CEST 2019
Stéphane,
Thank you for your insight.
I think I've found a possible explanation fromthe user's point of view:
If several entities are successively added and some of their properties
need to be modified on the fly, it is easier to use a single instruction
that affects the newly added entity instead of having to keep track of
the index or the handle of each specific entity. I suppose it is more
frequent to modify the most recently added object than a deeply buried one.
Regards,
Federico Miyara
On 10/04/2019 03:47, Stéphane Mottelet wrote:
>
> 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
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190410/e0acf047/attachment.htm>
More information about the users
mailing list