Tim Wunder <[EMAIL PROTECTED]> writes: > I understand the desire for a simpler SLR dialog. The one in 2.0.x required [...] > And finally the user is presented with a "Press Apply to create these > transactions" page, where the user could cancel out of everything, or press > Apply to commit the entrries. > > Now you might say that's a lot of dialogs to force a user through just to > create some SXs, but the dialogs are clear, well labeled, and logical.
There was one more page that probably no one ever saw, which was the "obsolete SX deletion" page. As well, there was a lot of logic behind the scenes to maintain each page in response to changes in the others. And (even still), the only way to get the real transactions displayed for review was to actually create them, which meant that: 1/ they were created before 'Apply' was pressed, which is not ideal, and 2/ they needed to be deleted if you hit Back or Cancel, dirtying the book along the way. > Now I'll describe the new diaog, and why I don't particularly care for it > (and > maybe some ways to improve it): > When starting the SLR, the user is presented with a single window > titled "Since Last Run". There's no bold name of the window, there's no > description of what the window is for. It's just a window containing what > appears to be every transaction reminder and every transaction ready to be > created. Yes. This was part of the goal: instead of splitting these related transactions across 3-4 separate pages of the druid, to bring them into a single dialog where the user can both see and act on them in one go. [reminders vs. to-create...] > ready to be created. I liked how the 2.0.x SLR separates the two. Maybe a > compromise would be to provide a button to hide or show the reminders. By The view could be filtered, yes. I don't have plans to do this right now, but I've noted it in <src/doc/sx.rst>. > I also don't like how I have to click and hold the Instance State in order to > select another Instance State for an SX. Let me click, let go and then select > a new state. Yes, this is an artifact of how the GtkTreeView works with the editable cells. Similar to the register, the first click activates the cell, where the widget changes from a label to the combobox. It would be nice if there was an affordance in the GtkTreeView that the cells were activate-able. > The headings of the dialog are too techno-speak. These are all great suggestions. I've added them to <src/doc/sx.rst>. > Instead of "SX, Instance, Variable" something like "Transaction" would be > better. The "problem" with that column is that it does contain all three values: the SX name, the instance date and the variable name, as well as being the hierarchy-control widget column. But it's probably better to just say "Transaction" than try to combine all that. > Instead of "Instance > State" I'd prefer "Status." Instead of "Variable Value" use "Value" > or "Amount." Agreed. > And if it is a variable, show it as (need value), if not, > display an amount. That is what happens now. Are you seeing something else? > Perhaps the amount on the first line of the SX. Maybe even > add an account name to the dialog. Perhaps the account displayed could be > specified in the SX itself, in the template transaction dialog by adding a > display tag. Each line item on the template transaction could have a checkbox > for displaying in the SLR. But I'd prefer to see something like > > Transaction Status Amount Account > Payday > 6/20/07 To be created $1000 Income:Salary Yeah, we have this general problem with the SXes and the template transactions ... the variables can affect more than one account, and there's not a single account or value that's reasonable to display (without user prompting), though in most cases there probably will be... letting the user decide what account/amount to be displayed would be good. > Instead of the arrow thingy that lets the user expand the SX instances, why > not just show the SX names in Bold and list the instances below, in a > semi-outline kind of fashion? The usefulness of being able to expand or > contract the instances of an SX escapes me, but I think there would be an > appearance and readability benefit from making the SX names bold. If there are a lot of SXes, the expand/contract widgets are very useful. The GtkTreeView naturally provides them. I agree that bolding the SX names would make it more appealing. > I'll admit that as I looked at the new SLR in a bit more detail tonight, I > see > where it could be an improvement over the old SLR. But as it stands now, I > certainly prefer the old SLR to the new. Thanks for the feedback. :) I'm curious what you think of the SX List page and the new (tabbed) SX Editor, as well. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
pgpTYLFVojR8H.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
