This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 16339 - Gray icon badge on node which was cut
Summary: Gray icon badge on node which was cut
Status: RESOLVED DUPLICATE of bug 41087
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 3.x
Hardware: All All
: P4 blocker (vote)
Assignee: t_h
Keywords: UI
: 17900 23613 (view as bug list)
Depends on: 13003 29466
  Show dependency tree
Reported: 2001-10-08 14:14 UTC by _ lkramolis
Modified: 2008-12-22 09:49 UTC (History)
3 users (show)

See Also:
Exception Reporter:

Nodes before cut action. (3.56 KB, image/png)
2001-10-08 14:15 UTC, _ lkramolis
Nodes after cut action - with gray badge. (3.01 KB, image/png)
2001-10-08 14:16 UTC, _ lkramolis
Badge used over cut node. (68 bytes, image/png)
2001-10-09 08:14 UTC, _ lkramolis

Note You need to log in before you can comment on or make changes to this bug.
Description _ lkramolis 2001-10-08 14:14:40 UTC
In XML module we implemented support for gray icon badge on nodes of XML and DTD
documents, which was cut. Those nodes are not dirrectly removed, they are
removed from source just in time, when clipboard content is paste to target
node. Nodes which was cut to clipboard are visible because of gray icon badge
(see attached screenshots).
This behaviour is just on inner XML and DTD nodes. We think that this could be
very useful to have this support implemented in openide because of most nodes in
IDE have same cut behaviour, but user does not see, which nodes was cut into
You can look at implementation in XML module, class AbstractObjectNode
- methods activateCutIcon, deactivateCutIcon, clipboardCut. Its functionality
could be moved to AbstractNode and activated on subclass's demand.
There is still problem with fireOwnershipLost which is not called when user
sellect more then one node (bug 13003).
Comment 1 _ lkramolis 2001-10-08 14:15:35 UTC
Created attachment 2894 [details]
Nodes before cut action.
Comment 2 _ lkramolis 2001-10-08 14:16:30 UTC
Created attachment 2895 [details]
Nodes after cut action - with gray badge.
Comment 3 _ lkramolis 2001-10-08 14:31:50 UTC
Changed target milestone: 3.3 -> 3.4
Comment 4 _ lkramolis 2001-10-09 08:14:30 UTC
Created attachment 2907 [details]
Badge used over cut node.
Comment 5 _ lkramolis 2001-10-15 18:07:09 UTC
See discussion on nbui:
Comment 6 Jiri Rechtacek 2002-02-07 17:55:35 UTC
For me (after discussions with David S.) an implementation required a
lot of time (probable about 15mandays) which could inhibit the
implementation of other enhancements. We should deeply think out the
end-user assets vs. time factor. I vote for postpone in release 4.0.
The opinions are welcome.
Comment 7 _ lkramolis 2002-02-07 18:13:18 UTC
I agree that this is not user so important. But I think, it is very
nice feature, isn't it?

I cannot agree that it is so difficult. As I wrote, it is already
implemented in XML module (1 day) - just one class, about 30 lines. I
am aware, you should implement it more general - but just 1 or 2 extra
days, I think.
Comment 8 Jiri Rechtacek 2002-02-08 11:02:47 UTC
*** Issue 17900 has been marked as a duplicate of this issue. ***
Comment 9 David Simonek 2002-02-08 13:00:05 UTC
Libor, keep in mind that we're totally new to explorer impl. Your
estimate is simply wrong. Can anyone tell me why this is so important?
We have hundreds of more serious problems I think (look at the
plan.xml in core and you'll see).
Imagine typical use case: paste is always done immediatelly after cut
IMO, and moreover clipboard is always overwriting, so from UI
perspective, what left is that user knows that cut action worked ok
and objects was transferred to clipboard (which is good, I agree, but
then what about copy action? user sees still nothing..).
Still that sounds to me as "nice to have" and from our planning
estimate it looks that we don't have time to do it.
I'm changing target milestone to future, and we'll keep this as "if
time permits". Ok?
Comment 10 Jiri Rechtacek 2002-02-08 14:17:21 UTC
If time permits then nice to have in 3.4 yet.

Comment 11 _ lkramolis 2002-02-08 14:41:04 UTC
Dafe, you are right, my estimate was flaming - you can double it. :-)

You did not understand me. I did not say, you should implement it. I
just inform you, that I think, it is really simple to implement what
is already implemented in XML module.

I do not want to devise something new. I just tried to implement
similar behaviour as M$ Explorer has. Users wanted to know, which node
will be deleted, when you paste it somewhere.

Chris could help us to define such behaviour.
Comment 12 Chris Ledantec 2002-02-08 15:45:37 UTC
two things: 

1. when we have time to do indicate what nodes are cut it should be
done. this piece of visual feedback is extremely useful when working
on ranges of nodes in the explorer. but it has to be prioritized
relative to everything else that's out there. 

2. we should not introduce a new way of indicating this cut state. the
known behavior is to fade the icons out and that is what we need to
stick to. if we introduce a new way of indicating this then it adds to
what the user must learn in order to understand the environment. if we
do it in a way they are already familiar with then they will not
'notice' it as they are seeing what is expected.
Comment 13 _ gtzabari 2002-02-08 18:31:13 UTC
From Issue 17900: instead of overlaying a gray background on top of
the original icon I suggest fading out the original icon (ie: increase
its alpha value) so it becomes transparent. This will look nicer.
Comment 14 Chris Ledantec 2002-02-11 09:30:26 UTC
yes, making the selected-cut items look slightly transparent is what
we'd want to do. 
Comment 15 Jiri Rechtacek 2002-02-14 12:03:35 UTC
I have looked through the XML module implementation it looked
applicable in general (thanks Libor). This way is available for Copy
action too.
Note: there is a problem when a node is cut (will be marked) and then
a text is cut in editor e.g. later. A node is marked still but Paste
action on the node is correctly disabled.
Comment 16 Chris Ledantec 2002-02-14 13:19:08 UTC
indicating what is being moved only needs to be done on cut -it shows
that a certain group of things will no longer exist in that spot.
enabling it for copy is not appropriate.

