QGridLayout support

[kSkip]

It would very useful to have support for grid layouts in a view (e.g. as a HVGroup or GridGroup)

It would need only the dimensions and index location of the Items in the grid allowing for empty cells as well.

[corranwebster]

What is insufficient about VGrid groups?

Edit: I think I know the answer, but I am curious what you need.

[kSkip]

What I need is this (Which I achieved using a Custom Editor) After looking into the VGrid (which I did not know about) I was able to painfully produce Using

        VGrid(
            spring,
            Item('value1'),
            spring,
            Item('value1'),
            spring,
            Item('value1'),
            spring,
            Item('value1'),
            spring,
            columns=3
        )

The equivalent pyqt code

    layout.addWidget(widget, 0, 1)
    layout.addWidget(widget, 1, 0)
    layout.addWidget(widget, 2, 1)
    layout.addWidget(widget, 1, 2)

I believe this numerical indexing is much more intuitive for the developer as you are explicitly in control of the location rather than implicitly.

What do you think?

[rkern]

Consider using qt_binder to get this amount of fine control over your layout.

https://github.com/enthought/qt_binder/blob/master/examples/grid_layout.py

That kind of procedural numerical indexing is rather at odds with the declarative nature of Traits UI, so I don't think it's going to happen here. I don't find it particularly natural or intuitive, myself. It's certainly more compact when you have a sparse layout, but being compact doesn't necessarily move you towards API usability.

[corranwebster]

Given that VGrid can do what you want it to, even if it is perhaps not elegant, coupled with the fact that TraitsUI really has no notion of a backend-independent "layout" object (for better or worse), I don't think we're going to support coordinate assignment to grid locations. As Robert says, it sort of goes against the grain of the declarative design.

For this use case, i'd probably just go with a VGrid of Button traits, QtBinder, or, if I wanted something prettier for what is clearly a coordinate control UI, something based on Enable (eg. the Enable Compass is close to what you want: https://github.com/enthought/enable/blob/master/enable/compass.py)

Oh, and what i thought you'd be asking for was the ability to span cells in the Grid, which would be nice, and might actually be possible for column spans (if not row spans).

[kSkip]

@rkern Thanks for the tip. I'll look into using qt_binder.

However, I don't agree that declarative and explicit are mutually exclusive. For example,

view = View(
    Grid(
        GridItem('trait1', x=0, y=0),
        GridItem('trait2', x=0, y=2)
        grid_width=3,
        grid_height=4
    )
)

is both.

[rkern]

Sure, and as a code writer, I might like that if I have a particularly sparse grid.

As a code reader, I find it impenetrable. I have to "run code in my head" to get an idea of what that's going to look like. Even if I liked that when writing it, "six-month-later-me" who has to read it isn't. It's unavoidable when you have spans that need specifying, so qt_binder's SpanGridLayout looks like that.

Since the benefits on the writing side only seem to accrue for sparse layouts, which are relatively rare, I'm not inclined to pursue that route for the basic-case API.

[kSkip]

Thanks. Sounds good. I'll be looking into the SpanGridLayout

FTR, before this issue is closed.

This

        VGrid(
            spring,
            Item('value1'),
            spring,
            Item('value1'),
            spring,
            Item('value1'),
            spring,
            Item('value1'),
            spring,
            columns=3
        )

is absolutely unread-able for me and I also have to run the code in my head to see it.

[rkern]

Yup, that's why BasicGridLayout uses an explicit lists for each row.