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 111311 - Improper behavior of "cut" in design mode
Summary: Improper behavior of "cut" in design mode
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 6.x
Hardware: All All
: P4 blocker (vote)
Assignee: issues@guibuilder
: 185791 (view as bug list)
Depends on:
Reported: 2007-07-28 23:34 UTC by ahristov
Modified: 2010-05-11 09:40 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description ahristov 2007-07-28 23:34:08 UTC
In design mode, the "cut" operation doesn't remove the component and instead prefers to wait for the corresponding
"paste" in order to perform its action. However, this behavior is incorrect. A typical scenario:
Create a panel and place, say, a label inside.
Apply "cut" on the label.
Delete the panel (the label gets deleted since it still lives within the panel)
Now try to paste the label you cut before. Nothing happens (but *should*)

Another example:
Create panel + label
Cut label
Click outside
Undo (the Paste operation is reverted)
Click outside
Paste (nothing happens, but should)

This behavior is not only incorrect, but also incoherent with the rest of the Netbeans UI elsewhere.

The proper behaviour would be to put the label in the clipboard and remove it in the very same moment "cut" is applied
instead of waiting for something more to happen.
Comment 1 Tomas Pavek 2007-07-30 15:32:12 UTC
Removing the components requires lots of updates (internationalized resources, event handlers, etc) that are hard to 
revert and actually unnecessary when the component is added back to the form. Also remembering all layout information 
in clipboard would be needed. We had this in the past, but changed it due to all the problems. That's why we have the  
cut/paste operation now implemented as one "move" operation. It is consistent e.g. with the project explorer. I think 
it doesn't really limit anybody from doing anything. The two examples you mentioned have easy workarounds.
Comment 2 ahristov 2007-07-30 22:40:10 UTC
Sorry, I don't share such a way of reasoning. It's quite a usability issue when half of the IDE does not behave like the
other half, and evenmore - when it does not behave like *all* other Windows apps do (all that I've seen, at least). So
it's WONTFIX because ... "it's hard to fix"? :-/

Yes, probably removing components is a lot of trouble and stuff, but probably not more than the troubles of any other
IDE (Java or not) or software (Java or not), and yet they do it PROPERLY. The current implementation is purely and
simply a hack and it's buggy. 

Lower the priority, set the target to "future", do whatever, but saying that you (Netbeans) have decided not to correct
this hack "because of problems in the past", instead of fixing those very problems and following the established
convention doesn't seem neither like the best way to go nor does it sound very promising for people asked to rely on
Netbeans. These kinds of replies are not what is expected when Roman Strobol comes to Javalobby asking for feedback on

Comment 3 ahristov 2007-07-30 22:50:52 UTC
Sorry, I'm not done yet. If "it has a workaround" and "it doesn't really limit anybody from doing anything" are going to
represent the quality target that the Netbeans team has set for themselves, then I guess trying to use it and reporting
bugs is next to worthless and I should stick with the easiest workaround of all: using something that works properly
(Eclipse) and where reported bugs get quite a different treatment (at least those reported by me). 
Comment 4 Tomas Pavek 2007-07-31 18:03:16 UTC
Sorry, I just thought this was not such a problem. The fact cut/paste does not delete the component did not seem to me
as a serious issue affecting the quality. I agree the current behavior is a bit nonstandard, but we've been having this
behavior for several releases and nobody really complained about it. I'd rather expect some discussion raised on nbusers
or nbui before filing this as a defect.

We can have this issue opened, but will hardly have time to do anything about it for 6.0. We can see how many votes this
issue can gather.
Comment 5 Petr Dvorak 2008-04-29 15:02:52 UTC
ahristov said:

"when it does not behave like *all* other Windows apps do (all that I've seen, at least)"

Hmmm, nice - you are not a very experienced PC user, are you? If you have a Windows, open a Windows Explorer (Start >
Programs > Accessories > Windows Explorer). Select some folder, invoke "Cut" action from the pop-up. The folder does not
disappear (just the icon seems to be 50% transparent). Invoke "Paste" somewhere else. The folder is copied and then
removed from the original location.

The behavior you consider incorrect is absolutely standard behavior in any situations where data consistency needs to be
assured and where the memory requirements might be too high for normal PC's to work flawlessly. Thus I disagree with
tpavek that he "agrees the current behavior is a bit nonstandard". It is 100% normal from the usability point of view
and there is no strong reason to change it.

My last point would be that IMHO the current behavior is in no way affecting the quality of NB as you say. Your use
cases describes some behavior, but the behavior you consider incorrect is correct and expected too. The mentioned
"workarounds" are so simple and natural, that they cannot be considered as any problems for the usability.

Closing as WONTFIX.
Comment 6 ahristov 2008-04-29 21:03:19 UTC
Actually, I've been into IT and computing way before windows AND YOU were born, thank you. Your puny adhominem is so
blatantly wrong that I won't waste any time discussing it with you, especially considering that there's a legion of
applications and usability standards proving you wrong should you have the time and desire to look further than your ego.  

The excuses about data consistency et all for not fixing this *bug* are laughable at best, considering that the
operation of cut has been a standard even before GUIs, in as "lowly" applications as plain text editors back in the
early 80's.  For example, read carefully what "cut" does in this Apple design document of *1980*
(, or the definition of Cut in Microsoft's Interface
Guidelines For Software Design, dated 1995. Nah, I'll even paste it for you: "For a command method transfer, remove the
selected object visually when the user chooses the Cut command (...) The user will expect Cut to remove a selected object"

There's a very specific reason why file managers do what they do for cut operations, but I'm certainly not into teaching
opinionated kids. 

I'm reopening the issue, but I personally don't care anymore.  You don't want to fix it and prefer to 'redefine' black
as white? Fine. Good Luck to you. 
Comment 7 Jiri Vagner 2008-04-30 08:05:09 UTC
tpavek said :
" ...That's why we have the cut/paste operation now implemented as one "move" operation... "
" ... I agree the current behavior is a bit nonstandard ... "
" ... we can have this issue opened ... "

So this issue IS DEFINITELY VALID. Yes, we can discuss about priority and impact of this problem, users from community
can vote for this issue, ... but closing this issue with so arrogant and vain comment is counter-productive. We will not
improve nb, we will lose community member. :(
Comment 8 Petr Dvorak 2008-04-30 09:28:45 UTC
Hi ahristov,

first of all, I apologize for the remark I made in the beginning of my last comment. It was definitely wrong to start
the comment the way I did. (Now I just hope you will have problem only with "joshis" user and not with NB - as I am
small fish in the NB pool. ^_^)

I have discussed this issue with a few folks around me and we agreed it should be left opened. The behavior of CUT
operation in Visual Design could be (in time) enhanced in the way you propose.

Finally - I like the fact that you reopened the issue - you made me really thinking about the problem and proper
functionality of CUT operation. I also thank you that you replied to my (not very nice) remark in a constructive way,
providing many additional information.

So if I could make a constructive proposal this time, there might be the way (lets say a "shortcut") how to change the
"real priority" of this issue so that the behavior changes in some new version of NB. The reasoning is as follows:

The functionality of CUT works and can be used well with trivial workarounds - thus it can be hardly considered a high
priority bug. However, maybe it could work even better - the priority of this as an enhancement is much higher...

Therefore, I suggest following, (please let me know if you agree/disagree/don't care anymore(hope not), ahristov - we
can also discuss it on

1.     change the issue from DEFECT to ENHANCEMENT
2.     set the priority to P2
3(!!). paste additional links about usability standards (i.e. those you have mentioned) in a comment

Would you please help us by providing some additional links, ahristov?

Comment 9 Quality Engineering 2009-12-21 06:06:57 UTC
This bug was reported against NetBeans IDE 6.0 or an older release, or against a non-maintained module. NetBeans team does not have enough resources to get to this issue, therefore we are closing the issue as a WONTFIX. If you are interested in providing a patch for this bug, please see our NetFIX guidelines for how to proceed. 

We apologize for any inconvenience.

Thank you.
The NetBeans Team
Comment 10 Jan Stola 2010-05-11 09:30:40 UTC
*** Bug 185791 has been marked as a duplicate of this bug. ***
Comment 11 xandrani 2010-05-11 09:40:30 UTC
@comment#1 "Removing the components requires lots of updates":

I worry that developers seem to be running the show with NetBeans development.  Just because an issue is "hard to fix" doesn't mean it shouldn't be fixed in order to improve the quality of the product.

There should be a project manager who runs the whole show and who communicates with someone who specialises in user interface design.  A user interface design has priority over a developer in regard to user interface design issues (as that's there job), developers of course should have final say on implementation of the code.  I wish people would remember their jurisdiction in regard to design decisions.

You wouldn't get a car mechanic telling a professional chef how to cook a good risotto, and the same should be true in this case.