Bug 502437 - add links without checking loses data
add links without checking loses data
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: tucan (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Simon
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-25 05:32 EDT by Rahul Sundaram
Modified: 2013-03-13 01:44 EDT (History)
4 users (show)

See Also:
Fixed In Version: 0.3.8-0.1.alpha.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-23 15:04:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Debian BTS 531392 None None None Never

  None (edit)
Description Rahul Sundaram 2009-05-25 05:32:44 EDT
Description of problem:

http://tucaneando.files.wordpress.com/2008/11/checking.png

If you click on add without clicking check links first, tucan throws away all your links.
Comment 1 Simon 2009-05-28 17:23:20 EDT
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
Comment 2 Rahul Sundaram 2009-05-29 01:18:04 EDT
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?
Comment 3 Simon 2009-05-29 05:59:50 EDT
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.
Comment 4 Christoph Wickert 2009-05-29 07:35:27 EDT
(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.
Comment 5 Rahul Sundaram 2009-05-29 07:49:34 EDT
(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?
Comment 6 Simon 2009-05-29 08:08:29 EDT
(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
> is?
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.
Comment 7 Rahul Sundaram 2009-05-29 08:41:18 EDT
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.
Comment 8 Simon 2009-05-29 09:18:16 EDT
this is my optimalbehavior of this app, too

but upstream says it would destroy their thinking how the app should work..
Comment 9 Rahul Sundaram 2009-05-29 11:39:57 EDT
Well, that's just sad but whatever prevents data loss would be a acceptable compromise.
Comment 10 tucaneando 2009-05-29 20:31:16 EDT
"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.
Comment 11 Rahul Sundaram 2009-05-31 02:36:22 EDT
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.
Comment 12 tucaneando 2009-05-31 10:29:34 EDT
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.

BIG PERIOD.
Comment 13 Rahul Sundaram 2009-05-31 11:15:35 EDT
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

https://admin.fedoraproject.org/mailman/listinfo/design-team
Comment 14 tucaneando 2009-05-31 11:42:47 EDT
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.
Comment 15 Rahul Sundaram 2009-05-31 12:56:20 EDT
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.
Comment 16 Bug Zapper 2009-06-09 12:31:18 EDT
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Fedora Update System 2009-07-17 16:57:28 EDT
tucan-0.3.8-0.1.alpha.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/tucan-0.3.8-0.1.alpha.fc11
Comment 19 Fedora Update System 2009-07-17 17:07:43 EDT
tucan-0.3.8-0.1.alpha.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/tucan-0.3.8-0.1.alpha.fc10
Comment 20 Simon 2009-07-19 08:31:40 EDT
@rahul
it would be nice, if you give a karmapoint to the update. (after testing of course)
Comment 21 Fedora Update System 2009-07-22 17:55:43 EDT
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
Comment 22 Fedora Update System 2009-07-22 18:00:52 EDT
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
Comment 23 Fedora Update System 2009-07-23 15:04:09 EDT
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.
Comment 24 Rahul Sundaram 2009-07-23 15:08:17 EDT
(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:
> http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7867  

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.
Comment 25 Fedora Update System 2009-09-18 20:07:29 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.