[Experimental] List widgets generic experimental

[zhizhangchen]

Trying to implement list widgets using generic listitem. Please review it and give some overall comments.

[grgustaf]

This seems like a big improvement to me, being able to drop List Item into any of the list types. What do you guys think?

I'm just going to look at it from a user/functional level at this point, not digging into the code. Here are some problems I see:

1. The list items are composed of multiple widgets (e.g. a Text Split List Item has a "list Text Button" with two Texts inside, and a "List Button". But if you delete the "list Text Button", I don't think you're able to get it back. If so, that's fundamentally broken. You shouldn't be able to do anything to the widget canvas that you can not also reverse. (Perhaps "List Button" was just inadvertently removed from the palette?)

2. Similarly, if you delete an Image from a "Thumbnail list Button", you can't add one back again, as far as I can tell.

3. If you remove a "list Text Button" from a "Text Split List Item", you are left with an empty container that you can't seem to do anything with.

4. The "text" property within the list items is useless and doesn't get displayed anywhere.

5. It seems to me it would be a good simplification for the user to collapse the e.g. "Thumbnail list Button" into the "Thumbnail Split List Item". So a Thumbnail List Button becomes a widget with two zones, one on the right for a button, and one on the left that can contain text, etc. Then the main button properties would become properties of the outer list item. This would resolve problem [General] Fix issue: same file selection can not trigger Import #3 above while reducing exposed complexity.

[grgustaf]

Oops, bumped the close & comment button accidentally.

[zhizhangchen]

1. Sorry I forgot the "min and max limit of cardinality" patch. Please fetch the updated pull request and try again. This patch will prevent List buttons from being deleted.
2. Actually, you can drag an Image widget from the palette into a List Button, although it's a little hard to find the right position - the placeholder should be near the bottom of the List Button.
3. Solved by 1
4. Yes, the "text" property of some list items is useless, we can remove it easily.
5. Yes, this is a very good idea. Although the following problems should be considered, I think it's doable:
   1. For thumbnail split list item, there can only be one Image widget in the left zone, how to limit this?
   2. The properties of all split button should be inherited by the list item, so we have to specifiy htmlSelector for each property, which looks tedious. Maybe we should introduce a widget scope htmlSelector?

[grgustaf]

It's probably about time we try to truly realize the whole "zones" vision in the first place. We've always kind of avoided it. The real zones feature would be to have geometric hints about where children belong within a widget.

For allowing only one image widget, the way that should work is that there is a special image zone on the left, that can contain zero or one images and nothing else. Then the middle zone can contain N Text widgets, or whatever else is allowed. The right zone can contain zero or one List Buttons.

What should really happen is that when you hover an Image over the List Item anywhere, it realizes that images are only allowed in the left image zone, and the placeholder shows up there. In a case where a widget can potentially be dropped in multiple zones, it should be placed in the current zone where the mouse is hovering, or if not allowed there, it should geometrically find the nearest appropriate zone. I'm not sure if we really have a case where that would happen though.

[grgustaf]

Re: widget scope htmlSelector, yeah I already wanted to do that for widgets to reduce the repetition in the existing classes. I was thinking of it as a "default html selector" -- it could possibly be called that. I remember thinking that it could get a little confusing with the common properties though. But it's probably fine. It's probably a best practice not to put the html selector in the common properties, make that something that is overridden if need be per widget.

[zhizhangchen]

Replaced by #196

[zhizhangchen]

close it.