Fewer columns should be visible by default

[jdaguil]

We are showing too many columns in the table view by default.

[mjherzog]

We need to enhance the Column Visibility options in the Table View. Some ideas:

1. Create an "Info set" option like "License Info" for each Model - currently missing Package and ?
2. Add a Fileinfo Info set - not sure that Fileinfo corresponds to a specific Model.
3. Define a minimal set of Fileinfo columns that are used in each Info set
4. Document primary Info subsets in the Column Visibility window - these appear to be already primarily sorted by Model (and in Help)

[johnmhoran]

@jdaguil If my count is correct, we currently display 48 columns in the Table View when a SQLite DB is loaded. What subset of columns do you suggest we display by default? @MaJuRG @pombredanne @mjherzog and colleagues -- do you have any preferences?

[steven-esser]

@johnmhoran, since the scancode --info is the only option explicitly required by ABCM, perhaps just the standard file info scan attributes: file_name, file_size, file_type, and sha1?

[jdaguil]

@johnmhoran +1 to @MaJuRG's suggestion. Also, since it's the first view on load, it might be nice to show copyright_statements and license_short_name too.

[johnmhoran]

Thanks @MaJuRG @jdaguil -- I'll make the change displaying those 6 columns on load.

Do we also want a column group button for this grouping, and if so, with what name? Could this be related to item 2 of @mjherzog 's 5/19/17 comment on this issue (re a "Fileinfo Info set")?

[johnmhoran]

@jdaguil @MaJuRG -- and of course include Path as well, right?

[steven-esser]

@johnmhoran Yes.

[jdaguil]

@johnmhoran For now, let's just have fewer columns by default on load. I've added a separate issue for the other ideas to discuss there #164

[johnmhoran]

Thanks @jdaguil . After some googling and checking the DataTables docs and forum, there appear to be two approaches to setting columns as visible/hidden on load. One uses columns.visible, listing each column separately by display index. We already use columns -- "columns": AboutCodeDataTable.TABLE_COLUMNS, -- so this is not available. The other uses columnDefs.visible and takes either a list of columns or an array of display indices in the target property, e.g.,

'columnDefs': [
    { targets: 0, visible: true },
    { targets: 1, visible: true },
    { targets: 2, visible: false },
    . . . list all 48 columns . . .
    { targets: 47, visible: false }
],

and

"columnDefs": [
    {
        "targets": [ 2, 3, 4, 5, etc. ],
        "visible": false
    },
    {
        "targets": [ 0, 1, 8, 23, 24, 27, 28 ],
        "visible": true
    }
],

The latter also seems to work if only the hidden columns are identified. Note: When paging through the table using these default settings, occasionally the vertical borders of the column headers and related content cells get slightly (and just temporarily) misaligned. The behavior otherwise looks fine, and the column-grouping buttons seem to work as expected.

My gut tells me there's a more elegant and easier-to-maintain approach using our JavaScript class and static getter structure, but I haven't yet been able to figure out what that might be. Meanwhile, I'm going to finish testing etc. using the array approach and will then commit, push and open a PR so you, @MaJuRG and others can vet.