1. Instead of "to the right of the currently active tab" I would say "behind the currently active tab in the default writing direction (LTR/RTL)"

2. I believe most users would prefer it. you could ask on the mailing list, if a preference is really required.

I would use "after" rather than "behind", but yes agree with the LTR/RTL comments.  I only bring up the preference question on jrall's suggestion; personally I agree with you a preference is likely not needed.

I poked at this and it is not hard to do, change about 3 lines in gnc_main_window.c, just thinking of LTR at the moment.

Would need to check if OK for 4.0 but this change would create all pages to the right of current page so new register pages would be created right of CoA where ever that may be right ?

Jumps from registers would open new register pages to the right of current one if not already open ?

New Reports would be open to the right of current page ?

> so new register pages would be created right of CoA where ever that may be 
> right?
Don't know what "CoA" means, but if it means currently active tab, then yeah, I would want new registers to open to the right of the currently active one.

> Jumps from registers would open new register pages to the right of current 
> one if not already open?
Yes please.

> New Reports would be open to the right of current page ?
Yep.

Chart of Accounts

I would not treat the chart of accounts any differently.  Just keep it as "to the right of the currently active tab".  So yes, if you open an account from the chart, it would be right of the chart, given that the chart is active.

As a corollary I wish the Window menu populated itself with all tabs. RClick the tab bar gets weary quickly.

Created PR 737 for this change as unsure if OK for 4.0

Chris I am not sure what you mean by that?

