Re: ROPopup, views and zIndexes

> Hi Dennis,
>
> Sorry for my late answer.
>
>> I looked at the following method:
>>
>> ROPopup>>createElementFor: element
>> ^ ROElement new
>> add: (ROElement new
>> + ((ROLabel
>> text: (text roValue: element model)) color: textColor))
>> + box copy;
>> yourself
>>
>>
>> and noticed some things:
>> • A ROElement is create inside another. Out of curiosity: why is this necessary?
>
> Look at the following example:
>
> <Screen Shot 2013-04-04 at 8.37.28 PM.png>
>
> The popup shows "hello" in a gray background. There are two elements here. The gray background and the white text.
>> • When doing ROElement new, these elements are NOT added to the same view, the given element is in, thus these elements dont use the same zOrdering. What view is this? Where is it from and why is it a different one?
>
> You are very right. The two elements are not added in the same view. It took us some time to come up with that solution. The reason is that you do not want to have the same camera for the view and the popup. Consider the following example:
>
> -=-=-=-=-=-=-=-=-=-=-=-=
> | view el stack |
> stack := ROViewStack new.
> view := ROView new.
> el := ROElement on: 123.
> el + ROBox.
> el @ (ROPopup new receivingView: stack).
> el @ RODraggable.
>
> view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ].
>
> view add: el.
> stack addView: view.
> stack open
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> Do a bit of clicking on the background and raise the popup. You get something like:
> <Screen Shot 2013-04-05 at 2.34.54 PM.png>
> The node is large and the popup has its original size.
>
> Now, if you remove the "receivingView: stack" as in:
> -=-=-=-=-=-=-=-=-=-=-=-=
> | view el stack |
> stack := ROViewStack new.
> view := ROView new.
> el := ROElement on: 123.
> el + ROBox.
> el @ (ROPopup new).
> el @ RODraggable.
>
> view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ].
>
> view add: el.
> stack addView: view.
> stack open
> -=-=-=-=-=-=-=-=-=-=-=-=
>
>
> You will have a big popup. Rather ugly isn't it?
> <Screen Shot 2013-04-05 at 2.36.55 PM.png>
>
>
>
>
>
>> • The created elements will have a zIndex of zero, since none is set.
>> To make popups work in the case a view uses ROBasicZOrdering I changed the method in the following way:
>>
>> ROPopup>>createElementFor: element
>> ^ (ROElement new view: element view; zIndex: element zIndex + 1; yourself)
>> add: ((ROElement new view: element view; zIndex: element zIndex + 1; yourself)
>> + ((ROLabel
>> text: (text roValue: element model)) color: textColor))
>> + box copy;
>> yourself
>>
>>
>> These changes should not affect the normal use case.
>>
>> I don't know if this is the correct way to do this, or if there are maybe underlaying issues with zIndex in general which should be adressed first.
>>
>> What do you think?
>
> If I understand correctly, you want to use the zIndex to always have the popup above the pointed element. Normally, this is not necessary since the popup is the last in the drawing queue (since it is added when a MOMouseEnter is raised). However, I see this is not always the case since you are using zIndexes: you may have elements with a different zIndex and the popup has still 0 as zIndex.
>
> But why "+1" ? The popup should be above all the other nodes shouldn't it? It could therefore be 10000 instead no?
>
>> I attached the code if you want to merge it in.
>
> I have no problem to include your change, I am just trying to figure out the usage scenario first.
>
> Cheers,
> Alexandre
>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> On Apr 5, 2013, at 8:41 PM, Alexandre Bergel <[hidden email]> wrote:
>
>> Hi Dennis,
>>
>> Sorry for my late answer.
>>
>>> I looked at the following method:
>>>
>>> ROPopup>>createElementFor: element
>>> ^ ROElement new
>>> add: (ROElement new
>>> + ((ROLabel
>>> text: (text roValue: element model)) color: textColor))
>>> + box copy;
>>> yourself
>>>
>>>
>>> and noticed some things:
>>> • A ROElement is create inside another. Out of curiosity: why is this necessary?
>>
>> Look at the following example:
>>
>> <Screen Shot 2013-04-04 at 8.37.28 PM.png>
>>
>> The popup shows "hello" in a gray background. There are two elements here. The gray background and the white text.
>>> • When doing ROElement new, these elements are NOT added to the same view, the given element is in, thus these elements dont use the same zOrdering. What view is this? Where is it from and why is it a different one?
>>
>> You are very right. The two elements are not added in the same view. It took us some time to come up with that solution. The reason is that you do not want to have the same camera for the view and the popup. Consider the following example:
>>
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> | view el stack |
>> stack := ROViewStack new.
>> view := ROView new.
>> el := ROElement on: 123.
>> el + ROBox.
>> el @ (ROPopup new receivingView: stack).
>> el @ RODraggable.
>>
>> view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ].
>>
>> view add: el.
>> stack addView: view.
>> stack open
>> -=-=-=-=-=-=-=-=-=-=-=-=
>>
>> Do a bit of clicking on the background and raise the popup. You get something like:
>> <Screen Shot 2013-04-05 at 2.34.54 PM.png>
>> The node is large and the popup has its original size.
>>
>> Now, if you remove the "receivingView: stack" as in:
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> | view el stack |
>> stack := ROViewStack new.
>> view := ROView new.
>> el := ROElement on: 123.
>> el + ROBox.
>> el @ (ROPopup new).
>> el @ RODraggable.
>>
>> view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ].
>>
>> view add: el.
>> stack addView: view.
>> stack open
>> -=-=-=-=-=-=-=-=-=-=-=-=
>>
>>
>> You will have a big popup. Rather ugly isn't it?
>> <Screen Shot 2013-04-05 at 2.36.55 PM.png>
>>
>>
>>
>>
>>
>>> • The created elements will have a zIndex of zero, since none is set.
>>> To make popups work in the case a view uses ROBasicZOrdering I changed the method in the following way:
>>>
>>> ROPopup>>createElementFor: element
>>> ^ (ROElement new view: element view; zIndex: element zIndex + 1; yourself)
>>> add: ((ROElement new view: element view; zIndex: element zIndex + 1; yourself)
>>> + ((ROLabel
>>> text: (text roValue: element model)) color: textColor))
>>> + box copy;
>>> yourself
>>>
>>>
>>> These changes should not affect the normal use case.
>>>
>>> I don't know if this is the correct way to do this, or if there are maybe underlaying issues with zIndex in general which should be adressed first.
>>>
>>> What do you think?
>>
>> If I understand correctly, you want to use the zIndex to always have the popup above the pointed element. Normally, this is not necessary since the popup is the last in the drawing queue (since it is added when a MOMouseEnter is raised). However, I see this is not always the case since you are using zIndexes: you may have elements with a different zIndex and the popup has still 0 as zIndex.
>>
>> But why "+1" ? The popup should be above all the other nodes shouldn't it? It could therefore be 10000 instead no?
>>
>>> I attached the code if you want to merge it in.
>>
>> I have no problem to include your change, I am just trying to figure out the usage scenario first.
>>
>> Cheers,
>> Alexandre
>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Don't give to get. Just give."
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Cheers,
> Alexandre
>
>
>
>> On Apr 5, 2013, at 8:41 PM, Alexandre Bergel <[hidden email]> wrote:
>>
>>> Hi Dennis,
>>>
>>> Sorry for my late answer.
>>>
>>>> I looked at the following method:
>>>>
>>>> ROPopup>>createElementFor: element
>>>> ^ ROElement new
>>>> add: (ROElement new
>>>> + ((ROLabel
>>>> text: (text roValue: element model)) color: textColor))
>>>> + box copy;
>>>> yourself
>>>>
>>>>
>>>> and noticed some things:
>>>> • A ROElement is create inside another. Out of curiosity: why is this necessary?
>>>
>>> Look at the following example:
>>>
>>> <Screen Shot 2013-04-04 at 8.37.28 PM.png>
>>>
>>> The popup shows "hello" in a gray background. There are two elements here. The gray background and the white text.
>>>> • When doing ROElement new, these elements are NOT added to the same view, the given element is in, thus these elements dont use the same zOrdering. What view is this? Where is it from and why is it a different one?
>>>
>>> You are very right. The two elements are not added in the same view. It took us some time to come up with that solution. The reason is that you do not want to have the same camera for the view and the popup. Consider the following example:
>>>
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>> | view el stack |
>>> stack := ROViewStack new.
>>> view := ROView new.
>>> el := ROElement on: 123.
>>> el + ROBox.
>>> el @ (ROPopup new receivingView: stack).
>>> el @ RODraggable.
>>>
>>> view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ].
>>>
>>> view add: el.
>>> stack addView: view.
>>> stack open
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>
>>> Do a bit of clicking on the background and raise the popup. You get something like:
>>> <Screen Shot 2013-04-05 at 2.34.54 PM.png>
>>> The node is large and the popup has its original size.
>>>
>>> Now, if you remove the "receivingView: stack" as in:
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>> | view el stack |
>>> stack := ROViewStack new.
>>> view := ROView new.
>>> el := ROElement on: 123.
>>> el + ROBox.
>>> el @ (ROPopup new).
>>> el @ RODraggable.
>>>
>>> view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ].
>>>
>>> view add: el.
>>> stack addView: view.
>>> stack open
>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>
>>>
>>> You will have a big popup. Rather ugly isn't it?
>>> <Screen Shot 2013-04-05 at 2.36.55 PM.png>
>>>
>>>
>>>
>>>
>>>
>>>> • The created elements will have a zIndex of zero, since none is set.
>>>> To make popups work in the case a view uses ROBasicZOrdering I changed the method in the following way:
>>>>
>>>> ROPopup>>createElementFor: element
>>>> ^ (ROElement new view: element view; zIndex: element zIndex + 1; yourself)
>>>> add: ((ROElement new view: element view; zIndex: element zIndex + 1; yourself)
>>>> + ((ROLabel
>>>> text: (text roValue: element model)) color: textColor))
>>>> + box copy;
>>>> yourself
>>>>
>>>>
>>>> These changes should not affect the normal use case.
>>>>
>>>> I don't know if this is the correct way to do this, or if there are maybe underlaying issues with zIndex in general which should be adressed first.
>>>>
>>>> What do you think?
>>>
>>> If I understand correctly, you want to use the zIndex to always have the popup above the pointed element. Normally, this is not necessary since the popup is the last in the drawing queue (since it is added when a MOMouseEnter is raised). However, I see this is not always the case since you are using zIndexes: you may have elements with a different zIndex and the popup has still 0 as zIndex.
>>>
>>> But why "+1" ? The popup should be above all the other nodes shouldn't it? It could therefore be 10000 instead no?
>>>
>>>> I attached the code if you want to merge it in.
>>>
>>> I have no problem to include your change, I am just trying to figure out the usage scenario first.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Don't give to get. Just give."
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Hi all,
>
> Thanks for the explanations Alexandre. It seems that the problem with the z-indices does no longer exists. When I try with all the latest code, the pop-ups are always in front. I'm not sure what has changed, but it seems it works now, so my code change suggestion is no longer necessary.
>
> Cheers,
> Dennis
>
>
> On Fri, Apr 5, 2013 at 11:16 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> On Apr 6, 2013, at 12:08 AM, Alexandre Bergel <[hidden email]> wrote:
>
> >> Using two nested elements for modeling "hello" + background is not really clean from a conceptual point of view, but this should go away once we get a proper way of building complex shapes. Right? :)
> >
> > "is not really clean " => Well... I would not be that categoric.
>
> Well, you are using two elements just to simulate a background. You are not expressing information, you are merely expressing the way the information (hello) should be presented. This is the job of a shape, at least in the Roassal and Mondrian design. So, from this point of view, it is not clean.
>
> > But yes, a way to better compose graphical shape is necessary.
> > Juraj is currently working on this. This is necessary to move forward in getting rid of Mondrian. So far, he has done the "easy things". We cannot avoid the umlShape and classBlueprint any longer.
> > We hope to make a proposal to this mailing list at the beginning of the next week.
>
> Great. I would happily help.
>
> Cheers,
> Doru
>
>
> > Cheers,
> > Alexandre
> >
> >
> >
> >> On Apr 5, 2013, at 8:41 PM, Alexandre Bergel <[hidden email]> wrote:
> >>
> >>> Hi Dennis,
> >>>
> >>> Sorry for my late answer.
> >>>
> >>>> I looked at the following method:
> >>>>
> >>>> ROPopup>>createElementFor: element
> >>>>    ^ ROElement new
> >>>>                    add: (ROElement new
> >>>>                                    + ((ROLabel
> >>>>                                            text: (text roValue: element model)) color: textColor))
> >>>>                                    + box copy;
> >>>>                    yourself
> >>>>
> >>>>
> >>>> and noticed some things:
> >>>>    • A ROElement is create inside another. Out of curiosity: why is this necessary?
> >>>
> >>> Look at the following example:
> >>>
> >>> <Screen Shot 2013-04-04 at 8.37.28 PM.png>
> >>>
> >>> The popup shows "hello" in a gray background. There are two elements here. The gray background and the white text.
> >>>>    • When doing ROElement new, these elements are NOT added to the same view, the given element is in, thus these elements dont use the same zOrdering. What view is this? Where is it from and why is it a different one?
> >>>
> >>> You are very right. The two elements are not added in the same view. It took us some time to come up with that solution. The reason is that you do not want to have the same camera for the view and the popup. Consider the following example:
> >>>
> >>> -=-=-=-=-=-=-=-=-=-=-=-=
> >>> | view el stack |
> >>> stack := ROViewStack new.
> >>> view := ROView new.
> >>> el := ROElement on: 123.
> >>> el + ROBox.
> >>> el @ (ROPopup new receivingView: stack).
> >>> el @ RODraggable.
> >>>
> >>> view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ].
> >>>
> >>> view add: el.
> >>> stack addView: view.
> >>> stack open
> >>> -=-=-=-=-=-=-=-=-=-=-=-=
> >>>
> >>> Do a bit of clicking on the background and raise the popup. You get something like:
> >>> <Screen Shot 2013-04-05 at 2.34.54 PM.png>
> >>> The node is large and the popup has its original size.
> >>>
> >>> Now, if you remove the "receivingView: stack" as in:
> >>> -=-=-=-=-=-=-=-=-=-=-=-=
> >>> | view el stack |
> >>> stack := ROViewStack new.
> >>> view := ROView new.
> >>> el := ROElement on: 123.
> >>> el + ROBox.
> >>> el @ (ROPopup new).
> >>> el @ RODraggable.
> >>>
> >>> view on: ROMouseClick do: [ :event | ROZoomInMove new on: view ].
> >>>
> >>> view add: el.
> >>> stack addView: view.
> >>> stack open
> >>> -=-=-=-=-=-=-=-=-=-=-=-=
> >>>
> >>>
> >>> You will have a big popup. Rather ugly isn't it?
> >>> <Screen Shot 2013-04-05 at 2.36.55 PM.png>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>    • The created elements will have a zIndex of zero, since none is set.
> >>>> To make popups work in the case a view uses ROBasicZOrdering I changed the method in the following way:
> >>>>
> >>>> ROPopup>>createElementFor: element
> >>>>    ^ (ROElement new view: element view; zIndex: element zIndex + 1; yourself)
> >>>>                    add: ((ROElement new view: element view; zIndex: element zIndex + 1; yourself)
> >>>>                                    + ((ROLabel
> >>>>                                            text: (text roValue: element model)) color: textColor))
> >>>>                                    + box copy;
> >>>>                    yourself
> >>>>
> >>>>
> >>>> These changes should not affect the normal use case.
> >>>>
> >>>> I don't know if this is the correct way to do this, or if there are maybe underlaying issues with zIndex in general which should be adressed first.
> >>>>
> >>>> What do you think?
> >>>
> >>> If I understand correctly, you want to use the zIndex to always have the popup above the pointed element. Normally, this is not necessary since the popup is the last in the drawing queue (since it is added when a MOMouseEnter is raised). However, I see this is not always the case since you are using zIndexes: you may have elements with a different zIndex and the popup has still 0 as zIndex.
> >>>
> >>> But why "+1" ? The popup should be above all the other nodes shouldn't it? It could therefore be 10000 instead no?
> >>>
> >>>> I attached the code if you want to merge it in.
> >>>
> >>> I have no problem to include your change, I am just trying to figure out the usage scenario first.
> >>>
> >>> Cheers,
> >>> Alexandre
> >>>
> >>>
> >>> --
> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >>> Alexandre Bergel  http://www.bergel.eu
> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Moose-dev mailing list
> >>> [hidden email]
> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>
> >> --
> >> www.tudorgirba.com
> >>
> >> "Don't give to get. Just give."
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Moose-dev mailing list
> >> [hidden email]
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "No matter how many recipes we know, we still value a chef."
>
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev