Layout macros (column!, grid! etc.) are moved into the kas::widgets namespace.
These layout macros no longer recurse internally (except with feature recursive-layout-widgets). This is slightly less optimal but means that e.g. column!["title", row!["a", "b"].map(|_| &())] is now possible since the internal row![..] is a widget and thus supports all the usual methods. Caveat: this is incompatible with the recursive-layout-widgets feature, and thus we warn about it in all cases.
Note that recursive layout macros must remain a feature to support usage in custom widgets where inner layout components may refer to fields of the custom widget, so all we're really doing is turning off this feature in the common case to improve diagnostic output.
Since these macros now behave (mostly) identically both within and outside of other layout macros, we can stop prepending with kas:: to identify non-recursive macro calls and just import the macros (explicitly, since glob import clashes with the stdcolumn! macro).
Layout macros (
column!,grid!etc.) are moved into thekas::widgetsnamespace.These layout macros no longer recurse internally (except with feature
recursive-layout-widgets). This is slightly less optimal but means that e.g.column!["title", row!["a", "b"].map(|_| &())]is now possible since the internalrow![..]is a widget and thus supports all the usual methods. Caveat: this is incompatible with therecursive-layout-widgetsfeature, and thus we warn about it in all cases.Note that recursive layout macros must remain a feature to support usage in custom widgets where inner layout components may refer to fields of the custom widget, so all we're really doing is turning off this feature in the common case to improve diagnostic output.
Since these macros now behave (mostly) identically both within and outside of other layout macros, we can stop prepending with
kas::to identify non-recursive macro calls and just import the macros (explicitly, since glob import clashes with thestdcolumn!macro).