I'm trying to build a GUI for a program I just finished writing. I don't have any prior experience with building a GUI, but I have found enough online to get started.
I initially used the GridLayout and got the setup I wanted, however, I found that I couldn't resize any of the components. Instead, when the program launches, they are at their smallest size. After some research, I found that the GridLayout doesn't allow for resizing and that the GridBagLayout would be a much better solution though it is more complicated. I cannot find this layout in the palette and have been unable to find anyone with the same issue in a few google searches. Does anyone know if I might be missing something obvious?
Here is the image of the options that show up for layouts.
Related
I am working on a project with using Swing. Recently, I ve encountered a weird problem that I can't figure out how to solve. Had a look at similar questions and tried to use layouts for frame but it didnt solve the problem. All design is done with using free design. I am using Netbeans.
My question is, I want every panel to be resized properly. Without losing half of the panel and buttons on the screen.
Also tried to call pack() method in the componentListener(another solution that i saw here) but it didnt work neither. Here are some pictures of my project.
Regards.
After resizing:
I'm just curious if anyone knows the easiest solution for an image marquee in Android with clickable events, etc.
I've looked at a few various projects and flicked through the manual, but I can't seem to find anything appropriate.
I would like to create a scrolling image effect similar to the Expedia android application homepage. See https://play.google.com/store/apps/details?id=com.expedia.bookings&hl=en
What I've looked at so far :
FragmentActivity -- Scrolling seems jittery and would take a fair old amount of adapting to achieve what I want
HorizontalScrollView -- Limited scroll functionality (this would be perfect if I could
continiously loop the contents, but short of overriding the draw I can't see how it's possible)
GLSurfaceView -- So far this seems like it's the only viable solution, but it's gonna take me a while to implement all the functionality manually
Before I get cracking deep into the OpenGL route it would be of great help to know if there is something out there that can already do this.
If anyone could suggest anything it would be much appreciated!
Thanks
I was going through this thread and I was wondering, if maybe we could use the scroll-bars to do that?
How to Use Scroll Panes describes how to do things using scroll bars. If I am making a terminal based application using Java for a Linux OS, then can't I use code that will move the terminal knob/scrollbar move down further? I mean, that is how even the BASH "clear" works, right? So, maybe this console-based Java app can move the console scroll down and pretend to clear the screen?
Now, my problem is that I am unable to find any class within this "Scroll Pane API" documentation that would help me do that. If anyone has worked with this API before can help me, it would be much appreciated!
..maybe we could use the scroll-bars to do that?
No. You cannot 'wrap the CLI in a JScrollPane (or add any JScrollBar instances)'. It is a native component that is outside the control (beyond textual output) of Java.
I've designed my program in both null layout and the free design layout, however, when I compiler my program and run it with the null layout the window gets resized (Despite my original size, and specifying the default size, minimum, maximum etc) and the buttons are not visible anymore. However, when I compile and run my program in free design layout, the size is perfect and it works great, but my components get screwed up when I perform all sorts of operations (example : making a component visible, setting the text, etc). Is there any fix to this? I believe this is a netbeans bug but I can't tell. Please help this is a disaster. I'm using Netbeans 7.0.1
Is there any fix to this?
Yes, use a layout manager. Using a null layout is almost never the way to go.
If you need to rearrange the components or change labels at runtime, the 'free design' is probably not the way to go. Its not designed for this, and it really has nothing to do with netbeans. You will need to understand how to use the appropriate layout managers to make it do what you want.
In addition to the standard layout managers, you might also want to look at Mig Layout.
IIRC, netbeans also offers an XY layout for absolute positioning. This is only a bit better than null layout though, because your UI will look bad once it hits another system, but if you don't care about that then that might be the right answer for you.
I am currently toying with the idea of converting a small/medium sized project from AWT to SWT, although Swing is not totally out of the picture yet.
I was thinking about converting the main window to an SWT_AWT bridge object, but I have no idea how the semantics for this work. After that, I plan to update dialog for dialog, but not necessarily within one release. Is this possible?
Has someone done a conversion like this and can give me some hints? Is there maybe even a tutorial somewhere out there? Is there maybe even a tool that can automate parts of this? I have tried googling, but to no avail.
Update: One additional thing is: Currently, this is a netbeans project. Might be of help or not, I don't know.
We have done this quite a few times. But only because we are going from a Swing application to an Eclipse RCP application not because we like messing with things. This project will really let you know whether you've separated your controller/model code from your view code.
One suggestion is to not try and convert everything all at once. You will end up with a bunch of mixed code that doesn't work at all. You can start at converting portals. I would consider a portal anything within a Tab, Dialog, or Window, essentially self contained unit. If you have a window that opens up, create the Window in SWT, but make it's contents the existing AWT/Swing. This should be fairly straight forward and allow you to get used to the (I really hope they weren't drunk and had a good reason for this) way of instantiating and associating parent/child controls.
One gotcha that can occur is with transparent components. Swing, with the exception of a "window" class is all rendered in Java. This makes it very easy to render things the way you want them. In SWT, there are some restrictions:
Borders. If you use SWT.BORDER you are stuck with whatever color the native component uses. Your best bet is to use a PaintListener and render your own borders if you want them in a different style or color.
Transparent labels, progress bars. I have not been able to get Labels or Progress Bars to have a transparent background. If you want them to take on the parent color, or drawing you will need to render the text and other controls yourself.
Controls. There are composites and controls in SWT. Think of Controls as the basic native controls that do all the native API calls. These cannot be subclassed, which makes things difficult.
Tables will give you the most trouble. Make sure everything is stable before you attempt to convert a JTable to a Table or TableViewer. You will spend some time on these, especially if you have custom editors and viewers.
I have not researched why SWT was designed the way it was. I am guessing there HAD to be a good reason. It would be great if someone had a blog or defense to it's design so I don't have to search for it. Once it's posted I'll remove these lines since they have no relevance to the question.
Addition
I want to add that since you have an existing product I assume works. The best piece of advice I can give you is to never let your code get into a state that it cannot compile and run. If you work on your conversion and whatever you check in always runs and executes (despite the visual differences between SWT/AWT/Swing) you will save yourself many headaches in the long run. The worst thing you can do is try to tackle this all at once and get your code in an unstable state for weeks at a time.
I would suggest importing it into a WindowBuilder project, as WindowBuilder gives you the ability to parse existing code and create a GUI mock-up, then morph components to either SWT or Swing.
If you're thinking of using a mix of SWT and Swing in the same application, this Eclipse Corner Article will be immensely useful.
We are preparing the same step: Swing to SWT/JFace. First we try to determine the bottlenecks: reimplement special components derived from JComponent with SWT/JFace, search for a replacement of JIDE docking (we want to use SWT/JFace, not RCP to avoid too much hassle). The worst thing we already imagine is, that in Swing you could create components and adding it later to the parent. With SWT this is not possible: the parent component must be passed as a reference to the child component's constructor. This will require major refactoring in the Swing application before using SWT.
Frankly, we rate the conversion a very heavy change, because we expect the time where nothing can be compiled as quite long. We try to decrease this time by preparing everything as good as possible, but we'll see how good it will work.
Update from April 6th 2011:
We now refactored our Swing application to always create components with their parent (as in SWT). Our subclasses of JFrame and JDialog got refactored to just have a JDialog instance to make it easier to switch to SWT's Shell. In parallel, we rewrite sophisticated components in SWT.