New chat window behavior?
 

This behavior started occuring yesterday, with the patching of Frostfell.

It seems that now if you click on a chattab that is *partially* obscured by the shifter buttons, it *forces* the tabs to shift to make that tab fully visible.

Has anyone else noticed this? Unfortunately I haven't checked the behavior in the default yet, but the fact that it occurred at a time I didn't make any changes to my UI leads me to think that it was a change on SOE's side. I'll update this post once I get around to checking the behavior in the default.

confirmed. annoying.

Agreed.

*Looks around for Rothgar*

Can we un-have that please? I normally have my last tab partially hidden under it, but it's the last tab so I don't need it to move the tab row. Or at least give us an option to disable it, because by gawd does it get annoying. Especially since if the bugger of a tab shifter didn't show up in the first place, the last tab wouldn't be hidden...

Yes, I added the code recently to auto-scroll the tab when selected if its partially obscured. I didn't realize until the other day that this was happening even on windows that didnt display the scroll buttons. So I made a fix where this wont happen anymore if the scroll buttons are not visible.

But... are you guys saying you really don't want this option even if the scroll buttons are visible?

This I don't understsand, doesn't the client controls the visibilty of the buttons? :confused:

Personally, yes, that is what I was saying, because to get back to the first tab that gets auto-scrolled out of sight you now then need to use the scroll buttons whereas before you did not. But I would not want to speak for the broader userbase here, maybe they like it. I have not received any feedback on this so far (also I do not know how many people even have this many tabs, it may not be relevant for most).

It make no deference to me. I can live with it either way. Not like it is hard to click the button to get the others back into view. The tabs that I have under these controls is info I hardly ever look at.

I don't think so. I believe you have have to set a property on the UITabbedPane if you want the scroll buttons to be visible. If you set them visible, I believe the client will enable/disable them based on how many tabs are there.

Since I have the fix in so that the tabs won't auto-scroll if the buttons are off, I'll leave it as is unless I get a lot of feedback that this behavior isn't desired.

Ah ok, that is what you mean. Yes, in TabPane you define ScrollLeftButton/ScrollRightButton to tell the client the names of your scroll buttons. If you keep that empty then of course the client won't autoshow/-hide them.

I'd say it is rather unlikely that there is any UI out there set up like that, the more likely scenario is that someone would simply delete the tableft/tabright buttons from the default window.

Ah, I see what the cause of my issue was. By default the tabbedpane stops at the buttons... so a tab that before was normally *just* partially obscured by the buttons was triggering the move action.

I didn't realize that before, but now that I've set the tabbedpane to be almost the full width, I'm a happy camper once again =)

Personally I wouldn't want it to autoscroll anyway, but since I don't use the scroll functionality (I always have all tabs visible) it doesn't bother me since you've fixed it not to happen when the scroll buttons aren't displayed.

Yes, you can safely set it to full width and have it overlayed by the scrollbuttons if you want, works fine for me. :)

Yep, thats exactly what I did once I realized that it wasn't already that way.