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.
NB: 200808261401 Create a JFrame form and place two JPanels 200x100px into it so that one is just bellow the other one. Now try to insert a JTable into one of the panel - it is quite difficult, because the JTable preview (bellow the cursor) is too large and the cursor is in the middle of the preview, hiding both panels... I would suggest to decrease the preview dimensions and I would also place the cursor to the upper left corner of the preview for larger components (well, the other way round, I would place the preview so that point [5,5] is bellow the caret). I think cursor can remain centered for buttons, labels, ... other smaller components... Similar problem holds for JTree, little better situation is for JList and JTextArea... (Previews for Containers are small enough, so I would say it is OK...)
... caret... nice... I meant "cursor"...
We considered this problem some time ago. We decided to use the following solution: use preferred size of the added component if it is not too large. If the preferred size of the added component is bigger then the designed container then shrink the component a little to be slightly smaller then the designed container. I don't see any advantage in changing the cursor position to something else then the center position - it definitely is not any defect, it is just your personal preference. As for your scenario, it can be solved easily with Design This Container action (it is in contextual menu of the container or it is invoked when you double-click the container in Inspector or in the designer). Whenever you have any difficulty with the design of some nested container then this action is ideal to focus design just on this container. In your case, when you focus design on one of the JPanels and attempt to add JTable then the JTable will be made small enough to fit into this panel.
Well, the best solution (according to my preferences) would be not to display preview when pick&plop at all, allowing user to insert component by dragging: User would click the JTable item in the Palette, palette item would be highlighted, then he could click ("mouse button down") in the designer, drag the cursor and drop. This would allow him to specify the size of a component. After all - he knows what size he/she wants better than some pushy IDE developer, right;)? If he just clicks (no drag), item would be inserted as now pick&plop works (user would miss the preview, not a big pity, IMO). D&D would work the same way as it works now. This is what VisualStudio+Delphi basically do (maybe with small differences), isn't it? Actually, these IDE's do not display preview during insertion at all (Visual Studio displays icon by the cursor), preview is actually not so handy as one might think... > I don't see any advantage in changing the cursor position to something else then the center position - it definitely is > not any defect, it is just your personal preference. I believe that you don't see the advantage, but IMO it is very simple. User would see where he drops the component in most cases (cursor position [A,B] relative to preview ~ no problem for containers bigger that AxB pixels). It might be just my personal preference, but I think it is better than how it works now => well, this is a personal preference again, so I am adding olangr on CC to evaluate. I think that the position in the center of the preview is very unfortunate... Btw: Visual Studio has the point at [0,0] (cursor is in the upper left corner). I am reopening this issue as an enhancement - workflow with a form designer could be much better. I am giving proposals here, it is opened for discussion. > As for your scenario, it can be solved easily with Design This Container action Yes, it could, but "easily" - well - I think it is just your personal preference, I would prefer not to use it...
I'm not gonna push anyone here ;) but I was added to CC to evaluate, so I'm adding my 5 cents. I basically see 2 separate issues here: 1) Previews are too large for some components I totally agree here. The table component has 4 columns and good 400px vertical size. After it is drag'n'dropped, it only occupies hardly 100px. So i'd say it should certainly be smaller. If it had 3 columns, the chance that we'll correctly guess the number of columns the developer needs is about the same as now and it'd be smaller and simpler, yet it'd be clear it is a table .. (might cause a problem if the table was 2 by 2). The same for JTree. 2) The cursor position No strong opinion here, but I slightly head towards keeping the current state. I don't see any advantage (for normally sized components) for having the cursor at [0,0]. I'd say that the main problem now is that to actually place the component correctly, one would sometimes have to move the cursor beyond the matisse/screen boundary, but that should be sufficiently solved by resizing the components to an appropriate size.
Thank you for your comments, Ondra. I agree that if previews are properly sized, cursor can remain centered. Maybe one more thing - what about the way of designing using drag&drop inside the form? I mean the way of editing that Visual Studio does, that allows user to specify the size of the container by clicking to some point, dragging and dropping cursor at some other point? Is the preview really so essential/helpful when using pick&plop? Would not be better/easier to dump it in favor of that way of editing? Can't we just display icon by the cursor when doing pick&plop? I am not saying it is better, I am just thinking aloud. Maybe the problem is that I spent too much time with Delphi/VisualStudio to remain open-minded about how designer should work and behave..
Both visual studio & NB way have their pros & cons. For the initial experience, I see the netbeans way better as the feedback on what's going to be dropped on the canvas is immediate. For long-term experience, I see the typical flow such that components are dropped on canvas and *then* aligned / scaled with each other and for this flow, the NB way also seems better as it requires less mouse interaction (one mouse movement and click to place the component instead of two). But I'm assuming that the components would be aligned later anyway (which may or may not be the case, I don't dare to say without having observed statistically at least a little bit valid number of user interactions). Anyway, we're getting a bit sidetracked here as the original topic of this issue was the size of the inserted components. I consider this a bug, so I'm changing type of this issue. Joshis, please, if you still think we should consider the double-click placement, file as a separate issue. Thanks.
Thanks, Ondra. > Joshis, please, if you still think we should consider the double-click placement, file as a separate issue. I will see how this issue will be dealt with before and how it works, I believe that decreasing the preview size might work well enough... Maybe making preview transparent (50-70%...???), so that one can see where exactly he/she drops the component would be nice too? And drawing a border to the container where a component would be dropped? I will open separate RFE's for this - oh - I already had:) - issue 145812 and issue 145814...
No changes to cursor hotspot and smaller preview of jtable and jtree - this will fix this issue. Do you agree with me joshis?
> The table component has 4 columns and good 400px vertical size. After it is drag'n'dropped, it > only occupies hardly 100px. So i'd say it should certainly be smaller. If it had 3 columns, the chance that we'll > correctly guess the number of columns the developer needs is about the same as now and it'd be smaller and simpler, Unfortunately, this is not true. The preferred size of JTable doesn't depend on the table model e.g. it is the same if it has 3 or 4 columns. > I consider this a bug, so I'm changing type of this issue. Could you, please, elaborate on this. I still don't understand what is this issue about. So far, there are just some vague complaints about large components, but I don't see any specific suggestion how to improve the algorithm that we use now. We must try to honor the preferred size of components. We cannot arbitrarily change the size of every large component - that would make the GUI builder "more inteligent" then the component vendor. We can possibly be "more inteligent" for standard components that we know very well e.g. for JTree and JTable (as mentioned by jvagner), but not for others. So, do you agree with jvagner that this issue is just about these two components?
> No changes to cursor hotspot and smaller preview of jtable and jtree - this will fix this issue. Do you agree with me joshis? Yes, it could do the job, Jirka... I still think that insertion point 0.0 is better as you can exactly see where you drop the component, but I will respect suggestion by olanger, who is responsible for making decisions about this. Another solution is to disable preview when using pick&plop, but I don't like this solution myself too much... Issue 145812 could also help this... > I still don't understand what is this issue about. So far, there are just some vague complaints about large components OK, little motivation first, to make it less vague. Typical usecase for me is following: I have a form of default size (File>New File, JFrame), then I place several panels to the form (lets say there are 4 panels - top, bottom, left and center/main panel) and then I want to place a table to the left panel. First thing - if I do so, the panel is expanded to fit the inserted component size and so my carefully designed layout can become totally screwed up. So I have to resize the table, fix the messed up layout, thank jstola for a "try to honor the preferred size of components" and have a cup of tea to relax. Also, I am doing a "blind design" when I don't actually see where I drop the component, as it covers some 98% of the form size. How should I know I am already above the left panel and not about main panel when I see nothing? Indeed, some workaround is to design a container, but I am not designing the container at the moment, I am trying to design a form and I want to see what a user of my application would see. > but I don't see any specific suggestion how to improve the algorithm that we use now. I will give it a try, in spite of the fact I am here to show problems, not solutions to them. Those are just quick thoughts, please take them with some reserve: Make the preview of the component so big that it can fit to the smallest container in the form, but so that it is not too small (lets say not smaller than 100px - preffered size of jpanel - in any dimension). Again - user can fix the size later and he/she knows where he/she drop the component as the preview should keep reasonable size in most cases. > We cannot arbitrarily change the size of every large component - that would make the GUI builder "more intelligent" > then the component vendor. Well, currently the GUI builder is smarter than developer who is trying to use it (which might not be such a big achievement in my case, right;)). Another problem: if you drop a component in a MSVS, it can actually overlap its container. It does not expand it as NB does, this is the reason why guys from Microsoft can afford to "honor the preferred size" and you cannot, IMO... > So, do you agree with jvagner that this issue is just about these two components? Well, lets say that you can mark this issue as "fixed" when these two components have smaller preview. But I am agreeing with you in this message for guys from HIE: "Could you, please, elaborate on this."
>> The table component has 4 columns and good 400px vertical size. After it is drag'n'dropped, it >> only occupies hardly 100px. So i'd say it should certainly be smaller. If it had 3 columns, the chance that we'll >> correctly guess the number of columns the developer needs is about the same as now and it'd be smaller and simpler, > Unfortunately, this is not true. The preferred size of JTable doesn't depend on the table model e.g. it is > the same if it has 3 or 4 columns. I may not have explained this well. I meant to say that (assuming that users will adjust the size of these components after dropping it on the canvas) by making the dropped component (as well as the preview) smaller (both in terms of pixel size and cell number), we are not less likely to "guess" the correct size and avoid the user having to resize it, but we'll make the interaction somewhat easier in case of small panels which this issue is about. > We cannot arbitrarily change the size of every large component - that would make the GUI builder "more intelligent" > then the component vendor. Well .. I agree with the second part, that it would make the GUI builder more intelligent than component vendors. And I think the fact that GUI builder offers a lot more than components themselves is the reason that people use GUI builders and don't just code forms. In other words, being more intelligent than component vendors sounds to me like a good thing for GUI builder. After all, GUI builder knows about the context which the instance of the component is going to be placed, unlike it's vendor. Are there any drawbacks to not respecting preferred size? I mean is there some odd behavior we can expect or something?
> it would make the GUI builder more intelligent than component vendors No, in general, we cannot be smarter than component vendors. The component vendor has complete knowledge about the component e.g. (s)he knows what the component should display, how it should react on user gestures etc. (S)he expresses this knowledge via component's getPreferredSize() method. The GUI builder knows nothing about the component (with the exception of some well known components like JTable or JTree). > Are there any drawbacks to not respecting preferred size? Yes, of course. The size of a component is affected by many aspects (OS, look and feel, JDK, font family/size) that can change without recompilation of the application (e.g. depend on context in which the application is executed). Hence, you should honor the preferred size of components where possible (the preferred size is calculated correctly from the mentioned variables). Fixed (=hardcoded) size may look well at the design time, but it will not work in the different context at runtime.
> Yes, of course. The size of a component is affected by many aspects (OS, look and feel, JDK, font family/size) > that can change without recompilation of the application (e.g. depend on context in which the application is > executed). Hence, you should honor the preferred size of components where possible (the preferred size is > calculated correctly from the mentioned variables). Fixed (=hardcoded) size may look well at the design time, > but it will not work in the different context at runtime. Does this mean that if I place the component on canvas and resize it afterwards, I do not "honor the preferred size of component" and "it will not work in the different context at runtime"? Because from my naive point of view, doing these two things automatically seems to be the main thing being asked for in this issue. With one more addition - making the preview smaller too.
I am still not fully getting this (maybe too MS affected reasoning?). So what you are basically saying is that in ideal world, all the components you put in a designer are keeping their preferred sizes? Therefore, if I place an unbelievably big component (from any vendor) to a form so that it breaks my layout because it is too big and if I then resize it to be smaller, I am making a design mistake, because my application "will not work in the different context at runtime"? In spite of having layout managers, h/v resizing options, etc.? How did Delphi do it? How does MSVS do it? What about other designer under Linux (there are some for Qt)?
> Does this mean that if I place the component on canvas and resize it afterwards, > I do not "honor the preferred size of component" and "it will not work in the different context at runtime"? Yes, unless you make it resizable (and the component is designed to be resizable). For example, if you change the size of some button (to be hardcoded) then it will have problem to accomodate its text if another look and feel uses larger font (or if its text is changed during localization). On the other hand, this is not a problem for components like JTree and JTable that are usually made resizable in the layout (and are well designed to handle resizing). Unfortunately, there is no automatic way how to determine that. That's why I suggest to modify size of well known problematic components (e.g. JTree and JTable) only.
> That's why I suggest to modify size of well known problematic components (e.g. JTree and JTable) only. I totally agree with you on this, we probably misunderstood each other previously, I wasn't suggesting to resize all large components automatically. Let's just do this for JTable and JTree and it should solve this issue or make it less obtrusive at least.
> Let's just do this for JTable and JTree and it should solve this issue or make it less > obtrusive at least. I agree with this, please fix these two components and close this issue as FIXED then. Just a little bottom-line. Components are resizing anyway: > If the preferred size of the added component is bigger then the designed container > then shrink the component a little to be slightly smaller then the designed container. (I would still try look for some inspiration somewhere on how to do this better... Visual Studio again: D&D -> preferred size, P&P preferred size or custom size design... but this is now out of scope of the issue...)
Not incomplete anymore, IMO...
Alright, we will implement autoresize algorithm for jtable and jtree preview. Algorithm will use the size of the smallest container component inside the edited form and also there will be a minimum dimension (80x80) for that preview.