Fl_Table default row height and column widths

[Rob McDonald]

The Fl_Table default row height and column widths are hard-coded to 25 and 80 respectively on lines 690 and 718.

The code will try to use the size of the last row/column if it exists, but for an empty table, it goes to the default.

Should this be a settable value?  I'm working with a dynamic table (initially empty) and it took me a while to figure out why my row height settings weren't having any effect (they preceded setting the table size).

Rob

[Greg Ercolano]

On 6/13/24 16:01, Rob McDonald wrote:

The Fl_Table default row height and column widths are hard-coded to 25 and 80 respectively on lines 690 and 718.

The code will try to use the size of the last row/column if it exists, but for an empty table, it goes to the default.

    Yes, I believe the examples/table-simple.cxx shows that after setting the number of rows(), one follows up with calling row_height_all(new_height).

    Or one has the option to set the row heights individually with row_height(row, new_height).

    (Ditto for cols() using col_width_all(new_width) and col_width(col,new_width))

Should this be a settable value?
I'm working with a dynamic table (initially empty) and it took me a while to figure out why my row height settings weren't having any effect (they preceded setting the table size).

    I'd be for it, if it didn't mean making even more method names to get/set the default height/width.

    If it weren't for backwards compatibility, it'd have probably been cleanest to have rows() and cols() accept optional arguments for initial height and width, e.g.

        virtual void rows(int new_rows, int new_height=25);
        virtual void cols(int new_cols, int new_width=80);

    That doesn't exist now, but if that could be changed without breaking API and old applications that already reimplement the existing simpler rows(int)/cols(int) methods, I'd be up for that. Pretty sure adding optional arguments to those virtuals would break API, though, unless there's tricks I can't think of offhand. (*)

    We could maybe work around by making additional virtual rows() and cols() methods that have those extra arguments, e.g. for rows:

        int rows() const;                                // return #rows
        virtual void rows(int new_rows);                 // set #rows
        virtual void rows(int new_rows, int new_height); // NEW METHOD: set rows and their default heights

    I imagine that preserves backwards compatibility and avoids API breakage, while appearing to the user to be optional arguments. It might have other implications though for existing classes that reimplement from Fl_Table that don't reimplement those methods.

    This would probably be better than adding new row_height_default() and col_height_default()..?




(*) Even though I designed some of the more complicated widgets (Fl_Table, Fl_Tree, and Fl_Terminal), forward planning API design is actually not my specialty. I'm good at solving problems, but C++ API design.. meh. So heaven help us all, lol. I fear there just have never been enough dev resources to do careful peer review of my widget APIs, which tend to be large and perhaps somewhat intimidating.