Page MenuHomePhabricator

efl_ui_grid : apply relative size feature and row/column count.
Needs RevisionPublic

Authored by SanghyeonLee on Jan 18 2019, 1:00 AM.

Details

Summary

The patch is updating efl_ui_grid overal functionality including row/column count feature
and relative size feature which calls partition.

The partition is grid specific feature which works similar like our size hint weight.
if user set the partition [N * M], get the item size by calculating N and M numbers item to
be shown in the viewport.

this value is depending on the viewport size, so if viewport is resized,
item size will be resized by viewport changes and partition will not be changed.

item_size_set is for absolute size on the other hand, regardless of viewport changes,
it still show the same size of item.

both value can be set in indivisual axis, but the final call will be always respected.

see more details in the documents in efl_ui_grid.eo.

Test Plan

run the efl_ui_grid_example_1.c in src/example/elementary.

you can test 4 different case,

item_size_set
partition_set,
row_partition_set with item size_set
column_partition_set with item_size_set

and you can see how it works differently by changing window size.

Diff Detail

Repository
rEFL core/efl
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 8922
Build 7784: arc lint + arc unit
SanghyeonLee created this revision.Jan 18 2019, 1:00 AM
SanghyeonLee requested review of this revision.Jan 18 2019, 1:00 AM

Additionally,
while I making this features,
I need to use struct about row, column repeatly,
so I wonder that we could add some public structure about row and column like, Eina_Table, {int row, int col} what you guys think?

This feature will be applied in Efl.Ui.Grid_View either and Eina_Table can be very useful.

fallback to IMAX size in original value

rebase patch

Additionally,
while I making this features,
I need to use struct about row, column repeatly,
so I wonder that we could add some public structure about row and column like, Eina_Table, {int row, int col} what you guys think?

This feature will be applied in Efl.Ui.Grid_View either and Eina_Table can be very useful.

I think Eina_Table could be useful, but at this point pushing for a new public API seems hard timing wise. I think it is ok to have it internal in Grid_View at the moment and work during next release cycle to make it public properly by refactoring Grid_View.

cedric accepted this revision.Jan 23 2019, 10:41 AM
cedric added a subscriber: segfaultxavi.

It seems technically correct to me, but could @segfaultxavi review the documentation that come with this patch before landing it?

This revision is now accepted and ready to land.Jan 23 2019, 10:41 AM

yes I think it might need @segfaultxavi 's review about the documents.

I have a few comments:

  • partition seems a bit unclear to me, I would call it visible_rows and visible_columns.
  • There's a lot of inconsistency among the properties: item_size is an Eina.Size2D, count is two separate ints (row_count and column_count), and partition can be accessed through 3 different properties. I would remove partition_set.

So, in summary, I suggest (with amended documentation):

