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. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
