Submit Ticket

1005
Open
Linkinus
Normal
graphical whois screen displays no information on Freenode

This is sort of tangentially related to a previous bug i submitted, ticket # 652.

Per that ticket, my preference would be an option to disable the graphical whois entirely, as i feel it is incredibly disruptive (it's slow, it blocks ALL OTHER ACTIVITY in the window, it spams NickServ, &c.).

However, if there are no plans to do that, then i think one thing that would be nice at the very least is if the graphical whois screen actually displayed whois information. Currently, at least on Freenode (i don't use any other networks), that screen is entirely useless because the only information it displays are nickname, user name, host name, real name, and network. All other fields (server, channels, idle time, &c.) are blank, every single time, even though the textual whois command returns them just fine.

Additionally, there does not appear to be any method by which Linkinus can display any information beyond the basic fields it has in the window. For example, there is no place in the graphical whois screen to show whether a user is identified to services (this is a common response to a whois on networks with services).

Again i would like to reiterate how irritating the entire concept of this screen is, but if you are still not convinced, please at least make it display the information it's designed to display. Thanks!

configuration: Linkinus 2.1 (and earlier) / Snow Leopard

Help us help you

The single most useful thing you can do when filing a bug report is to include a numbered list of steps that trigger the bug for you every time, like this:

        1.) Start the application
        2.) Click on the File menu
        3.) Choose Print
        4.) ... etc ...

Not all bugs are consistently reproducible -- but if your bug is reproducible, and can be reduced to a series of steps like this, it's as good as fixed once an engineer gets hold of it. Engineers love bug reports like this because it eliminates so much guesswork and trial-and-error.

Be meticulous and specific, but try to reduce the problem to the smallest number of steps you can. Say the problem occurs if you open an image, crop it, then save the image. Try eliminating the cropping step and see if the problem remains -- it may not be necessary to trigger the bug.

Sometimes users file bugs against the designed behavior of the program: "When I do X and Y, Z happens!" -- But, as far as the developer is concerned, Z is what is supposed to happen when you do X and Y.

To avoid this, it's best to include "expected" and "actual" results after your list of steps.

© 2012 Conceited Software. All rights reserved.