logo       

Bug#469964: marked as done (azureus: Zombie selection indicators: 'delete' : msg#03632

debian-bugs-closed

Subject: Bug#469964: marked as done (azureus: Zombie selection indicators: 'delete' removes item, but selection moves on.)


Your message dated Thu, 30 Jul 2009 15:36:05 -0400
with message-id <1248982565.4639.61.camel@desktop>
and subject line Fixed in previous versions
has caused the Debian Bug report #469964,
regarding azureus: Zombie selection indicators: 'delete' removes item, but
selection moves on.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@xxxxxxxxxxxxxxx
immediately.)


--
469964: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469964
Debian Bug Tracking System
Contact owner@xxxxxxxxxxxxxxx with problems
--- Begin Message ---
Subject: azureus: Zombie selection indicators: 'delete' removes item, but selection moves on.
Package: azureus
Version: 3.0.4.2-1
Severity: important


In 'My Torrents>Completed Torrents' left click to select some expendable
item; the item has a blue bar superimposed on it to indicate selection.

Right click 'Remove'. The item is removed, but the blue selection
bar remains -- but now another file is selected, one that the user
did not select. Worse, if multiple items are selected, say {1,4,8},
the same {1,4,8} selection pattern remains after a 'Remove'.

An illustration, using temp files in 'My Shares', (I haven't
any expendable torrents left). Before:

foo1
T foo2
T foo3
foo4
T foo5
foo6
foo7
foo8
foo9

Where 'T' means "tagged", or selected, these'd be blue. Now the user
does a 'Remove':

foo1
T foo4
foo6
foo7
foo8
foo9

...and 'foo4' is selected. In the 'My Torrents>Complete' list I observed
multiple tags remaining, an effect I couldn't reproduce in the 'Shares'
list.

(Standard file tagging/selection behavior, e.g. like in 'mc' or
'konqeror': if the user deletes a selection, the selected items
AND the selection indicator should go away -- unless the operation
failed.)

Justification for 'important' severity: users accidentally deleting
data -- when they see any remaining selection, they reflexively
assume it was something they selected, and they may delete it again.

Hope this helps...


-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages azureus depends on:
pn java-gcj-compat | java-virtua <none> (no description available)
ii libcommons-cli-java 1.1-1 API for working with the command l
ii liblog4j1.2-java 1.2.15-2 Logging library for java
ii libseda-java 3.0-3 the Staged Event-Driven Architectu
ii libswt-gtk-3.3-java 3.3.1-3 Standard Widget Toolkit for GTK Ja
ii sun-java5-jre [java2-runtime] 1.5.0-14-3 Sun Java(TM) Runtime Environment (

azureus recommends no packages.

-- no debconf information



--- End Message ---
--- Begin Message ---
Subject: Fixed in previous versions
Current Version: 3.1.1.0-4
Upcoming Version: 4.2.0.4-1

This bug was fixed in previous versions. If you feel you're able to
reproduce the bug in the new azureus-4.2.0.4 and still persists, then
feel free to reopen.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | Mail Home | sitemap | FAQ | advertise