wxDataViewCtrl problems (mostly having to do with column widths)

[Stefano Antonelli]

Hello,

I've been playing with wxDataViewCtrl and have noticed some problems.
This is with wxWidgets 2.9.5 on Ubuntu 10.04 (gtk 2.10.0 I believe).
Looking for some advice. Please let me know if I should be posting this
to another list.

__Initial Column Width__

wxCOL_WIDTH_AUTOSIZE provides a decent starting point for the column
width (sized to the header text), but it prevents further resizing. I
thought perhaps that I could set wxCOL_WIDTH_AUTOSIZE initially and then
later set the width to the current width with
wxDataViewColumn::SetWidth(). This does change the width, but it seems
as though the autosize style is still applied (can't grab the header
separator).

Is there any way to provide an initial size to the header that
automatically fits at least the header? Better yet, if there is data in
the model when the app starts, is it possible to size the columns to the
data? Or can the autosize "style" be disabled some time after the
autosize has completed?

__Double clicking the header separator__

I expect that double clicking the header separator would either:

a) resize to fit the header text or
b) resize to fit the contents of the visible rows

It does neither. Instead it appears to return to the initial size. You
can see this by changing the initial size of the "editable string"
column in the wxDataViewCtrl sample (dataview.cpp) from
wxCOL_WIDTH_AUTOSIZE to a value of 195. In this case, you can shrink
the header size down to some minimum size (that fits the header text and
no smaller), but if you double click the header separator from this
width, it will return to the initial size.

In Nautilus (list mode), double clicking the header separator of the
Name column sizes to some minimum size (looks like the initial size).
The Type column sizes to contents. I mention Nautilus because I believe
it is using the same native control.

In general I would expect that a double click on the header separator
would size to fit the "cell" contents or the header text, whichever
happens to be wider. Any advice on how to achieve this?

There is an additional strange behaviour if you set the size to
something smaller than the header text's width. You can see this by
setting the "editable string" column to an initial width of 20. Double
clicking the header separator does nothing initially (the current
behaviour is to return to initial size). If you pull the header
separator to the left, it does not get any smaller. Instead it grows to
fit the text in the header and can no longer be sized smaller. I guess
that this has somehow confuses the native control and it's not happy to
resize the header unless it's width is greater than or equal to some
minimum width. Though that begs the question of why we can set it that
small in the first place?

It would seem from playing with Nautilus in List mode that gtk does not
allow the header to shrink (by dragging the header separator) smaller
than the text in the heading. Any idea why? Is this a limitation of
gtk or just a matter of setting some extra flags? Seems like an
unnecessary limitation. As a user, I may want to shrink the other
columns down to almost nothing so that I can give the most room to the
column(s) of interest.

__Column stretching__

In the sample, the last column stretches when the window is resized.
However, in Nautilus list view, the first column stretches. Is there a
way to pick an arbitrary column as the stretch column?

__Rubber band selection__

As far as I know, this is not supported by the native control (ie. it
frustrates me in Nautilus list view). Is it possible to fake it?

__Generic wxDataViewCtrl__

Is it possible to use the generic version of this control on gtk? I
found references to wxHAS_GENERIC_DATAVIEWCTRL, but where do I specify
this? Would it even work?

Thanks,
Stef

[Vadim Zeitlin]

On Thu, 15 Aug 2013 02:31:18 -0700 Stefano Antonelli wrote:

SA> I've been playing with wxDataViewCtrl and have noticed some problems.
SA> This is with wxWidgets 2.9.5 on Ubuntu 10.04 (gtk 2.10.0 I believe).
SA> Looking for some advice. Please let me know if I should be posting this
SA> to another list.

Hello,

This list is fine but you may want to open tickets on our Trac for the
issues you encountered to ensure that they don't get lost. Please search
for the existing issues first if you do this though as I think that some of
the problems below may have been already reported.


SA> __Initial Column Width__
SA>
SA> wxCOL_WIDTH_AUTOSIZE provides a decent starting point for the column
SA> width (sized to the header text), but it prevents further resizing.

Yes, unfortunately this is how gtk_tree_view_column_set_sizing() behaves
when called with GTK_TREE_VIEW_COLUMN_AUTOSIZE argument. Apparently we
could still call gtk_tree_view_column_set_resizable(TRUE) in addition and
this would change the grow mode to GTK_TREE_VIEW_COLUMN_GROW_ONLY under the
hood but I didn't test what does this give in practice yet.

