Tab display feature requests

[Ethan Blanton]

Dexx Mandele spake unto us the following wisdom:
> First of all the obligatory (though entirely honest) gushing praise for the
> product. You guys make my work so much easier, thank you.

Thank you.

> 1) I have a very narrow chat window and my open windows are listed at the
> top of my window. This means that I usually have more tabs open than can
> comfortably fit. Fortunately Pidgin crops those off the screen, allowing me
> to access them with either ctrl+tab or by clicking the tiny arrows left and
> right of the visible tabs. This is pretty close to my ideal solution, it
> allows easy access to out-of-sight tabs without distorting my chat window
> too much. My problem is with the left and right arrow keys (as mentioned
> before, the ones to the left and right of the visible tabs), which shift
> the focus of my current window one tab to the left or right on click. This
> makes absolutely no sense to me. If I wanted to shift focus from one
> visible tab to another I'd simply be clicking the other tab as it is far
> more visible and easier to pinpoint than the tiny arrow. The arrow should
> be shifting the entire selection of visible tabs. To illustrate:

This is behavior we inherit from the graphical toolkit we use, Gtk+,
and not something we implement ourselves.  I am inclined to agree with
you that the Gtk+ notebook tab handling is good but not nearly ideal,
but we are not particularly interested in maintaining our own notebook
widget.

> In practice the lack of a practical tab searching system means I often
> switch back to my buddy list and finding a user there, even though I know I
> already have a conversation with that person open, simply because it's
> faster than ctrl+tabbing my way through 10+ tabs one by one.

Tab searching is something that might be possible either in the
existing Gtk+ notebook design (I don't know) or within Pidgin (which
we would have to implement).  I do not know that any developer would
make this a priority, but I recommend that you open an enhancement
ticket for it.

> 2) When I have a new message waiting for me in a tab, the tab title turns
> blue. When I open that tab and view the contents, the title switches back
> to black. I love that. The simple and intuitive visualization is obvious
> without being obtrusive. What I don't get is why that can't be implemented
> for 'user is typing' and 'user has stopped typing'. Respectively, these
> states change the title color to yellow and green. However, if I click the
> tab, thereby acknowledging the change in state, the title remains yellow or
> green! Only if the other user submits his message (turning the title blue)
> does the system allow me to revert the message title to black. This
> wouldn't be a significant problem if all messages ever started were also
> submitted within a reasonable time-frame. However, in my less than ideal
> world users often start typing something, think better of it, and end up
> responding hours later (if at all). This leaves me with a green/yellow
> warning title that constantly catches my eye and triggers a curious 'hey,
> did I get a new message?' response without actually providing new info.
> 
> In short; please revert the message title to black after I open a window in
> which a user is typing/has stopped typing.

This is very reasonable.  Again, I don't know what kind of priority it
will have, but please open a ticket for it.  Perhaps we can clear the
tab color but leave the typing icon (so that that information is not
lost).

Ethan