Closed Bug 772197 Opened 12 years ago Closed 7 years ago

ENH: panel anchoring

Categories

(Add-on SDK Graveyard :: General, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: glind, Unassigned)

References

Details

Anchoring can go on any element (great!), but it is tempting to anchor on a location, rather than get it indirectly using Bounding Boxes. Sometimes I want to anchor on a point, and not on an element. Impl: add a 'where' argument to .show(), that takes an object with x,y properties. See a diff for usage: https://gist.github.com/gregglind/iconcontextmenus/commit/8667366540435dc8ca19b57d6c51d6a7ce1c1818#lib/panel.js Overlaps with https://bugzilla.mozilla.org/show_bug.cgi?id=732294
What would be the use case for this? Would being able to create a sidebar (or a bottom-bar) cover this?
Not for the case I did at https://gist.github.com/gregglind/iconcontextmenus, where I used it to make new 'right click' menus, and I wanted them to anchor at the site of the right click. Having a defined sub-bar or side-bar is an awesome *addition* though. In the general case, panel is a simplified constructor for 'html in a new XUL window'. Maybe Panel should subclass (XUL_Iframe_Widget) or similar? (Basically, me having 'loose panels', allowed me to do a really interested experiment that would have been *really hard* to do even through straight XUL. I want to see that *opened up*, not more restricted).
P3, but this probably won't be taken care of anytime soon.
Priority: -- → P3
Whiteboard: [triage:followup]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.