[New] BitComet Beta [20111207] has been released

General Announcements
1

Dear all,

The latest Beta version of BitComet has just been released, you’re all welcomed to download it HERE.

Changelog

[2011.12.07]

GUI Improved: keep the tasks which occur downloading error together when sort task list by state

GUI Bugfix: keep task selection status when clear the keyword of task filter

GUI Bugfix: the setting of Auto-Shutdown can be set only once

Core Bugfix: handle torrent file not using UTF-8 encoding

[2011.11.21]

GUI Improved: save the heights of task list pane and Torrent History pane separately

GUI Bugfix: Auto-Shutdown at specified time does not work

GUI Bugfix: open URL using system default browser instead of IE

GUI Bugfix: torrent file icon should not use the program icon

GUI Bugfix: when adding new Torrent, all files will be downloaded instead of only selected

GUI Bugfix: task position in the task list should not be changed when press Home/End

GUI Bugfix: the setting of View - Task list - Show filter does not work when program starts

Based on the stable version v1.30

bitC.png

2

“Move up” and “move down” arrows for task scheduling are grayed out and do not function, in this release.

3

It works for me…you might have accidentally installed previous version,because those weren’t working in the last version.

4

Nope, it says it’s the 12/07 beta, so not much doubt about that.

5

I can confirm they are greyed out, using Win7 x64.

Any other windows versions showing this?

6

you are telling about the arrows which used for moving task up and down right?if so see it isn’t grayed out here(check the version) I’m on windows 7 ultimate SP1 (x64) and I’m using BitComet 64 bit version

/monthly_12_2011/post-54333-13236855797355.png" rel=“”>

7

1.31 is released.

Is your task list ordered by any column? You have to deselect that order for the buttons to become active.

8

Nope, on WinXP they are not grayed out.

9

I didn’t order the list by column, but observed that when I went back to 1.25, they were still grayed out. Playing around with various column sorts eventually made them come back, so something must have done that.

10

I vaguely recall this bug before… not sure when, but I think it’s back. Lets call it the "sort by columns bug, where if you click on some columns, you can no longer use the up/down arrows until you resort by name.

Ariel, can you please confirm this and report it to the team?

11

But this isn’t a bug, TUUS.

BitComet has three sorting states for EACH column:

  1. none (this is basically the same as the order in which they were added to the Tasklist) which is the DEFAULT

  2. descending

  3. ascending

Once you sort by #2 or #3 in any column, it only makes sense to gray out the move buttons and disable the same moving function for the key combos on the keyboard, since the application cannot know in WHICH POSITION you would like to move the selected task(s), given the fact that most, if not all of the tasks, change their visible position once they are sorted.

But this happens only visually, so that it can present the list to you in the order you wanted at that point; it doesn’t reshuffle, internally, the task entries in downloads.xml, so #1 is still the only sorting order that the application uses internally. At least that’s my take on it.

Therefore, this is normal behavior.

I can’t think of an alternative better one under the circumstances.

12

I dunno, it seems pretty obvious to me that you’d want to move the task as displayed, to a higher or lower priority. Should there be a “write” button? (Sort it like this. Now write it. Good. Now this’s the new default. Move this task up, up, up, there.) Always going back to an unchangeable default state doesn’t make much sense to me, but disabling functionality this way makes even less.

13

Maybe not a bug, but certainly “user friendlyness” issue just coined a new word lol

It would be nice if clicking on the up/down arrow would rest the sorting to “name” column, because anyone clicking there would expect such an action, don’t you agree?

My only point is a novice user would look at them grayed out and not have a clue how to enable it. Adding a popup tip would be complicated since most users would only get confused if we try to explain all the functions, something that simply works when clicked, without causing other problems would be a big improvement.

14

Well the default state of the downloads.xml has always been “sorting by time of task creation”.

Just look into the .xml file and you’ll see.

Up until now, in every version the sorting function was only a “display” function. It changed the way the tasklist was displayed while the sorting command was enabled, but it never re-wrote the downloads.xml file.

That’s the way it’s built.

If you want all the standard BC behaviors to apply to a different sorting mode (e.g. by name, size, etc.) then you’ll probably have to make a feature request that the devs introduce an option which allows you to define any column as the default sorting criterion. This would mean that all the existing tasks as well as any new task you add to the tasklist will be written in the .xml file based on the criterion you chose. Then you could rearrange the tasks in the list based on YOUR preferred sorting order.

But even in that case you definitely can’t expect the moving function to work for any other sorting criterion you choose, that is OTHER than the one you chose as default. It just doesn’t make any sense. It would mean that the program has to rewrite the downloads.xml file in a different order AS SOON AS YOU APPLY any new sorting command, so that it can then move the task inside that new “environment”.