SA> Is there any way to provide an initial size to the header that
SA> automatically fits at least the header? Better yet, if there is data
SA> in the model when the app starts, is it possible to size the columns to
SA> the data? Or can the autosize "style" be disabled some time after the
SA> autosize has completed?

You should be able to work around this by using SetWidth() with something
different from wxCOL_WIDTH_AUTOSIZE and, maybe, SetResizeable(true). But
the real solution must be implemented inside wxGTK itself. If anybody has
time to do it, it would be great.

For the reference, we have GetBestColumnWidth() method in the generic
wxDataViewCtrl which could be reused to compute the best column width if we
decide that we need to do it ourselves because GTK+ behaviour is not
useful.


SA> __Double clicking the header separator__
SA>
SA> I expect that double clicking the header separator would either:
SA>
SA> a) resize to fit the header text or
SA> b) resize to fit the contents of the visible rows

This is definitely the native behaviour under Windows but I don't know
about Linux/GTK. The GNOME HIG doesn't say anything about this so I guess
copying Nautilus is going to be about the best thing we can do...

SA> In general I would expect that a double click on the header separator
SA> would size to fit the "cell" contents or the header text, whichever
SA> happens to be wider. Any advice on how to achieve this?

Unfortunately currently you can't as we don't even send any events when
double clicking on a separator line. It would be nice to have an equivalent
to the generic wxEVT_HEADER_SEPARATOR_DCLICK event in wxDataViewCtrl but
we'd need to check whether the native GTK+ and OS X versions are even
capable of generating it in the first place.

SA> It would seem from playing with Nautilus in List mode that gtk does not
SA> allow the header to shrink (by dragging the header separator) smaller
SA> than the text in the heading. Any idea why? Is this a limitation of
SA> gtk or just a matter of setting some extra flags?

Looks like example of the GTK_TREE_VIEW_COLUMN_GROW_ONLY mode mentioned
above... But I don't really know.


SA> __Column stretching__
SA>
SA> In the sample, the last column stretches when the window is resized.
SA> However, in Nautilus list view, the first column stretches. Is there a
SA> way to pick an arbitrary column as the stretch column?

I don't think so. Besides, this functionality is specific to GTK+ only. In
portable code you'd want to handle wxEVT_SIZE and resize the columns
manually.


SA> __Rubber band selection__
SA>
SA> As far as I know, this is not supported by the native control (ie. it
SA> frustrates me in Nautilus list view). Is it possible to fake it?

This isn't going to be simple.


SA> __Generic wxDataViewCtrl__
SA>
SA> Is it possible to use the generic version of this control on gtk? I
SA> found references to wxHAS_GENERIC_DATAVIEWCTRL, but where do I specify
SA> this?

You need to define this before including wx/dataview.h so the safest way
to do it is to add /DwxHAS_GENERIC_DATAVIEWCTRL to your compiler options in
the make/project file. *And* you also need to specify it when building
wxWidgets itself.

SA> Would it even work?

It should. But it would definitely look worse in GTK+ environment than the
native control.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Stefano Antonelli]

Hi Vadim,

On Fri, 2013-08-16 at 12:32 +0200, Vadim Zeitlin wrote:
> On Thu, 15 Aug 2013 02:31:18 -0700 Stefano Antonelli wrote:
>
> SA> I've been playing with wxDataViewCtrl and have noticed some problems.
> SA> This is with wxWidgets 2.9.5 on Ubuntu 10.04 (gtk 2.10.0 I believe).
> SA> Looking for some advice. Please let me know if I should be posting this
> SA> to another list.
>
> Hello,
>
> This list is fine but you may want to open tickets on our Trac for the
> issues you encountered to ensure that they don't get lost. Please search
> for the existing issues first if you do this though as I think that some of
> the problems below may have been already reported.

I'm not quite sure there is anything to report...

> SA> __Initial Column Width__
> SA>
> SA> wxCOL_WIDTH_AUTOSIZE provides a decent starting point for the column
> SA> width (sized to the header text), but it prevents further resizing.
>
> Yes, unfortunately this is how gtk_tree_view_column_set_sizing() behaves
> when called with GTK_TREE_VIEW_COLUMN_AUTOSIZE argument. Apparently we
> could still call gtk_tree_view_column_set_resizable(TRUE) in addition and
> this would change the grow mode to GTK_TREE_VIEW_COLUMN_GROW_ONLY under the
> hood but I didn't test what does this give in practice yet.

