QMenu - need to be notified when it changes position due to position of target

[ddenev]

Hi,

I have wrapped QMenu in order to add a pointer (triangle) to its side.

But QMenu changes its position based on where (relative to screen top/bottom edges) the target/trigger element is positioned - when it's close to top, the menu is shown below the element, when it's close to bottom, the menu is shown above the element:

so I need to know where the menu will be positioned, relative to the target element so that I can update my css to move the arrow to the appropriate side.

How can I get this info from QMenu? Or is there any other way to find out how will QMenu be positioned?

[ddenev]

Would it be possible to add something like emit('update-position', <info about position change>) to the updatePosition function in QMenu.js?

[pdanpdan]

Interesting case. Need to think about it

[pdanpdan]

As a general rule I would mark the positioning (horizontal and vertical) against the center of the anchor element.

But I have a problem with what markers should be used when the popup is overlapping the anchor el:

|--A--|
|----P----| - here the popup is on which horizontal side?

[ddenev]

I played a little bit with the menu positioning here - https://quasar.dev/vue-components/menu#positioning
and it seems that whenever the position changes (e.g. due to screen restrictions/changes), the new menu position no longer respects the initial anchor definition.

For example
this is the "original" positioning that respects the configured anchor:

and this is the "altered" positioning that does not respect the configured anchor (after I dragged the bottom side of the browser window):

So for my case just receiving "original" or "altered" would be fine.

And keep in mind that since I know the settings for anchor and self, I can deduct the direction of the change when I get "altered".

Please correct me if I'm wrong somewhere.

[ddenev]

Hi,

any progress on this request?

thank you!

[pdanpdan]

Not yet - I haven't found a marking system that would make sense yet

[ddenev]

OK, maybe I'm not understanding the problem you're facing very well but:

1. Initially you have anchor and self defined on the component, right?
2. When the component is displayed, in certain conditions (e.g. target position, etc.) the component might not respect the initial anchor and/or self - which means there are new calculated anchor and self (see my example above - in the 2nd screenshot neither is respected)
3. If you can provide me with the "actual"/"modified" anchor and self then I can compare them to the original ones and that will give an idea of the change

Am I missing something?

[ddenev]

Hi @pdanpdan ,

any news here? have you had the chance to review my last comment? any thoughts?

[ddenev]

Hi @pdanpdan

any solution on this?

Thank you!

[ddenev]

@pdanpdan

any news on this?

[pdanpdan]

not yet, sorry

[ddenev]

can we at least revive the discussion and keep it live? :)

[pdanpdan]

it's in my todo list, no time for it for the moment

[ddenev]

Dear @pdanpdan

I did some digging and allow me to share my thoughts and findings.

QMenu has an internal method updatePosition() that is called on initial render, window resize, scrolling, props (self and anchor) reactive update, etc.

updatePosition() calls setPosition() which is defined in utils/private/position-engine.js (position-engine.js is used only by QMenu and QTooltip).

In setPosition() there is a call to an applyBoundaries() method, where all the repositioning calculations happpen:

applyBoundaries(props, anchorProps, targetProps, cfg.anchorOrigin, cfg.selfOrigin)

props is an object that holds the top and left properties for the menu. Before the call to applyBoundaries the props hold the 'requested' top and left (the ones calculated based on the initial self and anchor positioning). After the call to applyBoundaries, the props hold the actual top and left.

So... the idea is simple:

• based on the top and left before and after applyBoundaries, calculate whether the menu has been repositioned - to the left, to the right, to above, to below - relative to the 'requested' position
• compare the props before and after the call to applyBoundaries and if top or left differ then emit an event, e.g. 'position-update' that provides the 'actual' repositioning info, e.g.:

{
  up: true,
  down: false,
  left: false,
  right: false
}

the above would mean that the menu has been repositioned 'up', i.e. the 'actual' self is now "bottom middle" (if initially it was "top middle").

What do you think?

[pdanpdan]

The main problem is that the positioning algoritm is long due for a refactoring and needs fixing for some issues. That is the reason i would not touch it for the moment

[wojewsky]

any news on this?

[practicatto]

news on this?

[ericrange]

still a thing