Unsolved mystery - How to control GtkTreeView row height



Hello,

I need a way to control the rendered row height, in pixels,
of a GtkTreeView. This is essential to the application, because
I *cannot* use scrolling, but instead use a virtual grid mechanism
that loads a GtkTreeView with a small number of rows from a
larger virtual table, and control all scrolling by keystroke handling
of up arrow, down arrow, pageup, pagedn, etc.

BTW, we are talking GtkTreeView in single-row tables just like straight
database tables, no tree-structure here.

This is necessary because the virtual table is loaded from a
database table, and the returned number of records in that table is
unpredictable and can be very large, making the use of an arbitrary
GtkTreeView grid impossible.

This works perfectly as long as I can control, or at least predict,
the row height - because I load the "visible" GtkTreeView with an
exact numbr of rows to calculate which row we are currently on.

However, on some systems, the displayed row height changes to various
values, depending on some mysterious setting, and hence some
portion of the grid remains blank !

Note: This is OK as long as the blank portion is not "too" large, but
no good if the rows turn out to be too high - in those cases, the
row marker (highlight) partially vanishes into the end of the grid.

All in all, this is a totally undesirable display feature.

I assume that this is part of the current "theme", but when I checked the
methods of controlling the theme by using rc files and special parameter
syntax, I found that row height, and hence fitting the rows integrally
into a certain grid height, *cannot* be controlled by this method, because
the GtkTreeView apparently calculates the row height as needed, just
before "rendering" or "realizing" the grid (??).

Note: the "set_fixed_size()" function of GtkCellRenderer does *not* even
come close - the results are unpredictable and having little to do with
exact pixel height, rather they seem to affect the font height only, and
this cannot be controlled because it depends on the font at the time.

Note: Using set_fixed_row_height() for GtkTreeView makes no difference
either - and besides, we cannot use this because it forces us to use fixed-width
columns, which we want to keep resizeable for our users.

So, we are left with the problem of predicting or controlling the resulting
row height by choosing the current gtk theme, or using some method
that I cannot find yet. Themes cannot control the row height either, so
we are back to square one.

This requirement would seem absolutely essential in a commercial
application, for the simple reason that we were forced to write, and
anybody in the same situation is also forced to write, their own
"virtual grid" mechanism, since there is no such thing as a fixed
size grid with keyboard navigation control - only a "windowsy" style
mouse-scrolling grid which must contain *all* the records, which is
totally unsuitable for commercial use, and always was.

This is the last great unsolved GTK+ layout problem - all other functions
of GTK+ have worked magnificently for us, and have allowed us to create an
application that can be used on any unix or, God forbid, windows system
that has a functioning GTK+ library installed, without changing code.

Can anyone identify with this most obvious problem, and suggest a
solution to the developers?

Remember: all gtk code has been tried, and all doc and forums have been
searched unsuccessfully for a solution, for the past 2 years. It is time to put
our minds to fixing this universal problem of fixed-height grids, so that
commercially oriented applications can use GTK+.

Thanks,
Anthony E. Rich.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]