Home » Eclipse Projects » WindowBuilder » Large applet issues
| Large applet issues [message #875559] |
Wed, 23 May 2012 00:33  |
 Marc Chamberlin
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
Hello - I am encountering a problem with using WindowBuilder to design
a GUI for large JApplets which I need some help with. My applet is
rather large in size, so to accommodate it, I have extended JPanel with
a variant called SizeableJPanel that simply overrides the
setPreferredSize method to calculate the preferred size based on the
position of all the sub components within it. This then gets wrapped
inside a scrollPane to allow a user to scroll the contents of the
contained SizeableJPanel. This all works just fine, when the applet is
executed, or even when simply tested using the "Quickly
test/preview...." button inside Eclipse/WindowBuilder.
My problem is that WindowBuilder itself does not render the view of the
applet correctly in its editor window. I do not fully grok how
WindowBuilder chooses the "default size" it thinks the applet should be,
but anything that is outside of this default size gets clipped and is
not rendered in the view properly. This makes it very difficult to use
WindowBuilder to layout components in the part of the applet GUI that is
clipped. I have discovered, (trial and error) that setting the default
"form width and height" for Swing does affect this default applet size
but only up to a certain point. Further increases of either of these
values does not affect what WindowBuilder shows for the applet GUI, and
anything beyond that point is clipped out of view, unless a particular
clipped component is directly selected. FWIW my Swing form default
settings is now set to 600x1400 pixels. One guess I might make, and this
is a real long shot, is that it kinda appears that the maximum width and
height of the applet that WindowBuilder will render is based on the
width and height of the screen of the system that Eclipse is running
on??? I note that the applets GUI is being rendered on my desktop
momentarily just before it is displayed in the WindowBuilders edit
window, so hence my guessing there might be some sort of connection, but
as I said, I am really guessing....
I have written a small test applet that illustrates this issue Note
that I am using Absolute layout in the JPanel (panel_1) that is located
at the bottom of the applet and within it there is a button
(btnNewButton_2) that is located in the area that WindowBuilder is
clipping. As one can see, manipulating buttons and other widgets within
the clipped area is difficult.
I am unable to grab any of the boundary lines for the JApplet itself, to
resize it either, which is another issue I do not understand. That seems
like the obvious solution and one I would intuitively expect to be able
to do?
I do not think that the SizeableJPanel container I wrote has anything to
do with this problem. I have tried/tested this without it, and still get
the clipping problem. I simply included it here to give some context
about what I am trying to achieve. Yes, the applet will be larger than
what can be displayed on a screen, hence the need to make it scrollable.
It also doubles as a WebStart app and will have the capability to
"float" in its own window which is again why the ability to scroll it
will be needed. Attached is the code for my SizeableJPanel, and for the
test applet that I have written to demonstrate this problem. Would sure
appreciate any help from kindly gurus who can give me some guidance on
how to control the size of the applet as it is rendered in the
WindowBuilder's editor.
One other question/nit I have - How does one get rid of the
WindowBuilder label and revision number shown in the lower right corner
of the edit area? I have components and widgets in my applet/application
GUIs that those labels sometimes sit on top of, making it again hard to
work with. I didn't see anything in the WindowBuilder preferences that
allow me to turn the display of that info off...
Marc...
P.S.
Version: Indigo Service Release 2
Build id: 20120216-1857
Swing Designer 1.3.0.r37x201202021417
WindowBuilder Core 1.3.0.r37x201202052311
WindowBuilder Core UI 1.3.0.r37x201202052340
> java -version
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
package utilities;
import java.awt.Component;
import java.awt.Dimension;
import java.awt.Rectangle;
import javax.swing.JPanel;
public class SizeableJPanel extends JPanel {
/**
*
*/
private static final long serialVersionUID = 1L;
/*
* Finds the smallest rectangle enclosing all this container's components.
* This makes JScrollPane behave correctly when you want put a container in
* it that has a null (absolute) layout.
*/
@Override
public Dimension getPreferredSize() {
int maxX = 0;
int maxY = 0;
Component[] components = this.getComponents();
for (int i = 0; i < components.length; i++) {
Rectangle bounds = components[i].getBounds();
maxX = Math.max(maxX, (int) bounds.getMaxX());
maxY = Math.max(maxY, (int) bounds.getMaxY());
}
return new Dimension(maxX, maxY);
}
}
package Test;
import javax.swing.JApplet;
import javax.swing.JPanel;
import java.awt.BorderLayout;
import javax.swing.GroupLayout;
import javax.swing.GroupLayout.Alignment;
import javax.swing.JScrollPane;
import javax.swing.JButton;
import utilities.SizeableJPanel;
import java.awt.Dimension;
public class testApplet extends JApplet {
private JScrollPane scrollPane;
private SizeableJPanel panel;
private JButton btnNewButton;
private JButton btnNewButton_1;
private JPanel panel_1;
private JButton btnNewButton_2;
/**
* Create the applet.
*/
public testApplet() {
initGUI();
}
private void initGUI() {
getContentPane().add(getScrollPane_1(), BorderLayout.CENTER);
}
private JScrollPane getScrollPane_1() {
if (scrollPane == null) {
scrollPane = new JScrollPane();
scrollPane.setViewportView(getPanel_2());
}
return scrollPane;
}
private SizeableJPanel getPanel_2() {
if (panel == null) {
panel = new SizeableJPanel();
panel.setLayout(null);
panel.add(getBtnNewButton());
panel.add(getBtnNewButton_1());
panel.add(getPanel_1());
}
return panel;
}
private JButton getBtnNewButton() {
if (btnNewButton == null) {
btnNewButton = new JButton("New button");
btnNewButton.setBounds(51, 56, 107, 25);
}
return btnNewButton;
}
private JButton getBtnNewButton_1() {
if (btnNewButton_1 == null) {
btnNewButton_1 = new JButton("New button");
btnNewButton_1.setBounds(306, 314, 107, 25);
}
return btnNewButton_1;
}
private JPanel getPanel_1() {
if (panel_1 == null) {
panel_1 = new JPanel();
panel_1.setBounds(10, 400, 550, 900);
panel_1.setLayout(null);
panel_1.add(getButton_1());
}
return panel_1;
}
private JButton getButton_1() {
if (btnNewButton_2 == null) {
btnNewButton_2 = new JButton("New button");
btnNewButton_2.setBounds(180, 800, 107, 25);
}
return btnNewButton_2;
}
}
|
|
| |
| Re: Large applet issues [message #875993 is a reply to message #875569] |
Wed, 23 May 2012 17:39  |
Marc Chamberlin
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
On 05/22/2012 06:08 PM, Eric Clayberg wrote:
> This is the second time you have posted the same message multiple times.
> You need to find a way to avoid doing that.
My apologies! I have been using PortableApps version of Mozilla's
Thunderbird, running under Wine, under Linux to post to this newsgroup.
I am using news.eclipse.org as the newsserver to post to. Thunderbird
only shows me doing a single posting, but a check on the web indeed
showed multiple postings! So I was unaware of this problem. I will try
to resolve this, and have posted a question on the Mozilla Thunderbird
newsgroup to see if they have any ideas. (I am posting this from a
different variant of Thunderbird that runs directly under Linux, not
Wine, please let me know if that makes a difference....)
>
> Marc Chamberlin wrote on Tue, 22 May 2012 20:33
>> it kinda appears that the maximum width and height of the applet that
>> WindowBuilder will render is based on the width and height of the
>> screen of the system that Eclipse is running on?
>
> That is exactly right. Depending on the OS you are using, the size of
> the renderable area is limited by the size of the physical display. This
> is an OS bug/feature. The only work around I am aware of is to use a
> larger display (actual or virtual). You could also break the UI into
> multiple smaller panels and edit each panel separately and then combine
> them into the single large ui.
Hmmmm, Thanks Eric so much for your reply. You made me dig deeper and do
some further searching through past postings on this newsgroup and on
the Internet, and I see some evidence of users having similar
questions/problems about sizing containers in WindowBuilder, but they
are apparently running under Windows. I am running under Linux so if
these are indeed related issues, then I doubt you can claim it is an OS
bug/feature... Maybe it is a Java (libraries) related issue? I dunno,
can't say as I don't know anything about the design of WindowBuilder....
I will see if I help out a bit, if you like. I can port this project
(and/or the little test applet I sent you) over to a Windows box and try
it there, and get back to you, but it is going to take me a little while
to get Eclipse and set it up on a Windows system...
I will also ponder on your suggestion to break up the GUI into multiple
parts, but that may be difficult for us to do. Anywise, the biggest area
of the applet GUI's real estate is taken up by the need to display
variable sized images, hence the need for scrollbars and an applet that
is quite large, but yes perhaps buttons and other control widgets could
be moved into a separate project/GUI....
>
> Marc Chamberlin wrote on Tue, 22 May 2012 20:33
>> How does one get rid of the WindowBuilder label and revision number
>> shown in the lower right corner of the edit area?
>
> The latest build eliminates the WB label, but the revision number is
> still shown (its important to use for support purposes). There is no
> current pref to eliminate it, but you could we would be willing to look
> at a patch that added one.
Understood! It is just a nit/annoyance, not all that important to me. If
only I had 48 hours in a day so I could help out with providing you with
a patch.. ;-)
Marc..
|
|
|
| Re: Large applet issues [message #876117 is a reply to message #875993] |
Wed, 23 May 2012 23:50 |
Marc Chamberlin
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
>> Marc Chamberlin wrote on Tue, 22 May 2012 20:33
>>> it kinda appears that the maximum width and height of the applet that
>>> WindowBuilder will render is based on the width and height of the
>>> screen of the system that Eclipse is running on?
>>
>> That is exactly right. Depending on the OS you are using, the size of
>> the renderable area is limited by the size of the physical display. This
>> is an OS bug/feature. The only work around I am aware of is to use a
>> larger display (actual or virtual). You could also break the UI into
>> multiple smaller panels and edit each panel separately and then combine
>> them into the single large ui.
>
> Hmmmm, Thanks Eric so much for your reply. You made me dig deeper and do
> some further searching through past postings on this newsgroup and on
> the Internet, and I see some evidence of users having similar
> questions/problems about sizing containers in WindowBuilder, but they
> are apparently running under Windows. I am running under Linux so if
> these are indeed related issues, then I doubt you can claim it is an OS
> bug/feature... Maybe it is a Java (libraries) related issue? I dunno,
> can't say as I don't know anything about the design of WindowBuilder....
> I will see if I help out a bit, if you like. I can port this project
> (and/or the little test applet I sent you) over to a Windows box and try
> it there, and get back to you, but it is going to take me a little while
> to get Eclipse and set it up on a Windows system...
Eric, all - I brought my project up in Eclipse running on a Windows 7
system, on the same laptop that I do most of my development work on
under Linux, and yes the clipping problem is relevant to both OSs. So
that suggests to me that this is probably not an OS issue/bug/feature
but something else. I would hazard a guess that either something is up
with Java and it's libraries, or a hard look at the design of
WindowBuilder itself is needed in order to fix this problem. (I know,
who has the time... but perhaps I should submit a bug report somewhere
in order to capture this issue?) I should mention however, there was a
slight difference between Windows and Linux, on Windows the clipping
occurred at the top of the applet and on Linux the clipping occurred at
the bottom of the applet.
>
> I will also ponder on your suggestion to break up the GUI into multiple
> parts, but that may be difficult for us to do. Anywise, the biggest area
> of the applet GUI's real estate is taken up by the need to display
> variable sized images, hence the need for scrollbars and an applet that
> is quite large, but yes perhaps buttons and other control widgets could
> be moved into a separate project/GUI....
>
We are brainstorming on your suggestion, the hangup being that we have
to handle some dynamic placements of a few labels that are initially
created in the "clipped lower region" of the applet (on Linux), but can
be move to places on/around the large image(s) that I previously
mentioned.. Probably this means we will have to come up with a new
design/model in order to accommodate the WindowBuilder editor. And as
you might guess, that is not going over very well :-(
Marc..
P.S. This time I am posting from PortableApp's Thunderbird running under
Windows... Let me know if this gets posted multiple times...
|
|
| | |
| Re: Large applet issues [message #993615 is a reply to message #876156] |
Tue, 25 December 2012 00:24 |
Anestis Sismanidis
Messages: 2
Registered: December 2012 |
Junior Member |
|
|
I realize that this thread is old but this is the only discussion I found related this bug, so this is my only chance to get an answer...
Eric Clayberg wrote on Wed, 23 May 2012 22:37We have extensively researched this, so we know that it is a general OS issue. I did not mean to imply that it is an issue limited to a single OS. WB does not actually render any of the widgets you see; the OS does. This is basically an unfortunate OS optimization where the OS does not render widgets that fall outside the bounds of the current display buffer size. Make the display buffer larger (by using a larger display - physical or virtual) and the OS renders more.
We have spent many days looking for work arounds to try and convince the OS to render more and have not had any luck. This is an uncommon enough issue (e,g, trying to create a panel larger than the display) that we decided not to spend any more time on it. If anyone has any ideas for how to coerce the OS into doing the "right thing" and wants to submit a patch, we would be more than happy to look at it.
I don't understand why this is an uncommon issue. What if I want to create a JPanel which is larger than the size of the screen (e.g. a form which imitates a long paper form) and add this panel to a JScrollPane. Naturally, I could split it into smaller pieces but, at the end I would still want to assembly the whole panel just to see if it's ok.
Anyway, if you still haven't found a solution. Could you suggest a place where I should look? Should I post a bug report or something and where? I would even dive into source code if I knew which one is remotely responsible (I use Ubuntu). Could this bug/feature be inside the VGA driver?
I'm eager to find a solution, anything you can suggest (or anyone else), would help a lot.
Thanks in advance!
|
|
| | |
Goto Forum:
Current Time: Sat Apr 20 02:30:57 GMT 2024
Powered by FUDForum. Page generated in 0.03455 seconds |
] 
Search
Help
Register
Login
Home
