The terminology used for closing tabs/chats in Linkinus is very confusing and non-standard. This terminology appears most prominently in two places:
1. When you right-click a query or channel entry in the list on the left-hand side, there is an option called 'Delete Channel' (or 'Delete Query' or whatever).
2. The first time you close a query or channel (either from the above menu item or from the standard ⌘W keyboard shortcut), you are presented with a dialogue that warns you about 'deleting' the window. I've disabled this warning and can't figure out how to re-enable it, so i don't know what the exact wording was, but it definitely refers to deleting.
Using the term 'delete' to refer to closing a tab is, i think, a very poor idea.
Firstly, you aren't actually deleting anything. That channel (or user) is still there, the logs are still on your computer, you can rejoin it without losing any data — nothing has been deleted.
Secondly, the term 'delete' is non-standard. I can not think of a single other application that uses this terminology to refer to closing tabs or windows. This alone should be argument enough to not do it.
Thirdly — and related to the second point — the use of the word 'delete' is very destructive sounding, which confuses and worries users. I consider myself quite an advanced user, but even i was hesitant the first time i tried to close a channel window — i was concerned that this was not actually the command i wanted, that i would lose something, that it would be difficult to get back, &c.
I think it would be very wise to just use the word 'Close' like other applications.
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.