Submit Ticket

1006
Open
Linkinus
Normal
Linkinus should switch to console when other windows are closed

Linkinus has a minor but annoying quirk that's somewhat difficult to describe, so i'll just go straight into how to reproduce:

1. Connect to an IRC network.
2. Join a few channels.
3. Click on each channel and then close it.

After all of the channels are closed, you will be returned to what you might call an 'orphan' window — it's a blank screen with a Linkinus logo in the background that will accept no input. (Or, rather, it will accept the input, it just won't do anything with it.) So, for example, if i want to close all my chat windows and then rejoin the channels, and i try to do the above and then just do a /join #whatever... nothing will happen, because this 'orphan' window isn't associated with the server i'm on, it just does nothing when i type into it.

The logical thing to do in this situation would be for Linkinus to automatically focus the nearest CONSOLE window (the one with the MOTD, &c.) after all other windows have been closed. You should only receive this blank window if there is absolutely nothing else for the application to fall back on.

configuration: Linkinus 2.1 / 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.

© 2010 Conceited Software. All rights reserved.