Re: [lmi] Supplemental report column selection

[Greg Chicares]

On 2017-08-16 15:45, Vadim Zeitlin wrote:
> On Wed, 16 Aug 2017 14:34:00 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2017-08-14 13:11, Vadim Zeitlin wrote:
> GC> > On Sun, 13 Aug 2017 16:09:40 +0000 Greg Chicares <address@hidden> wrote:

[...with so many columns to choose from, a single flat listbox is not ideal...]

> GC> In the problem domain, the choices naturally fall into categories like:
> GC>   {Benefits, Payments, Interest, Charges, Values, Miscellanea}
> GC> each of which would contain perhaps four to twelve items.
> GC> 
> GC> In the solution domain, what control or combination of controls would
> GC> best represent those categorized selections?
> 
>  A wxTreeCtrl or wxTreeListCtrl with checkboxes. The latter would be useful
> if we want to display more than one column, e.g. a brief name and a longer
> explanation, perhaps, and is also slightly simpler to use than the former
> as support for item checkboxes is built in into it, while it would need to
> be done in lmi code for wxTreeCtrl.

That sounds good...

>  But, perhaps, as discussed below, it would actually be better to use two
> controls instead.

...but so does that.

> GC> OTOH...we propose (at least) two distinct but cooperative enhancements:
> GC>  - a better GUI for selecting columns
> GC>  - a way to save and load column selections
> GC> If we do the second one first, then the panel need only contain something
> GC> like a listbox (or perhaps a file picker) to choose a named set of column
> GC> selections...and then editing a named set (or creating a new one) might
> GC> naturally involve popping up a child dialog.
> 
>  I thought showing everything inside the same dialog would be preferable
> because, when selecting an existing column selections set, it can be useful
> to immediately see which columns are included in it and also be able to
> modify them directly, instead of opening another dialog to do it.
> 
>  And I think that even creating a new columns set would still be slightly
> more convenient if it didn't involve opening another dialog.

This calls for deep thought. But I just learned that, while end users
certainly want the sort of improvements we're discussing here, we need to
postpone this task in order to work on a completely different new feature
for which they are even more eager. (It concerns complicated life-insurance
arithmetic, so we probably won't be discussing it much here.) And, just to
be clear, replacing XSL remains the doubleplus overriding priority. But I'd
like to say a few more things here anyway, while this is fresh in my mind.

> GC> This could be advantageous because the child wxRearrangeDialog wouldn't
> GC> need to be embedded in the tabbed input dialog, so no new XRC support
> GC> would be needed. (Of course, as discussed above, we'd want the dialog
> GC> to support item groupings, and maybe the existing wxRearrangeDialog
> GC> class wouldn't meet that need.)
> 
>  No, it wouldn't. But then neither would any other wxRearrangeXXX classes
> as they all work with flat items structure. Perhaps they could be extended
> to allow hierarchical item groups somehow, but it doesn't seem trivial: in
> particular, how would moving items up and down work in this case?
> 
>  In fact, this is a good question in any case: if we organize items like
> 
>       Benefits
>               B1
>               B2
>       Payments
>               P1
>               P2
>               P3
>       Interest
>               I1
>               I2
> 
> how exactly would you use the control to select "I2 B1" columns, in that
> order?

That's a difficulty that calls for stepping back and rethinking.

>  I think that we could, perhaps, use a slightly different approach and use
> tree control just for displaying items and have a wxRearrangeList nearby,
> with the "Add >" and "< Remove" buttons to move items between them. Do you
> see what I mean or should I exercise my artistic talents again and make an
> ASCII drawing of it (just asking, please don't necessarily take this as a
> thread)?

I understand and agree, so no more artwork will be necessary.

Of course, with this better approach, we gain more liberty in the way that
available columns are presented. They don't even have to be shown in a
single control: we could present them in a group of several listboxes, or
in a multi-column grid.

> GC> > GC>   http://savannah.nongnu.org/support/?105590
> GC> > GC>   Save and retrieve supplemental reports
> GC> > GC> because the improvements mentioned above merely make less tedious
> GC> > GC> to pick a set of columns, but in practice there are a few sets that
> GC> > GC> get used over and over again, and picking a file that embodies one
> GC> > GC> of those sets is much easier than selecting each of its elements
> GC> > GC> repeatedly.
> GC> > 
> GC> >  The first UI that comes to mind here is to put a wxComboBox on top of 
> this
> GC> > page allowing to select an existing supplemental report kind, by name, 
> and
> GC> > "Save" button allowing to save the current selection under the name 
> entered
> GC> > into wxComboBox.
> GC> 
> GC> Physically, where should sets of column selections be stored?
> 
>  This depends on the goals: do we want these column sets to be transferable
> between machines? Shareable between users on the same machine?

There are a few sets that we would want to share in our regular
distribution, so that they could be installed on many machines.

I don't think end users would often need to share their personal
customizations with each other. If they design something that's
useful across their community, we can include it in the regular
distribution.

>  If we don't care about anything like this at all, the simplest would be to
> just store them in wxConfig and not care about where exactly do they go. Of
> course, lmi doesn't use wxConfig much currently (AFAICS it's only used to
> store the recently opened files), so maybe you'd prefer to avoid using it
> for this too.

We use wxConfig for the MRU list because, IIRC, their implementations
are naturally tied together in the wx library.

We use 'configurable_settings.xml' for other parameters because...
well, I guess, because we've always done it that way.

These new settings seem closely related to other things we already
store in XML. But they're different in that we envision a variable
number of named sets of columns, which is more complex that anything
in the XML today.

Maybe we should get rid of the XML and use wxConfig for everything,
or at least for everything that's purely GUI specific (because the
command-line versions of lmi really are useful).

