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 _______________________________________________ [email protected] mailing list Want to unsubscribe? Use this link: http://pidgin.im/cgi-bin/mailman/listinfo/support
