Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. QML and Qt Quick
  4. Row height in TableView in qml-components
Forum Updated to NodeBB v4.3 + New Features

Row height in TableView in qml-components

Scheduled Pinned Locked Moved QML and Qt Quick
6 Posts 2 Posters 10.9k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • I Offline
    I Offline
    ittennull
    wrote on last edited by
    #1

    Hi
    I'm trying to make different heights for rows in TableView, but it seems now I can't change default cell height at all. It used to work earlier, it was not perfect but it worked. Now no matter what height I set in itemDelegate nothing changes, although setting height in rowDelegate helps. But in rowDelegate I don't have access to current displaying data and hence I can't not change height based on cell values in current row.
    Here is my simple code
    @import QtQuick 2.0
    import QtDesktop 1.0

    Rectangle {
    width: 360
    height: 360

    ListModel {
    id:listmodel
    ListElement{ myrole1: "value 1"; myrole2: "value 2"}
    ListElement{ myrole1: "value 3"; myrole2: "value 4"}
    }

    TableView
    {
    anchors.fill: parent

    TableColumn{ role: "myrole1" ; title: "Column 1" ; width:100}
    TableColumn{ role: "myrole2" ; title: "Column 2" ; width:200}
    model:listmodel

    itemDelegate: Text{

    height: 60 //!!! does not work
    text: itemValue
    }
    }
    }@

    In itemDelegate I'd like to write something like this
    @
    height: check_some_condition(itemValue) ? 50 : 100
    @

    Is it another regression or something crucial has changed and now there is another way to handle such cases?

    1 Reply Last reply
    0
    • J Offline
      J Offline
      Jens
      wrote on last edited by
      #2

      Yes. The problem was that the itemDelegate was not a good place to set height since you could get inconsistent delegate heights on the same row. You should be able to do this by creating a rowDelegate and set a row height on that instead.

      1 Reply Last reply
      0
      • I Offline
        I Offline
        ittennull
        wrote on last edited by
        #3

        Hi
        I see, but now I can not set row height based on cell height because I don't know cell height. Here is my delegate for a second cell of a TableView
        @Component
        {
        id: ruslistDelegate

        Column
        {
        id: column2
        Repeater
        {
        model: roleValue

        Text {text: "∙ " + modelData}
        

        }
        }
        }@

        There is no any indication of height in this code so I don't know what height to set in rowDelegate. And I don't want put here explicit height (because that way I'm more constrained moving to another platform or changing something) or try to calculate height in rowDelegate (because it duplicates code for height calculation and if I change cell delegate I have to remember to change rowDelegate as well).
        Moreover if I replace rowDelegate and calculate height there I'll loose ability to select items (highlighting), alternative background and so on, if I need to save them I'll need to copy from TableView the content of rowDelegate, but it is a copy-paste and if some day style is changed my table will look inconsistent
        Unless I'm overlooking some simple way to do what I need I think this change in TableView is a regression of flexibility. If there is a simple way please tell me
        It's always good when in case you need to change only one parameter - all you have to do is actually change this parameter preserving all other functionality and appearence

        1 Reply Last reply
        0
        • J Offline
          J Offline
          Jens
          wrote on last edited by
          #4

          I understand your point but there are some other important factors weighing in on the change.

          The primary cause was performance. With the old solution every single item delegate had to be queried for it's height on each row when instantiated. The row would then take the maximum height of all its children (because it could not assume that a row would have a uniform height, a single item cell could cause it to grow).

          In the end the resulting height was really the height of the tallest item, making the size hint of individual cells incorrect in many cases anyway. So conceptually a cell height should not be assumed to be the same as the row height.

          Most of the old itemview classes also have a setUniformRowHeight for similar reasons and it makes a massive difference there. Only after this change was I able to hit fluid 60 fps scrolling in my test cases and that to me is more important than the somewhat improved convenience this adds.

          What we could perhaps do instead is to investigate if there are other ways we could make setting the uniform row height more convenient from the cell delegate.

          1 Reply Last reply
          0
          • I Offline
            I Offline
            ittennull
            wrote on last edited by
            #5

            I see, after all it's all about performance again.
            For my app performance is nothing because my table usually has no more than 100 rows.
            Right now I ended up replacing the whole rowDelegate - now it renders all columns of the table by itself and itemDelegate is empty. I lost style because I can't even copy-paste it because StyleItem is undefined in my qml-files (and I don't know yet what to do about it). Although for my simple table it's not important, I can highlight selected rows by myself (of course it's extra-work but any way)
            Jens, where is the bug-tracker for qml-components? I have two bugs to report: one in TableView, seconds is for Buttons
            Jens, do you familiar with WPF and xaml? If you do, what do you think about it, does it influence somehow your work?

            1 Reply Last reply
            0
            • J Offline
              J Offline
              Jens
              wrote on last edited by
              #6

              Yes a hundred items should not stress things too much.

              We can in theory expose StyleItem in the API but I do not yet consider it public API as it is a bit too low level and requires too much knowledge about how styles work to be convenient. My leading principle so far is that if you want to style things, you will loose the native look and feel as to keep things consistent on all platforms. We can perhaps instead expose a StandardItemDelegate{} with a few extra properties to make common tweaks like text color and font easy while staying somewhat platform conformant.

              http://qt-project.org/wiki/QtDesktopComponents should contain a section on how to file bugs. Great if you do!

              As for WPF and XAML I will admit that my knowledge is limited as I have never worked on a full scale project using them. I tend to look at their API for inspiration and I sometimes get surprised by how similar those technologies are in principle. But my main inspiration is usage of Qt and QML itself. Are there particular aspects you are missing from these these technologies with regards to Qt Quick?

              1 Reply Last reply
              0

              • Login

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • Users
              • Groups
              • Search
              • Get Qt Extensions
              • Unsolved