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.
The GUI designer is constantly moving components in gratuitous and unwanted ways. Makes designing a form almost impossible. I'll submit a movie attachment of the behavior.
Created attachment 62335 [details] Movine of gratuitously moving components
Maybe upping the priority will get someone to actually even LOOK at this bug? It is significant, and makes actually designing anything almost impossible.
We are looking at it. Yes, the video shows some unwanted moves. OTOH it also shows you trying to do things that are simply not possible (e.g. making the labels and the slider slightly overlap - probably because the slider itself has a big invisible border which makes it bigger than it appears). We will analyze the video, try to reproduce the bugs and also give you some tips how to design such a layout.
Thanks for looking into this. I can provide video of simpler forms, without overlapping items, etc. where the movement of elements still occurs. Thanks!
Created attachment 63127 [details] Move two buttons, the whole frame resizes
Here's a movie of the Form designer itself doing things that you say are "simply not possible" i.e. making components overlap. The gratuitous movement of components makes the real-world use of the designer almost impossible.
Created attachment 65271 [details] New Movie of Bug in action
Created attachment 67347 [details] Gratuitous resizes and moves
This is really getting silly. It's a MAJOR issue, and I can see no evidence that it is being taken seriously. Maybe a public blog post on the matter with movies would have some effect? Makes it impossible to use Netbeans to design an application.
I have not seen movies, but since verion 5.0 of NetBeans, when Matisse was born (through 5.5, 5.5.1, 6.0, 6.0.1, 6.1), I had exactly the same problems (and all my friends from work). One bad move of mouse pointer could make a huge mess on a form. The only thing that can save your life is CVS/SVN, so you can always revert modifications and (gently) try to change something again, trying not to make Matisse angry, so it won't destroy your layout. The designer, however, works very well on simple forms, so everyone who was following tutorials but did not have to do anything >real< may be unaware of this issue. Long, long time ago I've lost my hope it will be fixed, as it looks like some major design bug, not some kind of trivial one. I see the light far away in JavaFX. I believe, there will be new, superb GUI designer for JavaFX in the future, and no one will use Java language to build forms, as this is so clear this language is great for everything but GUI.
Making simple moves on objects can cause the IDE to deform all other objects on the form, to the point where even going to Edit - Undo does not undo the changes the IDE made, thus ruining the form being worked on. As said before, this problem makes it practically impossible to design a form. I end up spending hours designing a form and half of that time is spent struggling and fighting with the IDE to get the form to look the way I want it to. My suggestion is to introduce options to completely turn off any sort of GUI help, along with other options for free-design, no auto-resizing, etc. An introduction of a new tab in the Options pane for the GUI helper would be most necessary. Furthermore I believe that this is a major bug as it applies to anyone wishing to design a GUI, which is quite a bit of people. It certainly deserves more recognition then it has gotten so far.
P5 is LOWEST priority. I bumped it up to P2 from P3, as I believe that may have been your intention. I certainly agree that it is a *major* bug that deserves attention, but I am not sure it will get it.
Is there *any* chance that this bug will ever get fixed?? Or should I just give up on NetBeans GUI builder? It is atrocious. Makes the GUI-builder unusable.
When I face this kind of thing, I try to reload form, what normally works. :(
That works (sometimes, mostly) to UNDO the damage, but I just spent 20 minutes with Matisse destroying/me un-doing the destruction, and what I was left with was ... the form in the EXACT stage I started. I cannot seem to move 5 labels/textFields 1/4" to the left. GUI Designer insists on re-arranging the entire panel and resizing the containing panel repeatedly. Blog post on the matter it is ... no movement in almost a year.
Some of the jumping around happens because the gui designer, to satisfy a placement you've done of a component, set a fixed "space around component". This could cause problems because when moving a component this extra space is not showed so you think that placing it "there" it's ok. To help people maybe the gui designer could do some of these things (random thoughts as i don't know how matisse works internally): - show the extra space occupied due do the "space around component" - if i move a component, reset the space around component and set it again to satisfy the new placement. I think that in most cases if i move a component the extra space around it loses its original meaning so it can be discarded.
Unfortunately we have no resources to work on this issue for NB 6.7. But please keep adding test cases where concrete problems can be reproduced. Even if we don't have resources for complex changes, we might be able to fix simple individual defects.
I didn't think it was possible, but it's actually WORSE in 6.7 than it was in 6.5.1. Whoever 'approved' the 'waiver' for 6.7 seriously messed up. This is unusable.
Created attachment 84938 [details] 6.7 version of bug
The movie of the 6.7 behavior shows the GUI designer doing things which are NOT SUPPOSED TO BE POSSIBLE: putting components ON TOP OF one another.
Seeing the last video, it really looks like something is broken, but I don't think any change in 6.7 could cause that, we barely touched the layout code. I believe you'd get the same with 6.5. I think there must be something wrong with the particular GUI form already before the recorded first move. Any chance you could share the GUI form (or possibly whole project), so we could play with it as is? Ideally in the state where you started the video. We need something real to test. It's still one specific example, not really P1.
NOT a single case. Read the comments in the bug. There are several others that have reported the bug. I will provide the entire source, but it is *easily* reproducible in *any* GUI-based project. If the NetBeans Engineers have been unable to reproduce it it's only because they haven't TRIED. I can reproduce it in EVERY GIU form, EVERY TIME. This is not a P2. It is a critical bug that makes the GUI Designer unusable.
Created attachment 84942 [details] SIMPLE project, where the behavior manifests. Movie of it to follow
Created attachment 84943 [details] Movie of SIMPLE project fail
I hopped you could rather attach sources for the previous case - that looked really broken, and seemed like some real UI. This last one is just about moving components around arbitrarily, the moves make no sense towards building some real/nice UI. Given the limited resources we have, we'd rather fix bugs that prevent people from creating real UI, not random moves that expose some weirdness after some time. I can surely create many such cases. The approach "fix it all" takes much time, fix what bothers most first seems more doable.
Fixed the last reported case where the layout collapsed so the components that should be on different rows overlapped. http://hg.netbeans.org/cdev/rev/4edb30dd1bca The main problem was that the buttons with big icons aligned on baseline with other components. Changed not to offer baseline alignment for buttons and labels that don't have text vertically in center. Made it possible to align at top or bottom. Also workarounded the case where such a button is removed from a baseline group (in an already existing layout) to prevent the collapse due to losing the height of the group.
Integrated into 'main-golden', will be available in build *200908260201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/4edb30dd1bca User: Tomas Pavek <tpavek@netbeans.org> Log: #136425: improving baseline alignment behavior
*** Issue 173752 has been marked as a duplicate of this issue. ***
Integrated into 'main-golden', will be available in build *200910140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/9e4e5cbcf9b0 User: Tomas Pavek <tpavek@netbeans.org> Log: #136425: additional fix of potential failure of deleting multiple components
Sorry if I'm wrong but this awful problem still exists in Netbeans 6.9! I can't find a fix for this problem in this thread... Is it me or the problem still exists?? What should we do? Try to place a component some where and make the looks of the form better and "BOOM" everything goes to hell! Using null layout is not an option... :( Why is it that the problem hasn't been fixed since 6.5?????? :-o Please... Do something about it. I always spend countless hours trying to arrange my components as Netbeans totally ruins my GUI! :( :( :( Thanks in advance ;-]
I have to agree with everyone that this bug makes the GUI builder useless. I find it almost insulting that the Devs have tried to say this is not a big deal and that it doesn't affect the design of real GUIs. I work in software developing and I have had to explain to my supervisors that I cannot properly make deadlines on GUI development because of the horrible problems with Matisse. I would much rather use Visual Basic which has a fully functional GUI builder lacking any of these problems than struggle for hours to develop a GUI in JAVA with Matisse.
This bug is anything but 'resolved' and whoever marked it as 'resolved' obviously doesn't use the GUI designer for real work. Considering this bug was filed against 6.5, and we are now at 6.9, I think it's safe to say that Netbeans is wholly uninterested in fixing this behavior. An honest "we have no intention of fixing this. Deal with it" would be preferable to the constant hand-waving and excuse-making.
I totally agree with Cjlaffe and santafen. This problem is nowhere near "Resolved" nor "Partially Resolved"! Makes me crazy... That's why I've totally switched to C# for a while and reached the conclusion that "with open source, there's ALWAYS a catch..."! I wonder why none of the NetBeans developers even take a look at this thread! :-? Have they even "tried" to create a good looking GUI with their handiwork?? Bet it's impossible for them too! :)) It's so ridiculous that we have to write the codes for the GUI parts manually (like ancient trolls! :-p) and we can't use NetBeans to design them... I think I'm giving up the hope that this problem will be ever fixed... :(
Oh my God! Unbelievable! The same thing happens if you use the JFormDesigner's "Free Design" layout! :-o :-o The Free Design layout is buggy as the JFormDesigner uses the same layout manager! What could be done?
Im pretty new to Netbeans and decided to use it because Visual Studios doesnt do J# and I am taking a class that uses it to teach us. Well with Netbeans I was trying to design the GUI and it was pretty hard to arrange things when the program wanted to move them for unknown reasons and it always keeps getting bigger. Resizing them again doesnt work for long and its hard to keep items in the position I want. I am using the newest version and I would post videos but everything that is happening to me is already posted above.
Don't even bother! As I mentioned before, I believe it has not to do with Netbeans. The problem is with the free design layout! I'm not wasting my time with Netbeans anymore! Why should I use Java when C# can get the job done faster and MUCH easier? Why shouldn't I use WPF and enhance the look and feel of my programs?! IMO open source is a dead end... Has let me down many many times already...
A bunch of issues were evaluated and put in a dependency tree of this issue which is now changed to an UMBRELLA. You can see the dependency tree of the identified problems here: http://netbeans.org/bugzilla/showdependencytree.cgi?id=136425 Should you encounter any specific case which has not been reported yet, please don't attach it here, but file it as a separate issue and mark it as Blocks: 136425 A general comment about this umbrella - we will never be able to fix 100% of cases you may encounter when moving components around arbitrarily - free design (GroupLayout) can never work as simply as plain absolute layout and it will always require the users to follow certain rules (brief description for now is at http://wiki.netbeans.org/FaqUnexpectComponentMove). We will be trying to fix the individual reports gathered here. Some of the known ones now seem to be fixed in a prototype we started recently, but that will not be ready in 7.0 timeframe.
Oh that's just awesome! Some attention after all! And guess what!? We have to stick to some crappy rules to get a complex UI designed! I really wonder how the heck they design UIs in Java without all these hassles!!! And guess what?? The issue is not going to be solved completely... How about not using a specific layout (such as Free Design) or something similar but assisting the designers via GUI Builder managed align lines and/or neat snap to grid features and stuff like these? Why don't we see anything like these in Visual Studio?! The most complex GUIs could be built in a matter of minutes in VS Designer! Oh and the XAML for WPF? It's just pure awesome...
Note there also is a grid-based layout, now improved: http://wiki.netbeans.org/NewAndNoteworthyNB70#GUI_Builder_-_New_GridBagLayout_Designer
(In reply to comment #39) I guess if you wish this kind of development, maybe you can use NULL layout. There is a lot of reasons to use layouts, the mainly is to make possible the UI works fine for any kind of OS, LAF and resolutions.
Or, in the case of the Matisse GUI Builder, to make sure that it's impossible to actually build a functioning GUI (other than one so simplistic as to be unusable in the real world). Hoping that this latest flurry of activity means this bug is actually being looked at finally, seeing as it was reported almost 3 years ago.
(In reply to comment #41) > (In reply to comment #39) > I guess if you wish this kind of development, maybe you can use NULL layout. > There is a lot of reasons to use layouts, the mainly is to make possible the UI > works fine for any kind of OS, LAF and resolutions. Thanks but I don't use the null layout for the same reasons you mentioned! The thing is in C# for example, the layout behaves like null layout but there are so many options to make the UI work in any resolution. I really like to see this bug fixed.
Task ?
Looking at the list of related bugs and having used the GUI Builder for a while, I can't help but wonder whether something is fundamentally wrong with the design of this feature. How about we build an extensive list of use-cases for GUI development and redesign the Human - GuiBuilder interaction around achieving those goals? If you try to simply fix individual bugs you will be spinning your wheels forever because the original design didn't seem to take them into account. Can you create a Wiki page and ask users to post their use-cases there? To be clear, by use-cases I mean something along these lines: Definition: Possible (snap) "targets": - Preferred or No space from the parent container's boundary - Large, Medium, Small, No space from another component's boundary 1. Ability to align a component with a target 2. Ability to center a component between any two targets 3. Ability to move a component a few pixels *without* snapping to a nearby target (useful for fine-tuning positions down to the pixel level) And so on... Let me know what you think.
On a related note, according to http://www.mindsilver.com/guide/docs/articles/layout/index.php GroupLayout will never be able to represent artbitrary free-form designs.
We plan to fix these problems in NB 7.1 (11/2011) ...
Ok, we will go through all related issues and close one by one those already fixed in NB 7.1 Beta. So this issue is no more stopper for NB 7.1 Beta.
(In reply to comment #48) > Ok, we will go through all related issues and close one by one those already > fixed in NB 7.1 Beta. So this issue is no more stopper for NB 7.1 Beta. I did it. I closed some issues as FIXED. I think we should low priority to P2, and wait for some feedback (new issues, reopened issues,...). Marian???
(In reply to comment #49) > Marian??? Thanks Adam, I agreed with Tomas : he will go through the rest of issues and then decide what we will do next.
So, after all rounds of fixing and testing I think we are done with this UMBRELLA ... changing to TASK, leaving open. I would like to ask everybody in case you do not agree, or you are facing other problems 'like this' please report it as separate issue and add dependency here, do not turn this into DEFECT. Thanks in advance.
WORKAROUND! Hi people. There is a workaround to fight against this bug, I´ve see that maybe makes this challenge usefull. Use as many panels do group controls as possible. Because the gratuitously moving seems to occur, when it occurs, only inside the respective panel, mantaining the others intact. I hope it can help you all. Good luck! PS: Sorry my english, Im Brazilian..lol...
This is not critical issue, You can see list of related bugs where you can find solution of your problem. http://www.bestessayhelp.co.uk
faustoodilon@netbeans.org this is really helpful & now all things updated. Now I am active on this site again & ready to help others with any type of essay/assignments.. https://www.speedyessay.co.uk/ We develop legitimate custom academic help that demonstrates your writing experience. The company has highly customized writings that help students understand what they are required in their academics.
I will close it, because it will handled now at the JIRA board: https://issues.apache.org/jira/browse/NETBEANS-1411. Please discuss it there for further information.