> GC> As separate files, in the same directory as 'configurable_settings.xml'?
> GC> 
> GC> Or as strings embedded in 'configurable_settings.xml'?
> GC> 
> GC> Isn't "as separate files" clearly better?
> 
>  Neither looks ideal but I'd say that "separate files" seems clearly worse
> to me...

Let the dialectic begin.

> GC> And, if so, then shouldn't they be chosen with a wxFilePicker? and
> GC> edited and saved through the File menu, like any other file?
> 
>  ... precisely because we don't want to bother the user with this, unless
> there is a really good reason to do it. But normally the last thing I, as a
> user, want to do is to select a file to store my column selection or hunt
> for this file later when I want to use it. I just want things to work,
> without thinking about them.

I want to understand how things work, so that I can make them do what
I want without the obstacle of a GUI. But I'm sure our end users share
your outlook instead.

>  So for me using a single file (or registry or database or whatever) for
> storing all these column sets definitely looks like a better solution. The
> main problem I have with this is that I don't like XML and I don't like
> adding even more things to configurable_settings.xml. But it's not really
> that big of a problem.

For configuration data, I think of XML as a regularized (though regrettably
verbose) syntax for name-value pairs. Then again, name-value pairs like
  [column_selections]
    Typical=Outlay,CashValue,DeathBenefit
    Custom1=...,...
can be just as regular, and easier to look at. Both would accommodate a
multiplicity of stored column-sets.

I'm a little hesitant to use an OS-specific storehouse like the msw
registry, because it may be harder to fix if things go wrong, and also
because it's harder to update in a monthly distribution. But IIRC wxConfig
has an option to use dotfiles on all OSs.

>  BTW, I've really started to appreciate the idea of using SQLite instead of
> inventing custom application formats such as configurable_settings.xml
> recently (the idea is not new, of course, well-known programs such as
> Firefox have been doing this for ages and others for probably even longer),
> see https://sqlite.org/aff_short.html. I don't advocate immediately
> replacing XML with SQLite but if, by chance, you're willing to consider
> this, I'd be more than willing to do it.

Given the small amount of configuration data we use, my initial
impression is that a full-blown database might be overkill; and
I'd rather avoid adding a new dependency. (What if it breaks?
What if it becomes abandonware? What if a horrible security
problem is found in SQLite someday and corporate policy forbids
its use?)

> GC> Or has my thinking simply failed to evolve since the 1990s?
> 
>  I'm afraid that the answer is a qualified "yes".

So I feared. Well, lmi's GUI should target its end users.

> GC> Is that more modern, and easier for today's users, than treating
> GC> an lmi selected-columns "profile" as a document?
> 
>  Again, if the goal is to handle it as a document, then maybe not. But are
> you sure users would think about them as documents? Without any deep
> knowledge of the problem domain, these column-sets look more like "program
> settings" to me, i.e. something similar to, for example, the last opened
> files or other things already stored in configurable_settings.xml.

Okay, end users don't think of settings as documents.

> GC> Is there some exemplary application that does this sort of thing in a
> GC> way that's generally considered natural and usable, so that we might
> GC> look to it for guidance?
> 
>  I don't think so, there are many different programs doing things in
> different ways. The most modern one is definitely having an online account
> and store all user data, including options like this, in a central location
> in order to allow user to have access to it from any machine (and, perhaps,
> to facilitate vendor lock in and make all contents more easily indexable
> for the purpose of {serving advertisement,fighting terrorism}). I don't
> believe having ever seen a program treating its settings as documents

vim ~/.vimrc

> and I
> can't say I see any real advantages in doing it like this for typical users
> (i.e. I might find it useful in order to put these documents in a Git
> repository, but would we really expect lmi users to do this?).

Redistributability is an advantage. Putting all configuration options
in a file means we can ship a preconfigured lmi system. But that
doesn't require that a configuration file be discoverable by end users,
much less modifiable in a text editor.