[GNC] Tabs Behaviors in GNC4.1

David Carlson david.carlson.417 at gmail.com
Wed Sep 16 15:46:14 EDT 2020


Geert,

I believe some users have backed off of trying to express informed opinions
about program development or documentation development because of various
roadblocks that have been thrown up.  Sometimes we are ignored, sometimes
asked to learn obscure new skills, and occasionally chastised for waiting
until after the fact to 'complain', to name a few.

There is a gap that we are having a hard time trying to deal with.  I don't
know if there would be a way to 'warn' users about pending changes before
they are released.  Some programs put changes into an official beta release
available to the general public some time before moving to the stable
release. Just an idea.


On Wed, Sep 16, 2020 at 2:26 PM Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:

> Op woensdag 16 september 2020 14:46:58 CEST schreef D.:
>
> > Thanks for pointing this bug out.
>
> >
>
> > It's too bad that the suggestion in the bug to discuss this change on the
>
> > lists was not apparently taken up. The devs would then have at least
> heard
>
> > from some other users about their use cases and preferences, and users
>
> > would have had a heads up about the change. Instead, a change gets pushed
>
> > out based on one person's request, mainly because it involves "three
> lines
>
> > of code." I'll set aside the wisdom of making changes to software based
>
> > primarily on the complexity of the fix, or on a single user and the
>
> > opinions of three devs...
>
> >
>
> > While it might seem overkill to discuss something as seemingly minor as
> this
>
> > change, I think *any* change in the user interface should be discussed
>
> > more, rather than less.
>
>
>
> David,
>
>
>
> Yes, more discussion up front is useful. However if you want more
> discussion to happen (or more precisely if *you* want to be get involved
> more in such discussions) I suggest you actively choose to become more
> involved proactively rather than waiting until a finished release is
> presented to you. That doesn't mean you have to write or review code, but
> you can subscribe to the channels where the devs generally communicate to
> get an early idea of what lives there.
>
>
>
> Some topics will be brought to the users, others not so much. And by the
> way, I don't think gnucash-user is the proper channel for this kind of
> discussion. I believe it should be held on gnucash-devel.
>
>
>
> >
>
> > Now, we get to have that discussion.
>
> >
>
> > At the risk of repeating myself, let me re-present. In my usage of
> Gnucash,
>
> > I keep a core set of tabs always open. These tabs represent my primary
>
> > active accounts: my checking account, savings account, credit card
> account,
>
> > and a cash account.
>
> >
>
> > I leave them open because they are involved in the vast majority of my
>
> > transactions, and it is easier to click on one of the tabs than to go to
>
> > the CoA, locate the account, and open it. I like to have them at the top
> of
>
> > the list at all times because I can quickly locate them there. I know
> where
>
> > they are.
>
> >
>
> > With the latest change, I no longer can rely on this. My core tabs move
>
> > down. If I open one of my more obscure accounts to look at things, it
>
> > pushes its way in at the top. If I've opened several of them, they are
> all
>
> > at the top, and when I am done with those tabs, I have to carefully close
>
> > tabs, rather than close all tabs below a certain point on the screen.
>
> >
>
> While I see what you mean with closing, I perceive this as a minor
> behavioural change. As all the new tabs will be on top, it should not be
> too hard to close them one by one by starting with the first one. You don't
> have to move your mouse for that. I can imagine you have to be a little bit
> more careful to stop clicking in time to avoid closing your first
> "always-open" tab. However if you have many always-open tabs that problem
> also exists when new tabs open at the end.
>
>
>
> > None of this is particularly catastrophic, but it does affect me and my
>
> > workflow every time I open or close an account, so I would prefer to have
>
> > the option of restoring the old tab behavior.
>
> >
>
> See my other replies here and on the bug. I don't think an option is a
> good solution.
>
>
>
> > The idea of pinned tabs is interesting, although it doesn't remove the
> need
>
> > for the preference. If I jump to a new account tab from a pinned one,
> will
>
> > the new tab go at the end of the list, or bury itself in the middle of my
>
> > pinned tabs? I think the user would still want the option of where the
> new
>
> > tabs open.
>
>
>
> That problem is not solved by adding an option.
>
>
>
> >
>
> > I'll give a clear and unambiguous preference: I want to be able to choose
>
> > this behavior with a preference setting. Put this setting on the same
> page
>
> > as the tab location setting, and have it read:
>
> >
>
> > Open new tabs: □ At the bottom of the tab list □ After the current tab
>
> >
>
>
>
> Understood. My clear and unambiguous design standpoint is that an option
> is not the solution. It's a band-aid at best. I don't have a ready-made
> answer but I know this isn't it.
>
>
>
> Geert
>


-- 
David Carlson


More information about the gnucash-user mailing list