malisipi / mui

A Cross-Platform UI Library
https://malisipi.github.io/mui/
Apache License 2.0
102 stars 10 forks source link

Suggesting Other Possibly Useful Widgets (UpDown and List view) #10

Closed Wajinn closed 1 year ago

Wajinn commented 1 year ago

Suggesting to add some well known widgets that seem to be missing or would be nice to add, to the existing awesome collection:

1) Combo box (similar to existing select box, but with scrollbar option) 2) List box (similar to select box, but all options viewable and scrollbar option, and clicking selection is direct action) 3) UpDown box (has 2 arrows on right side, where user can click up or down, to increase or decrease a displayed value) 4) List view (kind of similar to your cell example, but as a configurable widget)

malisipi commented 1 year ago

I agree the controls are required. But i could not understand a few things, 1- How is the combo box different from the select box? Is it always viewable or viewable until user-select? 2- Should the list view be editable? If not, what is different between the table widget? Also thank you for your contribution.

Wajinn commented 1 year ago

Thanks for the response. You are doing a good job.

1- How is the combo box different from the select box?

The combo box also has a scrollbar (usually vertical and on right side), to allow for a list that is longer than what is visible.

Is it always viewable or viewable until user-select?

Combo box contents become viewable, when you select it, like the select box. Difference is the vertical scrollbar. With the list box, the contents are always viewable (before user select), and not hidden. The list box also uses the vertical scrollbar, when necessary.

2- Should the list view be editable?

Usually, no. But sometimes list views are allowed to be editable. A similar widget where contents are usually editable is called a DataGrid or Grid view. However, DataGrid view can allow each cell to be editable, like a spreadsheet. Where often list views work by entire rows, and are a bit simpler.

If not, what is different between the table widget?

There are different variations of list views. The list view can be simpler, so like a list box, or be more complicated. List box and list view can be considered as related:

1) List box is basic 2) List view is the next more advanced with additional features 3) DataGrid/Grid view is the most advanced, and is like a spreadsheet.

A list box usually has rows, with no columns. All options or a certain number of rows are visible. If the number of rows are greater than the space available, then a vertical scroll bar is shown. Usually the entire "row" is highlighted, before selection and corresponding action/function. However, in some variations, you can have or allow for a picture/icon on the left side and along with the text. Other variations just have text.

The list view, would be similar to your table widget, where you have both rows and columns. However, only the row can be highlighted and clicking on a row can initiate an action/function. Then of course there is the most advanced form, the DataGrid view, where people can click on cells and is like a spreadsheet. But a super DataGrid widget might be more than some need or they may want something simpler too. The present table widget doesn't have options for these types of functionality.

malisipi commented 1 year ago

I have implemented list view with e41036d commit. It has accessibility issues with keyboard for now. It will be fixed in next commits. If you want to see a working example, you can browse demo_with_list.v in examples.

image

Wajinn commented 1 year ago

I have implemented list view with [e41036d]

Nice, that's about correct. However, 2 things of possible consideration.

1) A scrollbar option or highlight can keep going down and number of rows shown changes (so no scrollbar needed). 2) Allow user to choose text size.

Maybe have a default size, if the user doesn't put otherwise.

malisipi commented 1 year ago
  1. You can insert rows and row height will be total height / number of rows. Automatic scrollbars is not implemented yet on any widget and I'm not sure how to implement that. (I could misunderstand that. If it, please correct me).
  2. text_size option is supported now on list view.

Also UpDown widget (aka Spinner) is finished with accessibility support.

Spinner Source Code of Example

Wajinn commented 1 year ago

Also UpDown widget (aka Spinner) is finished with accessibility support.

Spinner/UpDown looks/works fantastically.

text_size option is supported now on list view.

Awesome work.

You can insert rows and row height will be total height / number of rows. Automatic scrollbars is not implemented yet on any widget and I'm not sure how to implement that.

Possibly there are 3, sort of easier/quicker, solutions/suggestions for consideration:

  1. No scrollbar, have a "viewable rows" option.

Have it where the MUI user selects how many rows before the highlight are viewable. So the user has 20 rows of data, but only wants to make space for 5 viewable rows. If there was an "viewable rows" option (and they chose 5), then only the highlighted and 4 previous rows (thus 5) would be shown. In this way, no scrollbar is needed. They just press down on the keyboard.

  1. Use the vertical slider widget to be the optional "scrollbar".

The height of the vertical slider would automatically equal to that of the table. Each downward click of the slider, would equal a set number of viewable rows. So again, if there was a total of 20 rows of data, but only 5 rows shown as viewable (as user selected option), the "value_max" could automatically be equal to 4 (or whatever number of rows to move down). Also the height of the drawn rectangle for the slider could be made taller, thus would look just about exactly like a scrollbar.

  1. Create a new scroll view widget.

A scroll view would be a frame/rect with a scrollbar attached. So the user creates a window, then a scroll view, and then the list view can be put into the scroll view. The advantage of that is you could put other widget types into the scroll view, such as labels, buttons, etc...

Would also be good to make the horizontal scroll bar and vertical scroll bar optional, so the user can have both or only one.

malisipi commented 1 year ago

I'm working on making easier to use scrollbar widget. It will be easy to integrate with other widgets.

app.list(id:"list", table:user_list x:300, y:220, width:380, height:100, row_height:40)
app.scrollbar(id:"list_scrollbar", x:680, y:220, width: 20, height:100, vertical:true, connected_widget:app.get_object_by_id("list")[0])

It's limited by vertical scrollbars for now. I will support horizontal scrollbars. Also i will support another widgets (includes frames). And i will not make a separate scroll view. Because it's same with frame widgets that has scrollbars. However, i will write a macro function to make that.

You can watch the video to see how works. And you can follow the progress from extended-scrollbar-support branch. (It's not merged with main branch yet.)

PS: Also I supported row_height in tables and lists.

scroll_list.webm

Wajinn commented 1 year ago

I'm working on making easier to use scrollbar widget. It will be easy to integrate with other widgets. It's limited by vertical scrollbars for now. I will support horizontal scrollbars. Also i will support another widgets (includes frames).

PS: Also I supported row_height in tables and lists

This looks excellent, as is your project overall. Please do have the vertical and horizontal scrollbars as separate options (as it appears capable in your example), so the user can choose one or both to appear. Look forward to the merging with the main branch.

Wajinn commented 1 year ago

Played with it after the merge. Is implemented in a very nice way, where things work together and there are useful options. I think we can say that these widgets are done, so will close.