Red Hat Bugzilla – Bug 502437
add links without checking loses data
Last modified: 2013-03-13 01:44:04 EDT
Description of problem:
If you click on add without clicking check links first, tucan throws away all your links.
i should close this, because it's a feature request
upstream think this is the best way to teach users to use paste -> check -> add
there will be a error popup in 0.3.8
i will close this bug with the next version update
While close to tray might be a feature request and as we agreed on IRC, this most certainly is a bug. It results in direct data loss. You should try and convince upstream to change their methods and not induce data loss in their applications.
Data loss is a incentive to not use the application again ever and shouldn't be used as a method to encourage any particular behaviour. A simple and effective way to do this is to not have a separate check links button but just have a add button and automatically check links in the background instead similar to say how bittorrent clients work. Why offer the choice if nobody is supposed to use it?
imho, if upstream knows that the app loss data on wrong use, and they want to do it in this way, it isn't a bug. It's a stupid behavior of the application and a bad solution of upstream to teach users in their thinking how the user should use the application.
I discussed with upstream a few weeks about this problem and now they are doing it with an errorpopup.
should be in their svn, check it out and update to it. Test it if you like it or not.
(In reply to comment #3)
> should be in their svn, check it out and update to it. Test it if you like it
> or not.
Sorry Simon, but as a maintainer this is clearly your duty. You are maintaining an app that suffers from data loss, so you should work togehter with upstream as closely as possible to avoid this. Test the latest SVN and if it fixes the issue, go cherry picking to apply the changes.
(In reply to comment #3)
> imho, if upstream knows that the app loss data on wrong use, and they want to
> do it in this way, it isn't a bug. It's a stupid behavior of the application
> and a bad solution of upstream to teach users in their thinking how the user
> should use the application.
Regardless of what upstream might think, throwing away data is clearly a bug.
> I discussed with upstream a few weeks about this problem and now they are doing
> it with an errorpopup.
That isn't ideal but way better than the current state. Can you please backport the change and update the application or ask upstream when their next release is?
(In reply to comment #4)
> Sorry Simon, but as a maintainer this is clearly your duty.
I work together with upstream on this issue since a couple of weeks.
upstream is in a transition atm and I will package the new stuff when it's ready, so users of rawhide can try it. I don't want to add incomplete stuff.
(In reply to comment #5)
> That isn't ideal but way better than the current state. Can you please backport
> the change and update the application or ask upstream when their next release
The next update is after testing the upload plugin and this issue...
Please say what is ideal for you, then i can carry your wish to upstream.
Ideal scenario - no explicit button for checking links. One button for add which automatically checks the links in a separate background thread and not in a modal dialog box.
this is my optimalbehavior of this app, too
but upstream says it would destroy their thinking how the app should work..
Well, that's just sad but whatever prevents data loss would be a acceptable compromise.
"stupid behavior": paste links -> check links -> add links
Having a separate "check links" button means flexibility:
1. If you find any offline links when checking, you can cancel and paste new links.
2. You can change the name of links on the treeview after checking and choose which links to add.
I agreed with cassmodiah about the popup dialog if there is nothing to add, because information is always useful.
I bet anyone who has added before checking has open again the input links dialog and checked the links, it isnt a weird behavior.
As I already indicated, doing this whole checking in a separate thread would solve all your use cases rather neatly.
1) If you do checking in the background, you can still cancel and paste new links or even better, no need to cancel but just continue adding more links if needed.
2) Again, same thing
Throwing away data and asking the user to add them back again is silly. Software should always strive to preserve data. If I add 30 links from different sources, close them since I have already added them to this program and then click on add and having it lose all the links, going back and figuring out all the links back is not easy. This isn't even a theoretical scenario. Don't throw user data away unless the user explicitly chooses to do so. Period.
With the popup there is no more data loss.
We do the check on a separate thread, from the start, that isnt the problem here.
Any button on the action area, except for help, should close the dialog.
This is a 3 step process, like it or not:
1. Paste links on the textview and check them with the check button. All this is on the same frame.
2. Select the links you want and change their names if you need. Also on its own frame and under it is the option to advanced packages.
3. Add the checked links to tucan or cancel. This is on the action area which should close the dialog.
With the popup added, there might be no data loss. I haven't seen the behaviour yet so can't comment on that but still find a explicit button for checking very awkard. I haven't seen any other download manager have a UI like that. None of the torrent clients or download accelerators have a explicit button for it. They also do the checking and do it automatically. I still don't see how this one is any different. Checking of links is a mere implementation details users wouldn't necessarily care. So this could very well be just a two step process.
1) Add links - it will queued for downloading and checking will happen automatically
2) Edit the name if needed.
That appears much simpler to me. You can look at say transmission torrent client which has a very streamlined UI that does this. If you want to get some expert help on having good user interaction, I suggest Fedora design list
The problem is solved, so the bug report should be closed.
If you think the current behavior is awkward its your opinion, i havent looked at how others do, but i have read the HIG and there isnt any contradiction.
This isnt the place for discussing design decisions.
The bug report might be solved upstream but the latest version in Fedora still has this bug. So until the point where a backport is made or a new upstream release is pushed as an update, it should remain open. I agree that design decisions are a bit off topic for this bug and recommend the fedora design list instead.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
tucan-0.3.8-0.1.alpha.fc11 has been submitted as an update for Fedora 11.
tucan-0.3.8-0.1.alpha.fc10 has been submitted as an update for Fedora 10.
it would be nice, if you give a karmapoint to the update. (after testing of course)
tucan-0.3.8-0.1.alpha.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update tucan'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7867
tucan-0.3.8-0.1.alpha.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update tucan'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7877
tucan-0.3.8-0.1.alpha.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #21)
> tucan-0.3.8-0.1.alpha.fc11 has been pushed to the Fedora 11 testing repository.
> If problems still persist, please make note of it in this bug report.
> If you want to test the update, you can install it with
> su -c 'yum --enablerepo=updates-testing update tucan'. You can provide
> feedback for this update here:
I verified and confirmed that it fixes the issue. I don't like the method in which the fix has been made upstream but atleast this particular data loss problem has been resolved. In the course of testing it, I found another one and will be filing it as a separate bug. Thanks for fixing this.
tucan-0.3.8-0.1.alpha.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.