Bug 16339

Created attachment 2894 [details]
Nodes before cut action.

Created attachment 2895 [details]
Nodes after cut action - with gray badge.

Changed target milestone: 3.3 -> 3.4

Created attachment 2907 [details]
Badge used over cut node.

See discussion on nbui:
http://www.netbeans.org/servlets/ReadMsg?msgId=165730&listName=nbui.

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.

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.

*** Issue 17900 has been marked as a duplicate of this issue. ***

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?

If time permits then nice to have in 3.4 yet.

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.

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.

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.

yes, making the selected-cut items look slightly transparent is what
we'd want to do. 

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.

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.

Chris, sorry, I can't agree. Quoting:
"it shows that a certain group of things will no longer exist in that
spot"
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.

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

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

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.

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.

Set target milestone to TBD

Set target milestone to TBD

*** Issue 23613 has been marked as a duplicate of this issue. ***

Assigned to new owner.

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.

For that matter, this could always have been done in NodeRenderer - you don't actually 
need html, just call renderer.setForeground (UIManager.getColor("controlShadow")).

Reassigning to new module owner Tomas Holy.

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