lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Supplemental report column selection


From: Greg Chicares
Subject: Re: [lmi] Supplemental report column selection
Date: Wed, 16 Aug 2017 14:34:00 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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

In the problem domain, the choices naturally fall into categories like:
  {Benefits, Payments, Interest, Charges, Values, Miscellanea}
each of which would contain perhaps four to twelve items.

In the solution domain, what control or combination of controls would
best represent those categorized selections?

> GC> Column order matters greatly for supplemental reports, so we'd have
> GC> to provide a way to sort the listbox items.
[...]
> GC> It isn't indispensable to integrate them into a single control, but we
> GC> really would need this to work in wxXRC.
> 
>  Neither of wxRearrange{List,Ctrl,Dialog} classes is currently available
> from XRC, but this would be very simple to change, at least for the first
> two (the latter one would be trivial to handle in XRC without support for
> its AddExtraControls() method too, but supporting this method nicely would
> be a bit more difficult -- but you don't need this one, in any case).

In the extremely long term, AddExtraControls() might be useful for this:

  http://savannah.nongnu.org/support/?104483#comment3
| linear combinations of other columns, with scalar coefficients
| of 1 and -1. We need a general facility to let users define such
| columns.

Thus, a user might add a column defined as "CashValue - Loan". But we
can hardly think of doing that this decade, and probably won't do it
next decade, either.

> GC> Vadim, if I've expressed the idea clearly enough, can you tell me
> GC> what specific controls we'd use to accomplish this?
> 
>  wxRearrangeCtrl. We can't use wxRearrangeDialog because we want it to be a
> page in an existing dialog instead of a standalone one and we don't want to
> use just a wxRearrangeList because we don't have any existing buttons for
> moving its items around, so it's simpler to use wxRearrangeCtrl which
> combines both the list and the buttons.

OTOH...we propose (at least) two distinct but cooperative enhancements:
 - a better GUI for selecting columns
 - a way to save and load column selections
If we do the second one first, then the panel need only contain something
like a listbox (or perhaps a file picker) to choose a named set of column
selections...and then editing a named set (or creating a new one) might
naturally involve popping up a child dialog.

This could be advantageous because the child wxRearrangeDialog wouldn't
need to be embedded in the tabbed input dialog, so no new XRC support
would be needed. (Of course, as discussed above, we'd want the dialog
to support item groupings, and maybe the existing wxRearrangeDialog
class wouldn't meet that need.)

> GC> I don't find a
> GC> wxRearrangeCtrl in any of the wx samples. This image search:
> GC>   https://www.google.com/search?q=wxRearrangeCtrl&tbm=isch
> GC> finds inheritance diagrams but no screenshot of the actual control.
> 
>  I've added the screenshots to the manual now (see
> https://github.com/wxWidgets/wxWidgets/commit/7316ce76269d9637d46a7fbdecc9849673151271
> which includes the images, although they don't load for me in the diff view
> right now for some reason -- you can still view them by clicking the "View"
> button however). And I also attach a screenshot of the entire
> wxRearrangeDialog where I (as if you wouldn't recognize my stroke) artfully
> circled the wxRearrangeCtrl part.

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

> GC> Once we've chosen the right control and implemented it (or chosen
> GC> a handful, experimented with them, and picked the best one), there's
> GC> another step:

(As noted above, it might be better to implement these steps in reverse
order.)

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

Physically, where should sets of column selections be stored?

As separate files, in the same directory as 'configurable_settings.xml'?

Or as strings embedded in 'configurable_settings.xml'?

Isn't "as separate files" clearly better? And, if so, then shouldn't
they be chosen with a wxFilePicker? and edited and saved through the
File menu, like any other file?

Or has my thinking simply failed to evolve since the 1990s? I've been
working with configuration options for KDE's 'konsole' today. Its
"Settings" menu contains these three items:
  Configure current profile...
which pops up a dialog to edit some profile...but I'm not sure which
one, or how it's chosen, and in one session this profile's name is
an empty string;
  Switch profile
which cascades to a submenu that offers only one choice, named
"Shell"--which is presumably different from the unnamed current
profile...but apparently it corresponds to the physical file
'~/.kde/share/apps/konsole/'; and
  Manage profiles...
which IIRC originally listed "Profile 1", ... "Profile 7", though
it now lists only "Shell"; it pops up a dialog that lets me either
edit a selected profile, or clone it to create a new profile and
edit that.

Is that more modern, and easier for today's users, than treating
an lmi selected-columns "profile" as a document? Might such a
"profile" be a special type of document that calls for its own
"File | Reports..." menuitem, which would pop up (for example)
a list of files like konsole's profiles, which could be edited
only through a wxRearrangeDialog? Is there some exemplary
application that does this sort of thing in a way that's
generally considered natural and usable, so that we might look
to it for guidance?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]