Review Request 127646: Add parameter to request collision detection against supplied menu coordinates

[Eike Hein]

> On April 13, 2016, 6:43 p.m., Marco Martin wrote:
> > I don't like the api...
> > If I understand correctly you need the menu aligned with the task item not going over the taskbar also in cases of windows can cover?
> > I would prefer in this case another open method, something along the lines of open(Plasma::Types::Location) that would open the menu relative to the visualparent, aligning it depending on the location
> 
> Eike Hein wrote:
>     No, it has nothing to do with the panel or even the visual parent. By default QMenus open towards the bottom and right of $pos. If $pos is closer to the bottom or right of the screen than the menu is big, the menu will go as far bottom and right as it can, bumping against the screen edge. In the case of the Task Manager that means the menu covers the task button. Our Task Managers have always had code to avoid this and position the context menu either against the panel edge or (better, because of multi-row task managers) the task item. The old Task Manager applet had the same code I added here to accomplish this.
>     
>     Your API suggestion is OK, but in some sense kind of doesn't overlap with this one. Your proposal would add a new API to position the menu relative to the visual parent with the Location enum (which I personally always felt is very very confusing, but I digress). This extends the coordinate-based API with a hint for how those coordinates should be respected.
> 
> Eike Hein wrote:
>     Note: I can try writing the enum API if you still want me to though ...
> 
> Marco Martin wrote:
>     the task item would be the visual parent, no?
> 
> Eike Hein wrote:
>     Yeah. The enum-based API would address the use case as well, but strictly-speaking the coordinate-based API could still benefit from this if someone prefers to use it.
>     
>     I'm fine with implementing either as you see fit.
>     
>     Though it's noteworthy that the Location enum is kind of broken by design for specifying relative positions, because it makes it hard to specify corners. You can do Left/Right/Top/Bottom, but you can't | the values to combine, say, Right and Bottom because it's not a flag enum. That means you have to bake in the assumption that Bottom means bottom-left. The coordinate-based API doesn't suffer from this restriction since you can just pass any coordinates in the visualParent. If we ever break Plasma API we should add a Position enum and convert all the relevant APIs to it.

I just noticed we have a PopupPlacement enum actually ...


- Eike


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127646/#review94585
-----------------------------------------------------------


On April 13, 2016, 5:24 p.m., Eike Hein wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127646/
> -----------------------------------------------------------
> 
> (Updated April 13, 2016, 5:24 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> -------
> 
> This adds a parameter to open() to request the menu be positioned to collide against the supplied coordinates instead of the screen edge if there's insufficient space to show the entire menu next to the coordinates. This allows Task Manager-style positioning (which used to be hardcoded in C++ in the applet), where the menu is shown above a task item in a bottom panel and to the left of the task item in a right panel. Without this opt-in behavior, the menu goes as far below/right of the coordinates as it an until it collides with the screen edge, therefore overlapping with the item.
> 
> The new behavior defaults to off, to not change API behavior.
> 
> It's added as a new parameter instead of a declarative prop in keeping with the existing style - the open coordinates are not declarative either; the whole thing is treated as a one-shot procedural op.
> 
> This will be used by the Task Manager applet to position the task context menu more smartly.
> 
> 
> Diffs
> -----
> 
>   src/declarativeimports/plasmacomponents/qmenu.h 41e8865 
>   src/declarativeimports/plasmacomponents/qmenu.cpp 2a96d77 
> 
> Diff: https://git.reviewboard.kde.org/r/127646/diff/
> 
> 
> Testing
> -------
> 
> Tested with rtl locales as well.
> 
> 
> Thanks,
> 
> Eike Hein
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160413/f390434e/attachment.html>