Alberto:
I strongly disagree. Your proposed API is not only more complex but also less capable, more redundant and more sensitive to ABI breaks. Redundant because set_dialog is the same as set_type(dialog). And redundant because relative positioning is useful to things other than just popups (e.g. the proposed decoration design where the titlebar is also a relatively positioned subsurface). More sensitive because the type "dialog" is just the current design open to change. When things do change like "dialog" you don't want to be deprecating entire functions with the type their names.
The API design proposed here is simpler, more flexible, has zero redundancy and less sensitive to ABI breaks. Remember we're not designing a toolkit with fixed semantics, but an API to support _any_ toolkit.
Robert:
Can parents be changed? Yes, see GTK. And even still, it's not sensible to impose arbitrary limitations without good reason.
What happens if I set a relative position but am (not?) parented? Am: You get positioned; Not: You don't get positioned. But also that question is not relevant to this proposal.
Should you be able to set a parent without a relative position!? Yes, two immediate use cases at least: floating toolboxes, indicators (auxiliary surfaces design doc).
What should these functions be called? Intentionally not a question to be answered in this small proposal.
Is setting a menu type without a parent an error or does the shell simply fail to change type for you? Semantics are not fully defined in Mir itself. We're open to letting the shell enfoce that (as all shells/toolkits are different which is a good thing).
Does the creation of these sort of attribute dances effectively mean creating an implied Window Management protocol which starts to look very Xey? No, we are designing an API to support toolkits.
"mir_surface_create_menu" is inappropriate for reasons mentioned at the start of this comment.
Alberto:
I strongly disagree. Your proposed API is not only more complex but also less capable, more redundant and more sensitive to ABI breaks. Redundant because set_dialog is the same as set_type(dialog). And redundant because relative positioning is useful to things other than just popups (e.g. the proposed decoration design where the titlebar is also a relatively positioned subsurface). More sensitive because the type "dialog" is just the current design open to change. When things do change like "dialog" you don't want to be deprecating entire functions with the type their names.
The API design proposed here is simpler, more flexible, has zero redundancy and less sensitive to ABI breaks. Remember we're not designing a toolkit with fixed semantics, but an API to support _any_ toolkit.
Robert: create_ menu" is inappropriate for reasons mentioned at the start of this comment.
Can parents be changed? Yes, see GTK. And even still, it's not sensible to impose arbitrary limitations without good reason.
What happens if I set a relative position but am (not?) parented? Am: You get positioned; Not: You don't get positioned. But also that question is not relevant to this proposal.
Should you be able to set a parent without a relative position!? Yes, two immediate use cases at least: floating toolboxes, indicators (auxiliary surfaces design doc).
What should these functions be called? Intentionally not a question to be answered in this small proposal.
Is setting a menu type without a parent an error or does the shell simply fail to change type for you? Semantics are not fully defined in Mir itself. We're open to letting the shell enfoce that (as all shells/toolkits are different which is a good thing).
Does the creation of these sort of attribute dances effectively mean creating an implied Window Management protocol which starts to look very Xey? No, we are designing an API to support toolkits.
"mir_surface_