{
   [[Simple grid widget with a Linear Pack interface. All items in the grid have the same size,
     which can be controlled by setting each item's size with @.item_size or by setting
     the amount of visible items in each row and column with @.visible_rows and @.visible_columns.
     When both are given, the last one to be set is respected.
     The linear packing implies that items are added to the grid as if it was a list, and the widget
     takes care of arranging the items in a 2D fashion.
   ]]
   methods {
     @property item_size {
         [[Size of each item in the grid.
           The individual min/max size of each item will be respected.
           If either the width or the height is $0, the value calculated from @.visible_rows or
           @.visible_columns will be used.]]
         values {
            size: Eina.Size2D; [[Size of item on the grid.]]
         }
      }
      @property visible_rows {
        [[The amount of visible rows in the grid (or the amount of items per column).
          The resulting number of columns is calculated when this value is set, and can be retrieved
          with @.column_count.]]
         values {
            rows: double; [[Amount of visible rows.]]
         }
      }
      @property visible_columns {
        [[The amount of visible columns in the grid (or the amount of items per row).
          The resulting number of rows is calculated when this value is set, and can be retrieved
          with @.row_count.]]
         values {
            columns: double; [[Amount of visible columns.]]
         }
      }
      @property row_count {
        [[The number of rows in the grid. This is calculated from the other values and cannot
          be set directly.
          see @.visible_columns @.item_size
          see @Efl.Container.content_count]]
        get{}
        values {
            count: int; [[The number of rows.]]
         }
      }
      @property column_count {
        [[The number of columns in the grid. This is calculated from the other values and cannot
          be set directly.
          see @.visible_rows @.item_size
          see @Efl.Container.content_count]]
        get{}
        values {
            count: int; [[The number of columns.]]
         }
      }

PLEASE DOUBLE-CHECK THAT I UNDERSTOOD THINGS CORRECTLY!

segfaultxavi requested changes to this revision.Jan 24 2019, 4:48 AM
This revision now requires changes to proceed.Jan 24 2019, 4:48 AM
SanghyeonLee added a comment.EditedJan 24 2019, 6:03 PM

I have a few comments:

  • partition seems a bit unclear to me, I would call it visible_rows and visible_columns.

I've searched term to explain this features... with some candidate... divider, division, visible_count, ....
but the partition is the only term that show the exactly how it is need to be work in google search result, and visible_count is hardly explain 2-demension way,
so I decided using partition as for this feature.
if you don't like this, we can vote about the term and I fallow the result :)

  • There's a lot of inconsistency among the properties: item_size is an Eina.Size2D, count is two separate ints (row_count and column_count), and partition can be accessed through 3 different properties. I would remove partition_set.

well that is why I hope we have Eina.Table2D for row and column and some Eina.Double2D which have double 2 demension value....but we don't have, and it is not a good time to ush this kind of structure, so I have no choice to expose the int.
I think... it is clearly better to provide some API to set both value in one single function calls... but like I said, we cannot provide some nice structure for this, so I.. think it would better to not expose partition_set at this moment and apply it when the base structure is ready. so.. I'll remove partition_set at this moment. thanks!

So, in summary, I suggest (with amended documentation):

{
   [[Simple grid widget with a Linear Pack interface. All items in the grid have the same size,
     which can be controlled by setting each item's size with @.item_size or by setting
     the amount of visible items in each row and column with @.visible_rows and @.visible_columns.
     When both are given, the last one to be set is respected.
     The linear packing implies that items are added to the grid as if it was a list, and the widget
     takes care of arranging the items in a 2D fashion.
   ]]
   methods {
     @property item_size {
         [[Size of each item in the grid.
           The individual min/max size of each item will be respected.
           If either the width or the height is $0, the value calculated from @.visible_rows or
           @.visible_columns will be used.]]
         values {
            size: Eina.Size2D; [[Size of item on the grid.]]
         }
      }
      @property visible_rows {
        [[The amount of visible rows in the grid (or the amount of items per column).
          The resulting number of columns is calculated when this value is set, and can be retrieved
          with @.column_count.]]
         values {
            rows: double; [[Amount of visible rows.]]
         }
      }
      @property visible_columns {
        [[The amount of visible columns in the grid (or the amount of items per row).
          The resulting number of rows is calculated when this value is set, and can be retrieved
          with @.row_count.]]
         values {
            columns: double; [[Amount of visible columns.]]
         }
      }
      @property row_count {
        [[The number of rows in the grid. This is calculated from the other values and cannot
          be set directly.
          see @.visible_columns @.item_size
          see @Efl.Container.content_count]]
        get{}
        values {
            count: int; [[The number of rows.]]
         }
      }
      @property column_count {
        [[The number of columns in the grid. This is calculated from the other values and cannot
          be set directly.
          see @.visible_rows @.item_size
          see @Efl.Container.content_count]]
        get{}
        values {
            count: int; [[The number of columns.]]
         }
      }

PLEASE DOUBLE-CHECK THAT I UNDERSTOOD THINGS CORRECTLY!

so I think here is some misunderstanding about the count....
the count is actual count of rows and columns... which is not the same meaning of partition (or visible rows and cols)
cause it is scrollable widget.
non-scrollable axis, count and partition will be same (almost... cause partition is double and allow some floating value),
but scrollable axis, partition is only value to set how many item is visible in the viewport, so count is much bigger then this.

so I think your updated document we may need to remove
and can be retrieved with @.column_count.]]
and I warn that this is not same value as count...

other comment looks much better than I had... I'll update the comment:)
thanks.

Thanks @SanghyeonLee ! Now I have it much more clear.
I now also understand that the direction in which the grid grows is controlled by Efl.Ui.Direction, and not by partition_columns or partition_rows. In fact, once you have set the direction, only one partition is needed, and the other is useless, correct?
Then, why don't we just use one partition value?

  • If the direction is horizontal, partition controls the number of rows and matches row_count (except for the rounding).
  • If the direction is vertical, partition controls the number of columns and matches column_count (except for the rounding).

If you agree with this, make the changes in the code and I will then propose the docs.

SanghyeonLee added a comment.EditedJan 29 2019, 3:36 AM

Thanks @SanghyeonLee ! Now I have it much more clear.
I now also understand that the direction in which the grid grows is controlled by Efl.Ui.Direction, and not by partition_columns or partition_rows. In fact, once you have set the direction, only one partition is needed, and the other is useless, correct?
Then, why don't we just use one partition value?

  • If the direction is horizontal, partition controls the number of rows and matches row_count (except for the rounding).
  • If the direction is vertical, partition controls the number of columns and matches column_count (except for the rounding). If you agree with this, make the changes in the code and I will then propose the docs.

sorry for late answer.
I had fever in the weekend..

the partition will controls both side regardless of scrolling directions.

for examples,
in horizontal case,
let's viewport size is {1000, 1000} and
if user set the partition(4, 4)

item will have the size {250, 250} to show 4 by 4 items in the viewport.


(Grey part is viewport. and guessing every item have same size :p)

and if viewport is now resized {2000, 2000}
partition still 4*4, so item will be resized {500, 500}.
that is what I meant, relative size.
item size will be changed by their viewport size to maintain this partition.

see another examples,
if user set the partition(4.5, 4)

item will have the size {222, 250} to show 4 item in the column and 4 item and half of item show in the viewport.

if user set the partition(4, 4.5)
which is more complex case I think... currently we round down the floating values on non-scrollable axis,
so it would be same as,

but I think we could understand this floating value as kind of padding size, so give padding outside of items depending on widget's alignment.
This will be future work.

on vertical scroll,
it will be only changed x and y, others will be same.

anyway,
by telling this story, I can sure my previous document is not well explain the feature yet...
I will update docs with more explain about this features.
honestly, put some images may helpful to understand this API, but I'm not sure about that.

segfaultxavi added a comment.EditedJan 29 2019, 4:18 AM

Thanks a lot for your patience, @SanghyeonLee, and for a very clear explanation. With pictures!
Unfortunately, I do not think we can add pictures to the EO docs yet :)

I understand now that both partition_rows and partition_columns are needed.
My only comment now is that maybe row_count could be renamed total_row_count to make it clear that it includes the rows outside the viewport. What do you think?

Here is my suggestion now, feel free to modify and use it:

{
   [[Simple grid widget with a Linear Pack interface. All items in the grid have the same size,
     which can be controlled by setting each item's size with @.item_size or by setting
     the amount of visible items in each row and column with @.partition_rows and @.partition_columns.
     When both size and partition are given, the last one to be set is respected.
     The linear packing implies that items are added to the grid as if it was a list, and the widget
     takes care of arranging the items in a 2D fashion.
   ]]
   methods {
     @property item_size {
         [[Size of each item in the grid.
           The individual min/max size of each item will be respected.
           If either the width or the height is $0, the value calculated from @.partition_rows or
           @.partition_columns will be used.]]
         values {
            size: Eina.Size2D; [[Size of item on the grid.]]
         }
      }
      @property partition_rows {
        [[The amount of visible rows in the grid (or the amount of items per column).
          This affects the @.total_row_count and @.total_column_count.]]
         values {
            rows: double; [[Amount of visible rows.]]
         }
      }
      @property partition_columns {
        [[The amount of visible columns in the grid (or the amount of items per row).
          This affects the @.total_row_count and @.total_column_count.]]
         values {
            columns: double; [[Amount of visible columns.]]
         }
      }
      @property total_row_count {
        [[Total number of rows in the grid, including the ones currently not shown.
          This is calculated from the other values and cannot be set directly.
          When the widget's @.direction is @Efl.Ui.Direction.Horizontal, @.total_row_count
          will match @.partition_rows (after rounding).
          When the widget's @.direction is @Efl.Ui.Direction.Vertical, @.total_row_count
          will be big enough to contain all items (roughly @Efl.Container.content_count / @.partition_columns).]]
        get{}
        values {
            count: int; [[The number of rows.]]
         }
      }
      @property total_column_count {
        [[Total number of columns in the grid, including the ones currently not shown.
          This is calculated from the other values and cannot be set directly.
          When the widget's @.direction is @Efl.Ui.Direction.Vertical, @.total_column_count
          will match @.partition_columns (after rounding).
          When the widget's @.direction is @Efl.Ui.Direction.Horizontal, @.total_column_count
          will be big enough to contain all items (roughly @Efl.Container.content_count / @.partition_rows).]]
        get{}
        values {
            count: int; [[The number of columns.]]
         }
      }

Thanks a lot for your patience, @SanghyeonLee, and for a very clear explanation. With pictures!
Unfortunately, I do not think we can add pictures to the EO docs yet :)

I understand now that both partition_rows and partition_columns are needed.
My only comment now is that maybe row_count could be renamed total_row_count to make it clear that it includes the rows outside the viewport. What do you think?

I'm also worried about misunderstanding between partition and count... so I think that is good idea.

and... sorry to bothering you again..
but I'm not an native speaker so I cannot catch the subtle nuance..
partition..
after you understand what exactly this feature... is it good enough?

I may have another candidate... "square_set" or "squares_set"
which is refered here
http://bluecaret.com/blog/responsive-grid-of-squares

and googled grid squares, it may give almost similar result as partition does.
which one is proper?

one better idea that @smohanty suggested,

just call it "row" and "column".
easiest thing could be best option in some case.

row_set or rows_set
column_set or columns_set
row_column_set or rows_columns_set

(I usually prefer singular in API... but here I'm not sure)

there are still some confusing part exist..
in scrolling axis, is this value means total rows(columns) in the content or only rows(columns) in the viewport..
we may need to explain this on document and also as @segfaultxavi idea, put "total" prefix in the count, they might not be confusing these as much as I worried.

I am not a native English speaker either, do not worry :D

I would not use squares because the content might not be square, most probably it will be rectangles, or it could even be circles or whatever :)
Also, I would not use just row or column, because that is the most ambiguous of all options.

I think total_row_count and total_column_count are very clear, I would use these names for the total counts.
Regarding the number of visible rows and columns in the widget, partition is a bit ambiguous to me. If you do not like visible_row_count and visible_column_count, what about viewport_row_count and viewport_column_count?