Wt

Hey,

This is related to trying to resize the columns to 'fit' the available space ?

What you are trying is not working, and this is indeed not documented. The reason is that WTableView already has a custom resize handler, client-side, and therefore the one you install is being ignored. This is a bug which ought to be fixed.

It would be interesting though to know what you want to do and if this should not indeed be a standard feature of WTableView ? If you are trying to divide available width over columns, then do you have any preference on how this should be done and if and how this should work together with the manual resizing of a user of certain columns ?

Regards,

koen

Hi Koen,

this issue may be somewhat related to columns that fit the available space, in that I'm trying to make the table as a whole fit the available space. Is that possible?

I have a WTableView in a WContainerWidget which has a WGridLayout. Where other widgets fill up the entire space of their cell in the grid, the WTableView does not seem to do that. Is that correct?

The way I'm trying to use a WTableView may be different as intended. In fact, after thinking it over it seems I may be using it as a nice looking grid layout. I'm not using any manual resize features. I very well understand that those features conflict with my intended use.

What I want is a tabular view of data with column widths completely under control of the program (not the user), but filling the entire width of its cell. Perhaps I should take a different approach?

The layout manager I liked best of all (but I very well understand it is not feasible to have something like this in a browser) is a Java one, JGoodies Forms, see also http://www.jgoodies.com/freeware/forms/ It allows you to specify column widths in several forms, absolute or relative to each other. For (a simple) example, you could have three columns, one with a fixed width, and two others that divide the remaining space between them in the ratio 2 to 3.

By the way, one way of making a WTableView fit its cell may be to have another widget in the same column, which is layout size aware, report its width, which can then be used to set the WTableView width. Would that work?

Thanks. Arjan.

I have the very same issues and have tried to get some hints (http://redmine.emweb.be/boards/2/topics/2652 and http://redmine.emweb.be/boards/2/topics/2629).

Hey Arjan and Vincenzo,

Thanks for the clarifications. The reference to the Java widget is helpful, and such a degree of flexibility is not unthinkable for WTableView (especially since the API already would be able to handle this since we use WLength). The implementation of this feature can take some time. If you could post this as a feature request, then you can keep track of its implementation status.

Now, there also seems to be a bug which prevents you from implementing a workaround in the meantime, which is that layoutSizeChanged() is broken. I intend to fix this first. Again, if you will file this as a bug, then this will be fixed ASAP.

Would the workaround work for both of you as a short-time solution ?

Regards,

koen

Koen Deforche wrote:

Now, there also seems to be a bug which prevents you from implementing a workaround in the meantime, which is that layoutSizeChanged() is broken. I intend to fix this first. Again, if you will file this as a bug, then this will be fixed ASAP.

I still need to study this thing as I'm somehow new to Wt.

Some more details or maybe a few code snippets would help me greatly.

Would the workaround work for both of you as a short-time solution ?

In general, as a developer, I hate workarounds.

As far as I've understood, this workaround would be limited at the layout construction.

If this is the case I would then agree for a short-term solution.

Regards,

koen

Hey Vincenzo,

you simply make a widget layout-size-aware, which means that whenever its layout size changes (e.g. the user resized his browser window), its layoutSizeChanged() method is called.

This would allow you to resize the columns based on your own logic so that the total width of all columns fits in the given layout size.

In other words, it allows you to implement the functionality you look for (ASFAIK), server-side. It is not limited to layout construction, but it would only apply to cases where the tableview is managed by a layout manager (although that is also the only way to have a tableview adapt its size dynamically).

Regards,

koen

Thanks for the clarifications. The reference to the Java widget is helpful, and such a degree of flexibility is not unthinkable for WTableView (especially since the API already would be able to handle this since we use WLength).

To me that seems a very ambitious plan. But if you think you can pull it of, please do so!

Perhaps it's worthwhile to think things over carefully before proceeding on this path. For example, Wt has layout managers, does it make sense to implement some of JGoodies functionality into one or more of them?

The implementation of this feature can take some time. If you could post this as a feature request, then you can keep track of its implementation status.

I added this request, see http://redmine.emweb.be/issues/963

Now, there also seems to be a bug which prevents you from implementing a workaround in the meantime, which is that layoutSizeChanged() is broken. I intend to fix this first. Again, if you will file this as a bug, then this will be fixed ASAP.

I added an issue, see http://redmine.emweb.be/issues/962

Would the workaround work for both of you as a short-time solution ?

I would be very much helped if layoutSizeChanged() would work.

Thanks a lot. Arjan.

Hey Arjan,

Actually, it seems that #962 has already been fixed in Wt's git repo (it had to do with composite widget's behaviour w.r.t. layoutSizeChanged()).

Could you confirm ?

Regards,

koen

It works! Great!

Also nice: not a single warning comes out during compilation of wt itself. I only needed to recompile my application and all was set to go. Great job.

Now I'll try to adapt the column widths to the width of the WTableView, I'll keep you informed.

Arjan.

As a first test I tried to equally divide all available space among all columns. Just dividing by the number of columns yields columns that are too wide. From the code, e.g. the void WTableView::updateColumnOffsets() method, I concluded I need subtract 7 from each columns width. Then my table was still a bit too wide, after some trial and error I found I have to subtract 3 from the total width:

void MyWTableView::layoutSizeChanged (const int width, const int height)
{
  for (int column = 0; (column < this->_wStandardItemModel->columnCount ()); column++) {
    setColumnWidth (column, Wt::WLength ((((width - 3) / this->_wStandardItemModel->columnCount ()) - 7), Wt::WLength::Pixel));
  }
}

But then it looks perfect! (I have tables with 2, 3, and 5 columns.)

I would like to know where the 3 comes from. Is it some margin? Can I query some object for it?

Arjan.

After careful observation I conclude that the 3 that I have to subtract from the total width, is actually a 5.

Can it be that the header of the last column in a WTableView is actually one pixel short? It is as if the gray gap between the header cells is repeated after the last column, see attached screen shot.

Hey Arjan,

The '7' is documented in WAbstractItemView. It is a misfeature that grew historically... Luckily it is a divine number.

As to why there are an additional 5, I believe you might be right about the last column. I will investigate. But we will probably be ending up documenting this as well (until we ever decide to break WTableView).

Regards,

koen

Okay, found the 7!

Still, would it be an idea to add a method that returns the 7? Then my code can query that method instead of hard-coding the 7 and you will have a good placeholder for documentation.

Same for the magical 5!

Cheers, Arjan.

Hello,

I'm getting the same issue, and I hopefully found this topic/

I'm using WTableViews with a GridLayout.

A very interesting feature would be to set some columns to have a "floating" width.

=> The remaining space would be divided between these columns.

What do you think?

Regards,