This is a good hint for a work around.

> SA> Is there any way to provide an initial size to the header that
> SA> automatically fits at least the header? Better yet, if there is data
> SA> in the model when the app starts, is it possible to size the columns to
> SA> the data? Or can the autosize "style" be disabled some time after the
> SA> autosize has completed?
>
> You should be able to work around this by using SetWidth() with something
> different from wxCOL_WIDTH_AUTOSIZE and, maybe, SetResizeable(true). But
> the real solution must be implemented inside wxGTK itself. If anybody has
> time to do it, it would be great.

How would it be implemented within wxGTK? As I discovered trying to
work around it, autosize doesn't have any effect until the model has
been associated with the dataview and at least header strings are
populated. Unless there is some way to receive notification that the
column has been autosized? That would need to come from GtkTreeView,
but I don't see anything in the docs about such a signal.

The work around:

After I added all my columns with wxCOL_WIDTH_AUTOSIZE (and after the
model was associated), I was able to:

int i;
for(i = 0; i < m_dataview->GetColumnCount(); i++)
{
m_dataview->GetColumn(i)->SetResizeable(true);
}

This had the desired effect of giving a reasonable starting point that I
could still resize after.

> For the reference, we have GetBestColumnWidth() method in the generic
> wxDataViewCtrl which could be reused to compute the best column width if we
> decide that we need to do it ourselves because GTK+ behaviour is not
> useful.

Probably not required. Simply making the column autosize followed by
setting it resizeable seems to work. The problem is, there's no event
to fire off of (such as double clicking the header separator).

> SA> __Double clicking the header separator__
> SA>
> SA> I expect that double clicking the header separator would either:
> SA>
> SA> a) resize to fit the header text or
> SA> b) resize to fit the contents of the visible rows
>
> This is definitely the native behaviour under Windows but I don't know
> about Linux/GTK. The GNOME HIG doesn't say anything about this so I guess
> copying Nautilus is going to be about the best thing we can do...
>

>From the gtk docs:
Please note that GTK_TREE_VIEW_COLUMN_AUTOSIZE are inefficient for large
views, and can make columns appear choppy.

This would imply that it's trying to fit the width of the column
contents. Which I can see happens in Nautilus's Type column. However,
I did grep the nautilus sources for GTK_TREE_VIEW_COLUMN_AUTOSIZE and
there is no mention of it. So I'm not sure how they are achieving this
behaviour. And why it only works "properly" for the Type column is a
bit of a mystery.

> SA> In general I would expect that a double click on the header separator
> SA> would size to fit the "cell" contents or the header text, whichever
> SA> happens to be wider. Any advice on how to achieve this?
>
> Unfortunately currently you can't as we don't even send any events when
> double clicking on a separator line. It would be nice to have an equivalent
> to the generic wxEVT_HEADER_SEPARATOR_DCLICK event in wxDataViewCtrl but
> we'd need to check whether the native GTK+ and OS X versions are even
> capable of generating it in the first place.

Right, after looking at the gtk docs I don't think GtkTreeView has any
signals for this. But I'm not familiar with gtk at all so it probably
doesn't mean anything.

>
> SA> It would seem from playing with Nautilus in List mode that gtk does not
> SA> allow the header to shrink (by dragging the header separator) smaller
> SA> than the text in the heading. Any idea why? Is this a limitation of
> SA> gtk or just a matter of setting some extra flags?
>
> Looks like example of the GTK_TREE_VIEW_COLUMN_GROW_ONLY mode mentioned
> above... But I don't really know.

I think you're right - native widget limitation. Seems like an
unnecessary restriction...

> SA> __Column stretching__
> SA>
> SA> In the sample, the last column stretches when the window is resized.
> SA> However, in Nautilus list view, the first column stretches. Is there a
> SA> way to pick an arbitrary column as the stretch column?
>
> I don't think so. Besides, this functionality is specific to GTK+ only. In
> portable code you'd want to handle wxEVT_SIZE and resize the columns
> manually.

Do you think it would be feasible to put that logic in wxdataviewctrl
(or subclass) instead of in the app? Is there a way for wxdataviewctrl
to get information about the clipping area around it?

Thanks,
Stef