I definitely wouldn’t appreciate that kind of random and intrusive behavior (e.g. if I forget the Task List sorted by some criterion **other **than my preferred default one and decide to inadvertently move a task - let’s say at the end of the list-, then when I revert back to my default sorting mode that task I moved will end up in an entirely different part of the list).

15

Currently I need to click on any collumn three times to cycle through the sorting and return back to where the up/down icons are active. Couldn’t a click on the icon be coded to cycle the sorting until active (if necessary), then move the task.

16

TUUS, wiz is right. This is not a bug, the prior versions all work in this way.

The dev team leader says if you choose to sort the tasks by certain column, then it make no sense to enable move down/up. If users want to arrange the list by themselves, then they change it when the list is arranged by creation time.

And to enable move up/down when you choose certain column sorted may involve more tech problem on realizing it.

Your idea that a quick button for default order is forwarded to the dev team. :slight_smile:

17

I’m afraid I simply disagree: it makes perfect sense to me.

Sort it by name. Ok, now that it’s sorted by name, move THIS task ahead of THAT one and do it first.

Sort it by size, do the smallest tasks first. Well, except for that one task, there are no seeders, so move it down to the bottom and we’ll hope some seeders show up eventually. (This is actually a frequentlly -encountered situation for me.)

Sorting is often just the first step in a process, and I frequently want to rearrange the task list after that.

Wiz, let’s say that the list is untouched. Then I select tasks and move them around to suit myself. Doesn’t this new order have to be written to downloads.xml, or handled in the same way? It seems like the same issue to me.

18

Thank you Ariel. I can see it’s a design choice, not a bug, but what makes it look like a bug is there is no easy way for a user to figure out why the buttons are gray (inactive), they’d have to do a lot of clicking randomly to figure out how to enable them, and the average user might thing the software was buggy if they sometimes see them active, other times gray, and not understand why.

19

@ Kluelos: I’m not saying that this is impossible to do. What I’m underlining here is the fact that the application must have a “default” INTERNAL sorting order of the list.

That internal list file can only be one of these:

A predefined not changeable one (as it is at present time), in which case all the sorting commands will act only on a displaying level without re-writing downloads.xml

A USER predefined, changeable one (this is what I was suggesting in my previous post) in which case the user would need some button/option to set a certain sorting mode as default (with the obvious result of rewriting BC’s INTERNAL list in downloads.xml based on the chosen sorting mode - e.g. you choose “sort by name” as default then downloads.xml has to be rewritten in this order). In this case the buttons would still need to be grayed out when you switch into another sorting mode other than the “default” you chose.

A totally volatile and instantly changing list (pretty much what you propose in your last post) in which case the program would have to instantly rewrite downloads.xml as soon as you switch to a new sorting mode. This one I don’t particularly enjoy UNLESS I had an option to revert back to a “default” mode since, as I explained above, if I forgot the list in a “sorting mode” other than my default (at present time the only default is “sort by creation time”) then I’d inadvertently mess up my list, on a constant basis.

If the last case (which you advocate) were the reality in BC, how would you benefit from that on long term? I’m not entirely clear on the benefits.

You say you may sort by size and arrange it in a certain way, that suits your preferences, right? But then if you sort it by other criteria and REARRANGE it again for good (meaning the program actually rewrites downloads.xml in this new sorting fashion) won’t that render all your previous “arranging” work useless?

I mean, if every new sorting and subsequent moving operation has to rewrite downloads.xml and I worked really hard to arrange my list in a certain way, as soon as I start sorting by other criterion, I won’t have any means of reverting back to the previous “arranged” state, since downloads.xml is re-written now.

I can see how this would introduce new hassle of keeping temporary or duplicate copies of the tasklist file, or even asking you when you exit which “variant” of the tasklist you want to keep.

As I said, if you really think that #3 is beneficial just make a request but I’d have to at least ask for an option to be able to revert to #2 or #1 mode, as to me is much more convenient.

@ TUUS: Perhaps a better option would be to leave the buttons enabled even in “sorting mode” but when you click on them to receive a message of the type: “You need to disable sorting in the TaskList in order to move any task!”

20

I would certainly defer the question of when downloads.xml should be written. I am assuming that the list exists in RAM, and that rewriting it there is trivial. When it should actually be persisted out is up to the programmer, just as it always has been.

I do not feel that the decision to ever gray-out the move-up and move-down buttons has ever been adequately justified in the first place, and that the correct answer here is “never”. In that case you don’t have anything to explain or even justify.