(In reply to Christopher Lam from comment #7)
> As a corollary I wish the Window menu populated itself with all tabs. RClick
> the tab bar gets weary quickly.

(In reply to Bob from comment #9)
> Chris I am not sure what you mean by that?

If you have many register/report tabs open, the only way to navigate to an arbitrary tab is to LClick the relevant tab, or RClick the tab-bar. The tabs do not populate the Window menu. I can try Ctrl-PgUp/PgDn to switch but is not reliable. So, to navigate tabs is awkward.

(In reply to Christopher Lam from comment #10)
 
> If you have many register/report tabs open, the only way to navigate to an
> arbitrary tab is to LClick the relevant tab, or RClick the tab-bar. The tabs
> do not populate the Window menu. I can try Ctrl-PgUp/PgDn to switch but is
> not reliable. So, to navigate tabs is awkward.

I have seen previous bugs reported for tab navigation, some pages use that key combo and so it is eaten, maybe I will take a closer look at what they are saying.

Have you tried Ctrl-Alt-PgUp/PgDn, that works for me.

Using the Windows toolbar would still equate to the same number of mouse clicks to RClick tab, then select or would you do this from the keyboard.

(In reply to Bob from comment #11
> I have seen previous bugs reported for tab navigation, some pages use that
> key combo and so it is eaten, maybe I will take a closer look at what they
> are saying.
> 
> Have you tried Ctrl-Alt-PgUp/PgDn, that works for me.

I'm not sure 100% reliable though.

> Using the Windows toolbar would still equate to the same number of mouse
> clicks to RClick tab, then select or would you do this from the keyboard.

You're right I'm a heavy keyboard user, using all sorts of gtk accelerator keys. Alt-W, hold Up/Down, Enter would be better to select a tab :)

I wonder if there is a short cut for the right tab menu, if not maybe it can be added?

(In reply to Bob from comment #11)
> Have you tried Ctrl-Alt-PgUp/PgDn, that works for me.

Specifically this does not work when you click on the WebKit canvas. [Ctrl][Alt]PgUp/PgDn goes to Webkit to scroll report.

I agree with Bob, having the tabs in the Window menu vs the right click context menu isn't significantly different.  Something slightly more useful would be a tab search feature (perhaps in the Window , as in open a text box, start typing the name of the open tab, and the list shortens with the search.  But I digress, this would be quite the significant enhancement.

Even at 50 open tabs, I don't mind the right click menu... for now... but yes, a solution would be great.  Navigating is still less cumbersome than opening a new tab at the end of the 50, then trying to drag it back to the start of the list!

Just pushed the change to mint so that new plugin pages are added next to the current page. Will be in 4.1

Other changes will be addressed in existing bugs.

Where is the preference to turn this off?

Please make this a preference setting. This is really not the preferred behaviour for some.

Well, given that my original feature request was for a preference setting rather than an immutable option, I'll re-open the ticket to reflect this.  It should be a preference setting in Preferences > Window

It looks like about every visual change that is made will trip up at least one user because they were used to how it was.

Before anyone starts implementing this option, I'll point out that just adding an option to keep old behaviour is not good design.

Also saying "this is not the preferred behaviour" is not sufficient. It doesn't motivate what was better about the old behaviour. We need strong motivations from a design point of view.

The design motivation to open a tab next to the existing one is that if you open a tab it's very likely you want to use it soon afterwards. So it makes sense to put it close to where you currently are, namely close to the current tab.

What design concept warrants opening tabs at the very end ? Firefox doesn't do it.

For reference I have looked at Firefox and Chromium, two webbrowsers and also heavy users of a tab interface. They also will position new tabs right next to the current tab (with the subtle improvement that if you open several one after another they will all appear next to the existing tab but in order they were opened - that is the first opened will be closest, the last opened will be furthest). I haven't found any preference setting to change this. So it seems browser designers agree on the concept of opening new tabs close to the existing one.

If you are using browsers as a comparison then multiple browsers offer 'pin' tab (e.g. Chrome, Safari), any new tab opens after all of the pinned tabs. This would be acceptable behaviour but there is no pinned tab behaviour in Gnucash.

My tabs are on the left and I have a number of reports 'pinned'. This change breaks my usage, so would prefer it be an option or pinned tabs.

(In reply to Geert Janssens from comment #21)

In Firefox, new tabs opened with the + button or ctrl-T open at the end of the tab list. Tabs opened from a link in an existing tab open to the right of that tab. Firefox has settings for these.

browser.tabs.insertAfterCurrent (default value false)
browser.tabs.insertRelatedAfterCurrent (default value true)

In this respect I would consider registers opened using the jump-to button and hyperlinks in a report to be related tabs.

Now we're getting somewhere. Thanks for the added details.

I think "pinned tabs" is a good enhancement on its own.

And in addition, the concept of related tabs is strong as well. I agree that tabs opened from a menu have much less relation to the current tab than the jump-to or hyperlinks are from. So that's a good metric to decide new tab location on.

As for the options in firefox, I suspected it to be very likely their advanced options could allow such configuration. And unfortunately that's also where I choose not to follow firefox. We don't have enough manpower to manage that extreme configuration flexibility.

So if we can come to a better overal experience by refining the tab location based on relatedness I'm ok with that.

Is there a plan to revert this patch while a better solution is found? Leaving this in place inconveniences a far larger number of users than it benefits.

I agree that the "fix" as implemented is inconvenient for my workflow since I usually search from the Account List. While I don't particularly care what the ultimate implementation is, my hope would be that options of placing the tab either at the beginning or the end of the tabs list be included in the next change that addresses this issue.

I repeat my request that this patch be reverted at the soonest opportunity. I (and others) continue to suffer with the ramifications of its change, and continue to think that interface changes such as this should not be made based on the needs of a single user.

(In reply to David from comment #27)
> … interface changes such as this should not be made
> based on the needs of a single user.

It's more than one, but I understand that one man's Uhl is another's nightingale. ;-)

IIRC we can also create a poll on uservoice.

Frank, I see ONE user (cdb-man) requesting this change. Chris makes a different ("corollary") request in comment 7. No one else joined the conversation to support the request; we only have Bob noting the ease of the change. 

In contrast, we have four different users (me, Richard, Alun, and now John) expressing displeasure at this change. (I will note, too, that cdb-man suggested that his idea would be better implemented as a user-configured preference, which has been dismissed by Geert) 

As any researcher will know, this does not necessarily reflect the true sentiment of the broader community (certainly not on a sample size of 5), although an 80-20% split is pretty extreme and can at least indicate a potential trend. I am not sure that a uservoice poll would be any more reliable, and in the meantime, those of us who have expressed our displeasure at this change continue to suffer. Just because a change is easy doesn't mean that it's right.

Problem Solved??? at least for me. I simply dropped back to version 4.0 while waiting to see what happens. I know I'll miss out on any other updates since then but I can live with that. My other option is to download the source and revert the code for this change as each update comes out. Not sure it's worth it to me to do that every time so I may be on 4.0 for the foreseeable future.

JohnL: no. It isn't solved. And every day I use gnucash, I get the reminder of how it isn't solved. I'm glad you've got a way to work around this, but I'm not planning to back load 4.0, and I won't be compiling and maintaining my own fork of the project. Based on the responses here, I'd suspect this is another one of those changes to the program that will simply live on because it Has Been Made.

This will be fixed in maint for 4.6. New boolean global preference in "Windows" tab: "Opens new tab adjacent to current tab instead of at the end".

Oh, thank you! I can hardly wait!