Re: [lmi] Supplemental report column selection

[Vadim Zeitlin]

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:
GC> > 
GC> > GC> The GUI for selecting supplemental reports:
GC> > GC>   File | Preferences
GC> > GC>   "View" tab
GC> > GC> could be easier to use.
GC> > 
GC> >  It's hard to argue with this.
GC> > 
GC> > GC> I think a single wxCheckListBox might be an improvement: then we'd
GC> > GC> have just one list with dozens of choices, and end users could
GC> > GC> pick up to twelve just by checking boxes.
GC> > 
GC> >  I agree that it would be a (big) improvement, but I'm not sure if it's
GC> > going to be ideal because there would still be too many items in it IMO. 
Of
GC> > course, maybe this dialog is used so rarely that it doesn't matter, but if
GC> > we wanted to make it as convenient to use as possible, I think something
GC> > would need to be done in order to reduce the number of choices, e.g. by
GC> > grouping them somehow. But I don't know what would be the best way to do 
it
GC> > from the user point of view, unfortunately.
GC> 
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.

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

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.

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?

 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)?

GC> That is very helpful. 'rearrangectrl.png' shows "Up" and "Down" pushbuttons.
GC> In one of the wxwidgets samples, I saw something similar, but with up and
GC> down arrows instead, which seemed preferable; but maybe that's an option
GC> that can be chosen by specifying a style flag.

 No, there is no option for this. But it would be simple to get the
wxID_{UP,DOWN} buttons from wxRearrangeCtrl and set their image to
wxART_GO_{UP,DOWN}.


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?

 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.

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...

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.

 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.

 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.


GC> Or has my thinking simply failed to evolve since the 1990s?

 I'm afraid that the answer is a qualified "yes".

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.

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 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?).

 Regards,
VZ