[New] BitComet Beta [20111207] has been released

[zerojinn]

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

[kluelos]

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

[puttachinku]

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

[kluelos]

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

[The UnUsual Suspect]

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

Any other windows versions showing this?

[puttachinku]

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

[Vasy]

1.31 is released.

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

[greywizard]

Nope, on WinXP they are not grayed out.

[kluelos]

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.

[The UnUsual Suspect]

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?

[greywizard]

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.

[kluelos]

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.

[The UnUsual Suspect]

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.

[greywizard]

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).

[The UnUsual Suspect]

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.

[zerojinn]

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. :)

[kluelos]

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.

[The UnUsual Suspect]

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.

[greywizard]

@ 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:

1. 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
   
2. 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.
   
3. 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!"

[kluelos]

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.

[The UnUsual Suspect]

I think the point is, average novice user will not understand why they are grey and assume either the app is broken, or not user friendly. Currently the only way to solve the problem is to click about until you randomly find the combination that works, or spend hours reading documentation. I think there must be a way that it can be made so simply clicking on the up/down arrow resets the columns to default and makes it work... we need this to be simple point and click, something so basic as moving a task shouldn't require any reading IMO.

[greywizard]

I never implied, when referring to writing downloads.xml, about writing it to disk. I was actually mainly referring to rewriting it in memory, where it's loaded.

Even though, with what you propose, at the very least it would need to be rewritten at program exit.

Given the way the tasklist works now (i.e. the one explained at #1) the gray-out of the buttons is perfectly justified from a programming standpoint, even though it isn't the only possible method.

As TUUS points out, it may not be the most intuitive solution for the user, but some form of informing him that the action is not possible while in sorting mode, need be in place.

In order for the application to work as you wish #3 or at least some form of #2 would need to be in place. If you think at the process from a programming point of view, you'll quickly come to agree on that.

Again, I'm not against what you wish, as long as I'm given the choice to keep the current behavior of the application (i.e. have one default chosen sorting state for the tasklist).

I guess that in the end it's a matter of preference.

Feel free to ask the team for this feature.

[greywizard]

What you suggest, TUUS, doesn't make much sense from a logical point of view.

This is why:

If the list is sorted by some criterion and in that state the user chooses to move a task to another position, then the moving decision will have been made by the user based on the visual display of the list which is presented arranged by the sorting criterion. That means that if you see Task A in some position which you think it doesn't suit your needs and want to move it, you won't make your moving decision based on its REAL position in the task list. Get it?

If you reverted the tasklist back to default state (prior to having the look which made you think "I gotta move this"), you may even not want to move the task in the first place, because its REAL position would most probably be a totally different one in the list.

That's one reason why this is not feasible.

The second reason why this is not feasible (I repeat, in the current state of facts with the tasklist working as described at #1) is that when sorting, because BC doesn't rearrange the tasklist internally, it WON'T know WHERE in the ORIGINAL (unsorted) list to put the task which you want to move.

I'll just give you a simple example.

A. Let's say you have a tasklist made of these (in null sorting state, which is "task creation date/time"):

Linux Debian
Linux Knoppix
Linux Slackware
Linux Fedora
Linux Suse

B. If you sort it, let's say by name, you'll get:

Linux Debian
Linux Fedora
Linux Knoppix
Linux Slackware
Linux Suse

At this point you decide for some reason that you want Knoppix in the penultimate position of the list, while in sorting mode as described here at #B. So, you would try to position it here:

Linux Debian
Linux Fedora
Linux Slackware
Linux Knoppix
Linux Suse

Remember that at present time BC doesn't internally modify downloads.xml when sorting!

So, you moved Knoppix in the penultimate position of the list (which is after Slackware and before Suse in #B list).

If you moved Knoppix while in sorting mode (assuming that was possible) where should the program put Knoppix in list #A (which is the REAL internal list kept by BC in the memory and in downloads.xml when it writes it to disk)?

Should it put it between Slackware and Fedora (i.e. after Slackware) or between Fedora and Suse (i.e. before Suse)?

[kluelos]

I think the confusion is in the idea of a "sorting" state. I don't think this exists, except very briefly. The list is arranged however it may be at the start. Then it's sorted another way. This new way is now the new "real" way, there is no other. (Why should there be?). There is no going back to the "old" way it was arranged (short of a catastrophic restart). You can only go forward, based upon and starting with the list as it is arranged at this moment.

In databases, a "sort" usually refers to the way in which the records are physically arranged in sequence. Re-sorting involves a lot of disk activity, takes time, and takes the table offline because you've got to shuffle records around on disk. That's not really a consideration where, as here you're holding the entire table in memory and can rearrange it instantly. The alternative is an "index", a list arranged by some independent criterion. The index shows things in some order that is completely unrelated to the arrangement of records on the disk. The index, like an index in a book, is a list of pointers to pages or records. Rearranging the index doesn't involve moving any records.

What is the tasklist that is being shown by BitComet? I think you are assuming it's an index while I am assuming it is a sort -- that this is always the reading out of the physical arrangement, with the intent that it either has been or momentarily will be persisted out to the disk that way. Causing a change, however you do it, means a brief rearranging of the order of things in the one and only list involved, and then it;s back to reading out the (new) physical arrangement. Moving one record up or down at any time is allowed, and relatively trivial -- no more difficult after a sort than before.

The thing is, I haven't seen any indication that makes me think it would be an index instead of a sort.

[greywizard]

I think the confusion is in the idea of a "sorting" state. I don't think this exists, except very briefly. The list is arranged however it may be at the start. Then it's sorted another way. This new way is now the new "real" way, there is no other.

Well, this is the way you WISH it worked, kluelos.

What I've been saying all along is the fact that it DOESN'T work that way at present time.

You can get all the evidence you need by opening the downloads.xml file while the Task List is in the "unsorted" mode and then reopening it again when BC is in a "sorting" mode. You can even go as far as leaving the list in "sorting" mode then hitting the "Exit" button and then reopening the application.

The Task List will still be in the same "sorting" mode, but if you open downloads.xml you'll see that the file is keeping the same structure it had before you started sorting.

I.e. the only structure that downloads.xml will use is time of task creation irrespective of what you're being shown in the Task List pane!

That's all the evidence you need that we're talking about an "index" and not an actual reshuffling of the entries in the file.

Besides, if you go back to the beginning of the thread you can see that Ariel says the team confirms it to be that way.

So, the bottom line is that the way you WISH it worked and the way IT WORKS NOW are two different stories. :)

Therefore, it's rather pointless for us to keep discussing the "what ifs". It's more practical that you made feature request if you really want to see it working that way.

Anyway, personally, I like having a "default" arrangement of the list (namely, by time of creation) and being able to revert back to that from whatever other arrangement order.

So, if any changes would be made in the program in the direction you suggest, I'd still like to have the option to "enforce" a "default" mode if I want to, and not have the list be re-written every time I briefly sort by another criteria.

That's because for a list of 10-50 tasks it really doesn't make much difference what the sorting order is; you'll still be able to find what you're looking for rather quickly.

But I have about 900+ tasks in my list now, and having it reshuffled with no option of going back, every time I want to do a brief sort (let's say by uploading speed) would translate in a total nightmare for me.