Hi there,
>> 2.) Browse Folder window, any version: If some kind of "view threads >> by" is selected, the threads are displayed with the "root message" and >> a little + to the left to expand the thread. However, a double click >> on this line doesn't expand the thread as is expected, but opens this >> message in a new window. M> I don't think this is a bug. As far as I can recall that has always M> been that way, I have just verified it with the oldest version I M> have (3.0.2.10) and it is the same. That's why I wrote "any version". ;-) It's also why I spoke of "deficiencies" instead of "bugs". A bug doesn't always come in the form of an AV, it may simply be an oversight without catastrophic consequences which needs a workaround to handle. Yes, I understand that and why this behaviour in fact may be beneficial to some, not everyone uses the message preview window. But most will, and the misleading double click response is definitly non-standard behaviour - in Windows, when you see a collapsed tree (with the + on the left hand side) you expect it to open on a double click like it does in explorer or even other TheBat windows (e.g. "Accounts/Folder List"). Look at it this way: Of 100 people doing a double click on the first subject line, how many will expect to have the message pop up in a new window instead of the thread unfolding? How many of them will accidently have executed an action that they didn't intend to execute? I bet you that it well be well over half, probably at least close to three fourth. A program that seeks ease of use adheres to UI standards. If it wants to reinvent the wheel way better than it had been before, this should be optional. Forcing the user to change their trained behaviour instead of catering to his expectations will not endear the program to the user. >> 3.) Editor (MicroEd), any version: The editor is unable to honour CRs >> without an empty line following. Two lines that follow right after >> oneanother are drawn together by auto-format even if the first one is >> terminated by a CR. M> This is a feature WAD, not a bug. A feature that is clear that you M> don't like, but a feature. I respectfully disagree. A feature is being able to do something, not being prevented to do something. If the way it currently works is intended behaviour, it definitly is non-standard and should be selectable. >> a.) The icons are unnecessarily large. M> You can change that with batskin.xml file and I guess it will be M> possible (soon?) via the Customise window. Great. Come to think of it, there shouldn't be a reason not to include the options we discussed above there too, should it? The programmers had such a hard time creating this monster of "Customizer", now that it exists it could very well be put to some good use. >> b.) The icons are also less clear as the ones in v3.01. M> You can use alternative ones defining them in batskin.xml file. Can the icons from v3.01 be extracted somehow? -- MfG, Alto mailto:[EMAIL PROTECTED]
pgpE5DGtUrTJc.pgp
Description: PGP signature
________________________________________________________ Current beta is 3.5.25 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
