Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Component/s: wtk
    • Labels:
      None

      Description

      GridView would be a data-driven component like ListView or TableView, but would arrange items in a 2-dimensional grid instead of in rows (similar to "icon view" in Windows Explorer or Mac OS X Finder). It would provide an orientation property that would dictate which way items would be laid out: a horizontal grid view would arrange items left to right, and a vertical grid view would arrange them top to bottom.

      GridView would assume a fixed renderer size, and would report preferred size based on orientation: e.g. the preferred size of a horizontal grid view would be (n * renderer width) x (renderer height). Constraining the preferred width of a horizontal grid view would cause the items to wrap at the end of each row; constraining the preferred height of a grid view would cause items to wrap at the end of each column.

      1. GridView.patch
        114 kB
        Edvin Syse
      2. grid_view_component_explorer.png
        38 kB
        Chris Bartlett
      3. grid_view_component_explorer.patch
        4 kB
        Chris Bartlett

        Issue Links

          Activity

          Gavin made changes -
          Link This issue is depended upon by PIVOT-219 [ PIVOT-219 ]
          Gavin made changes -
          Link This issue blocks PIVOT-219 [ PIVOT-219 ]
          Roger Whitcomb made changes -
          Assignee Edvin Syse [ edvin ]
          Edvin Syse made changes -
          Attachment GridView.patch [ 12490269 ]
          Edvin Syse made changes -
          Attachment GridView.patch [ 12490291 ]
          Hide
          Edvin Syse added a comment -

          New version that fixes:

          • Changes to the 'horizontalSpacing' and 'verticalSpacing' styles now invalidate the component
          • Pressing the DOWN arrow behaves correctly when there is no item below the selection
          • Expanding selection in MULTI mode now behaves as close to other similar components as possible

          The way components are selected in MULTI mode is a bit wierd across Pivot components, but for the time being it's probably best to keep them aligned atleast.

          Show
          Edvin Syse added a comment - New version that fixes: Changes to the 'horizontalSpacing' and 'verticalSpacing' styles now invalidate the component Pressing the DOWN arrow behaves correctly when there is no item below the selection Expanding selection in MULTI mode now behaves as close to other similar components as possible The way components are selected in MULTI mode is a bit wierd across Pivot components, but for the time being it's probably best to keep them aligned atleast.
          Chris Bartlett made changes -
          Comment [ The current patch contains an easily fixed error on lines 1606 & 1607

           Replace
           <bad>
           -import org.apache.pivot.wtk.
           ;
           </bad>

           with
           <good>
           -import org.apache.pivot.wtk.ListView;
           </good> ]
          Edvin Syse made changes -
          Attachment GridView.patch [ 12486356 ]
          Edvin Syse made changes -
          Attachment GridView.patch [ 12490269 ]
          Hide
          Edvin Syse added a comment -

          New version that fixes:

          • Import error in last patch
          • Arrow keys for navigation (up, down, left, right)
          • Removed 'alternateItemBackgroundColor' - makes no sense
          • Fixed padding related errors for hover, selection and layout
          • Added context menu to remove selected item, or add more items at random locations, to show update functionality
          Show
          Edvin Syse added a comment - New version that fixes: Import error in last patch Arrow keys for navigation (up, down, left, right) Removed 'alternateItemBackgroundColor' - makes no sense Fixed padding related errors for hover, selection and layout Added context menu to remove selected item, or add more items at random locations, to show update functionality
          Chris Bartlett made changes -
          Attachment grid_view_component_explorer.png [ 12489997 ]
          Attachment grid_view_component_explorer.patch [ 12489998 ]
          Hide
          Chris Bartlett added a comment -

          Patch to add a Grids -> GridView node to the ComponentExplorer tool which will aid interactive testing of the proposed GridView component

          Works with the corrected version of Edvin's initial GridView patch

          Show
          Chris Bartlett added a comment - Patch to add a Grids -> GridView node to the ComponentExplorer tool which will aid interactive testing of the proposed GridView component Works with the corrected version of Edvin's initial GridView patch
          Edvin Syse made changes -
          Attachment GridView.patch [ 12486356 ]
          Edvin Syse made changes -
          Attachment GridView.patch [ 12486355 ]
          Edvin Syse made changes -
          Attachment GridView.patch [ 12486355 ]
          Hide
          Edvin Syse added a comment -

          Path to add GridView with a Terra skin and a test.

          Show
          Edvin Syse added a comment - Path to add GridView with a Terra skin and a test.
          Greg Brown made changes -
          Fix Version/s 2.1 [ 12314825 ]
          Fix Version/s 1.5 [ 12314033 ]
          Hide
          Todd Volkert added a comment -

          Flex calls it a TileList. Borrowing from that theme of ideas, we could also consider TileView, which would be more consistent with our naming conventions...

          Show
          Todd Volkert added a comment - Flex calls it a TileList. Borrowing from that theme of ideas, we could also consider TileView, which would be more consistent with our naming conventions...
          Hide
          Greg Brown added a comment -

          I think BoxView would be misleading. BoxViews don't wrap, whereas this container would. GridView is appropriate because this component will arrange the items in a grid. It is similar to GridPane in that all of the cells will be the same size.

          The orientation simply defines the direction of the flow (left to right or top to bottom). It establishes which axis defines the "break" - a horizontal grid pane will break on the x-axis, and a vertical grid pane will break on the y-axis.

          I agree that an unconstrained GridPane would behave like a BoxPane with fill set to true. But then, so does a TableView with only one row or column. An constrained FlowPane (which does not align to baseline) behaves like a horizontal BoxPane with fill set to false and vertical alignment set to BOTTOM. So we have some overlap in our container behavior, but this is OK, because each of these containers is capable of doing at least one thing that the others can't.

          Show
          Greg Brown added a comment - I think BoxView would be misleading. BoxViews don't wrap, whereas this container would. GridView is appropriate because this component will arrange the items in a grid. It is similar to GridPane in that all of the cells will be the same size. The orientation simply defines the direction of the flow (left to right or top to bottom). It establishes which axis defines the "break" - a horizontal grid pane will break on the x-axis, and a vertical grid pane will break on the y-axis. I agree that an unconstrained GridPane would behave like a BoxPane with fill set to true. But then, so does a TableView with only one row or column. An constrained FlowPane (which does not align to baseline) behaves like a horizontal BoxPane with fill set to false and vertical alignment set to BOTTOM. So we have some overlap in our container behavior, but this is OK, because each of these containers is capable of doing at least one thing that the others can't.
          Hide
          Noel Grandin added a comment -

          I think part of my confusion is the naming - what you're describing here I would want to call a BoxView, since that is the container with the closest semantics.
          A GridView is a grid - it has rows and columns, doesn't have an orientation, you have to specify every single cell explicitly.

          If what you want is parity with the containers, then maybe we should create:

          (1) GridView - acts like the new GridPane.

          (2) BoxView - acts like BoxPane, the closest thing to what you're describing here.

          Show
          Noel Grandin added a comment - I think part of my confusion is the naming - what you're describing here I would want to call a BoxView, since that is the container with the closest semantics. A GridView is a grid - it has rows and columns, doesn't have an orientation, you have to specify every single cell explicitly. If what you want is parity with the containers, then maybe we should create: (1) GridView - acts like the new GridPane. (2) BoxView - acts like BoxPane, the closest thing to what you're describing here.
          Hide
          Greg Brown added a comment -

          That was actually the original idea. However, I think it will be simpler to implement as a separate component. It will also have parity with the planned GridPane class.

          We have overlap in other places in the API as well. ListView and TableView are also conceptually similar, but we implemented them as individual components for the sake of clarity and simplicity. BoxPane and FlowPane are similar (and even TablePane shares some features in common), but it would complicate the implementations of all of them to attempt to get everything into one class. So I think a dedicated GridView is the better alternative.

          Show
          Greg Brown added a comment - That was actually the original idea. However, I think it will be simpler to implement as a separate component. It will also have parity with the planned GridPane class. We have overlap in other places in the API as well. ListView and TableView are also conceptually similar, but we implemented them as individual components for the sake of clarity and simplicity. BoxPane and FlowPane are similar (and even TablePane shares some features in common), but it would complicate the implementations of all of them to attempt to get everything into one class. So I think a dedicated GridView is the better alternative.
          Hide
          Noel Grandin added a comment -

          It seems like the only real different between this and ListView is that
          (a) it can wrap like FlowPane
          (b) it has an orientation property.

          Given that all of the other logic (selection, editing, etc.) is shared with ListView, perhaps we implement this by adding wrapping and orientation styles to TerraListViewSkin?

          Show
          Noel Grandin added a comment - It seems like the only real different between this and ListView is that (a) it can wrap like FlowPane (b) it has an orientation property. Given that all of the other logic (selection, editing, etc.) is shared with ListView, perhaps we implement this by adding wrapping and orientation styles to TerraListViewSkin?
          Greg Brown made changes -
          Link This issue blocks PIVOT-219 [ PIVOT-219 ]
          Greg Brown made changes -
          Field Original Value New Value
          Summary Create a GridView component Add a GridView component
          Greg Brown created issue -

            People

            • Assignee:
              Edvin Syse
              Reporter:
              Greg Brown
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development