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.
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 Paste 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.
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.
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 Netbeans.
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).
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.
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.
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* (http://www.guidebookgallery.org/articles/lisauserinterfacestandards), 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.
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. :(
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 joshis.czech@gmail.com): 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? Document1: http://www.guidebookgallery.org/articles/lisauserinterfacestandards
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
*** Bug 185791 has been marked as a duplicate of this bug. ***
@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.