and again, i want to stress that doing this with a badge is not the
best for the users. changing the transparency (making the icons look
faded) is consistent with what users know and clearly communicates
that the items are in 'limbo' as they will be moved on a paste command.
Comment 17 David Simonek 2002-02-14 14:33:28 UTC
Chris, sorry, I can't agree. Quoting:
"it shows that a certain group of things will no longer exist in that
Wrong. Correct is: "shows that a certain group of things *may* be cut
and then will no longer exist in that spot."
Which unfortunately is not that straighforward to present to the user
and I think that's the reason why AFAIK only one application in the
world (=windows explorer) has this feature. This is also reason why I
would better give up. Or to do things completely, not halfway - I mean
give correct UI for whole cut/copy/paste story.
The reason I want to do something with copy is that copy action also
violates one of main UI rules - to give feedback to the user. How am I
supposed to find out if my copy action was succesfull? And it's the
same for copy and cut, only difference is what will happen when paste
is performed.
Comment 18 Chris Ledantec 2002-02-14 15:01:12 UTC
copy does not need to give feedback to the user bcs the original
location of the data is not being modified. cut is potentially
modifying the original location and so the feedback is critical.

think of it like having a stack of paper (with the same thing on each
piece). if you pick up the entire stack you can still put it back
where it was (cancel the operation) or you can put it somewhere new.
presenting a faded icon shows right where that stack was and that it's
been picked up. if you just pick up one piece off the stack you've now
got a duplicate of the stack that you can put where you want, but you
haven't done anything to the orginal location of so you don't need a
marker of where it was.

that is the complete cut/copy/paste story.

you said: "shows that a certain group of things *may* be cut
and then will no longer exist in that spot." but that isn't entirely
true. by clicking 'cut' or pressing ctrl+x the use has cut the data.
the stack of paper has been picked up from its original location.  the
faded icons remind where it was (should the user want to cancel) and
what is in it (again to let the user know if it should be canceled or
to help remind where it was going to start with). the operation isn't
finished until paste puts it all down again, but then, when moving a
stack of paper you aren't done until you put it down again either.

we're boats in the night on one little detail. if i understand you,
you're looking at the difference between cut and copy as indicating a
different result for paste (delete the orginal or nor). i'm
approaching it from the point of view that paste always does the same
thing (it puts what i've got into the new location) but cut and copy
do different things (one picks up the original and one copies the
original). it's a subtle difference but it might be why we aren't eye
to eye yet. 

have i clarified my point of view or just made things worse? :-)
Comment 19 David Simonek 2002-02-14 17:08:49 UTC
hmm, yes, I understand. But still, copy should produce some visual
output as well (in metaphor with papers, you can see that something is
copying).  For example change mouse cursor to waiting state for the
time when object is being transferred to clipboard (and then back)? 
Comment 20 Chris Ledantec 2002-02-14 17:19:39 UTC
if the process of copying stuff to the clipboard takes a while, then
yes, we should indicate that to the user... this is a more general
problem throughout the ide: there are several places where showing an
hourglass would communicate to the user that some action is
happening... though this is a slightly tangential issue. ;-)

it might be nice to have some kind of generic mourse badge that says
there's something on the clipboard...? this is definitely Bruce's
(graphic's) realm. i've added him to the cc list for more insight.
Comment 21 David Simonek 2002-02-14 17:31:16 UTC
hm, I thought of it too, but problem is that there is nearly always
something in clipboard, as paste operation doesn't clear it. too bad.
Comment 22 Marek Grummich 2002-07-22 11:27:27 UTC
Set target milestone to TBD
Comment 23 Marek Grummich 2002-07-22 11:28:55 UTC
Set target milestone to TBD
Comment 24 Jiri Rechtacek 2002-07-26 13:38:41 UTC
*** Issue 23613 has been marked as a duplicate of this issue. ***
Comment 25 Jiri Rechtacek 2004-04-23 10:45:47 UTC
Assigned to new owner.
Comment 26 _ tboudreau 2004-05-02 13:18:35 UTC
Once I commit the lightweight HTML renderer tomorrow, this issue should be perfectly 
doable.  We should consider this for promo D.

Hard part:  How to detect, when painting, that a node has been cut, so as to alter the 
display name text before it is rendered.  I suspect that checking with the clipboard to see 
if each node is on it as we paint would be unacceptable, performance wise, and not clear if 
one could differentiate between cut and copy in that case.

What might work, but would have to be done very carefully, is to use Node.putValue/
getValue to put some marker into the node when it is cut.  This would also mean 
remembering to clear this value in any of the many circumstances that could require it 
(external clipboard changes, internal clipboard changes, one of the cut nodes destroyed, 
etc., etc.).

Or some kind of hashmap that can hold whatever has been cut.
Comment 27 _ tboudreau 2004-05-02 13:20:16 UTC
For that matter, this could always have been done in NodeRenderer - you don't actually 
need html, just call renderer.setForeground (UIManager.getColor("controlShadow")).
Comment 28 Antonin Nebuzelsky 2008-02-07 16:07:35 UTC
Reassigning to new module owner Tomas Holy.
Comment 29 t_h 2008-10-20 13:12:51 UTC

*** This issue has been marked as a duplicate of 41087 ***