I liked the video. Here's my questions and feedback:
Is there a limit to data size? I don't need anything massive but having something extend beyond the short URL character limit would be nice. This could be dynamic too. So when the Data is too long it instead uses a token which references a local storage version of the state. Would be harder to "modify" by the general user but would make worrying about the length of the data easier for developers.
Will there be a designated SVG control? You mentioned how you could swap the ProgressWheel SVG for a different SVG. Will ImageViewer be cross-compatible with SVG's or will we need to hack the ProgressWheel and turn of the spin?
Will we be able to control the "fetch" size of the infinite scroll?
Just re-iterating that can we PLEASE get a WebContainer as a Custom Column Type as this would really reduce the overhead in designing these especially for novice users.
I didn't see "Icons" as part of the feature set. Please tell me this will be included(?)
It would be cool if you sort of supported our existing WebSDK controls in Web 2.0 kinda as-is with no future improvements and instead made a new WebSDK control that's more standardized. That would make project migration a lot more seamless.
Visual Session Controls
Can you go into more detail about this? I didn't really understand what you meant in the video.
I'm excited to see the move to Bootstrap 4.4.x. Will it be possible to specify column-count in the Fluid mode? Bootstrap 4 now uses flex-box behind the scene as the CSS implementation but *IT IS STILL* a 12-column grid layout system. Almost all of the modern layout frameworks use a column-based approach coupled with screen size media queries.
I know you mentioned a future item for supporting more Multiple Layouts per view. I think this could work but there could be a few flaws this solution could have that I hope can be avoided!
- Being able to say Small(12) Medium(4) Large(3) for columns without having to maintain 3 separate layouts is very important. In most cases I don't want to actually maintain the properties of 3-4 screen sizes for every single control (only certain ones) so when I set something to Small(12) I know that means also for medium and large and "everything up" unless I bother to go change them otherwise.
- Having to constantly reposition and resize my controls for every layout would not be fun. I know when I say S(6) it is exactly half and positioned correctly - no manual process or mistakes.
- Being able to simply resize my Xojo IDE window to see the responsiveness change through different screen breaks or "Layouts" seems a lot more useful than having to manually toggle through each Layout. I understand this might not make sense for Locale specific layouts but I think this feature would be very useful.
- Having to switch between each layout to determine the size of a control on each layout or to change its size makes each control difficult to understand and manage. So being able to see what size the control has across all Layouts in the properties panel without having to change anything is important.
I was thinking about managing control-level style properties with multiple layouts. Here's a couple ideas I had.
1) me.layout(0).style.borderColor = &cFF0000
2) me.layout("S").style.borderColor = &cFF0000
3) me.style.borderColor(&cFF0000, &c880000, &c660000) **ParamArray, And when given less properties than total layout count the last property is applied to all remaining layouts.
I think it would also be more helpful to allow the creation of an application LayoutSet. This is where you could set rules like screen size or locale requirements for each layout. Then you could set the LayoutSet on the view. This way you wouldn't need to recreate your page-size breakpoints and locale options for every single view. You just reuse your layout set!