I have a program that uses a JFrame. I would like to make it so people could play my game from a website. Is there an easy way to turn JFrames into JApplets?
I have a program that uses a jFrame. I would like to make it so people could play my game from a website. ..
Launch the JFrame directly off a web site using Java Web Start. JWS offers many neat features, like auto-update & desktop integration (menu items, desktop shortcut).
..Is there an easy way to turn jFrames into jApplets?
When it comes to applets, nothing is easy.
It is always a matter of dealing with how different (versions of different) browsers, on different (versions of different) OS, using different (versions of different) Java plug-ins interact with each other. And that can often be summed up as 'poorly'.
I think the best way is to code your application to be contained within a JPanel. Then in the main method create the JFrame and adds that JPanel to it. Likewise, you can create a JApplet that gets created and just add the JPanel. This way your Swing application will be generally agnostic with regards to the top-level container.
You can simply create a JFrame from the applet. This JFrame then is a new OS window, and not still embedded in your browser.
Our program shows an example of this (of both popping up an external JFrame (or JDialog) and having components inside the applet, actually). (No source available, though.)
Related
I am curious about how Java actually goes about creating a JFrame in swing; how does a window magically pop up? So, I went ahead and looked at the source code for the JFrame and ended up at the source code for the Window class.
In the Window class, there’s so much going on I can’t tell what hints at the initialization of a displayed window. I am a beginner, and even if it’s really high level stuff, I still want to be to see the actual code for making a window.
Maybe I’m looking at the wrong stuff. If someone could point me in the right direction or provide links, that would be great.
EDIT:
If anyone is confused by what I’m trying to ask, say you were to create a window just like a JFrame but from scratch, how would it be done? How is it done in swing?
Window (or more formally java.awt.Window) is a Java API to the platform native toolkit window. All modern OSes (that support display anyway) come with a toolkit.
JFrame and Swing were a secondary attempt at providing a user interface (UI) toolkit in Java that would look and work the same way over multiple OSes. The classes in java.awt like Frame and Dialog were the first attempt, but they had native peer classes (see java.awt.peer - compiled C/C++ code), and rendered and performed very differently across different OSes.
So what is going on under the hood is that JFrame is first creating the most basic window possible from the OS toolkit, and then dressing it up (adding menu bars, scroll bars, etc) to be a JFrame or a JDialog within the swing Java classes themselves.
I have a JAVA application that, every five minutes, transfers data from a Data Base A to a Data Base B. Then, the application makes some calculations with the data of the Data Base B, and shows the results in a java swing panel. The application is continuously running. All ok.
I would like to see this java swing panel from other computers (more than one). So the idea is to see the panel from different computer whenever you want. I have thought of making a webpage showing the results, but I have no idea of making webpages and I haven’t much time to deal with it.
Is it possible to make a fast java application (or anything else) that connects with my swing panel from another computer?
Thank you very much!
You could use an applet, your Swing components will be added to a JApplet instead of a JFrame, and any web client can download the full application. You will still need to make a web page, but it could only have your Java applet in it.
I've tried different ways of creating different interfaces and applets. One of the main things I'm trying to do is to get these gui's to display text and show multiple buttons with different text leading to different outcomes. What I'm asking is, what code is necessary to create an applet or an interface (because I fail at telling the difference between the two) and how should I approach building and structuring that.
I recommend you use netbeans because it has an editor and is the easy way to create Applet.
https://netbeans.org/kb/docs/web/applets.html
You have three main choices I can think of, others will for sure think of something else:
Create a web server and actually serve a web site with your interface. You can code the interface yourself and communicate with your java server using ajax, you can let GWT among others do that for you. COnsider also frameworks like Struts
Create an applet which will become an embedded object in a web site. This is quickly falling out of grace, and I'd strongly discourage you from doing it, if only because of the pains of java plugins in the browser
Create an application with an interface by using AWT or Swing (which come with Java) or, and this is my personal opinion, more elegantly with SWT
It's hard to tell what will best help you without knowing more of your requirements, but if you are going web, I'd suggest you check out GWT, and if you are going desktop app, look into SWT. Also, please understand these are all well tested frameworks and my preferences are just that, preferences.
To create an interface in eclipse using java you can use swing.
In eclipse:
Create a new Java Project (File -> New -> Java Project).
Right Click on src folder and click New -> Other -> WindowBuilder -> Swing Designer -> [Application Window]/[JApplet].
Add the components that you want (buttons, textfields...).
Seems to me like your trying to graduate from console programs to GUI programs. A GUI works differently from a console program. A console program you have a bunch of loops and if statements, but a GUI program work completely differently. The main difference is that GUI programs are event driven.
With that being said, you want to choose a GUI framework, like Swing. Then decide if you want your application to be web based or desktop. An applet is more for web. If you want a desktop program, then you want a JFrame which will be the top-level container of your application.
You can learn all the components that are available to you in the standard Swing API here. IMO it seems like you need to start from the beginnging, so I would start from the very being of How to Create GUIs with Swing. You will want to pay close attention to section on Writing Event Listeners
If you do want to create an Applet instead of a desktop program, you can see the Applets, where you'll learn how to develop Applets and how to deploy them. You will still need to learn some basics though from the Swing link I mentioned.
Also, before you start using drag and drop gui builder tools, I would strongly urge you to first learn to hand code. It will work best for you in the long run.
I hope this gets you started in the right direction.
The defacto world standard GUI for all platforms is becoming Html5 and css3.
So the easiest way for you to write an interface is in HTML. You don't need an applet unless you have real specific needs like having a constant connection to the server for a chat or whatever. Anyway most of the applet reasons to exist are now resolved in standard HTML. If you want to learn a new langue, try Dart (dartlang.org)
You could use dart to have the more adaptable GUI to standards in the world
I explain why in this blog post
http://1veu.blogspot.com/2013/12/why-i-think-dart-will-detrone-java.html
Naturally even if you need to write a stand alone application with native GUI, HTML5 and css3 are still widely employed along with webkit or native code transformers like PhoneGap.
I'm new here and not so much familiar with applets.
I searched the site and many other forums for answer but i found nothing.
I have made an application in Java which starts with an applet login form, and continues with JFrame subforms which are doing several things like running JOptionPanes for example when a customer make a change in his profile.
My problem is that when the JOptionPane appears, the applet start form comes on top even if i have opened 2 or 3 JFrames.
I forgot to say that my app is big so i cannot post any code (and i think is not needed).
Thanks in advance!
Avoid mixing frames and applets, your working with competing paradigms. If you MUST use an applet, use something like a CardLayout or JTabbedPane to allow the user to switch between forms.
If you can, try using Java Web Start, which will allow you to start your application off the web, but have the same restrictions as that of any embedded GUI.
As to your problem, it sends like you are mixing the native peer for the JOptionPane. Make sure that the parent reference is correct (ie references the frame or child of the frame)
I'm writing a genome browser designed primarily to view the history of chromosomal rearrangements. Right now the project is a series of proof-of-concept demos written using Processing. At this point if I don't make any radical changes the final application will be a web applet with a gui built of swing components that open PApplets to actually show the rearrangements happening.
My question is: Should I give up on processing and switch over to pure Swing/AWT? This is my first big java project. I'm building in eclipse, but I can use netbeans as well. If I could embed PApplet objects inside a JFrame, for example, that would make my day.
processing.core.PApplet extends java.applet.Applet, so it should be possible to embed
a PApplet in a java.awt.Frame, as discussed in the article Applet ⇒ application: Hybrid Switch Hitters. See also, Mixing heavy and light components.
Addendum: From the API, "Processing runs in a Frame and not a JFrame. However, there's nothing to prevent you from embedding a PApplet into a JFrame," except for the limitations mentioned above.
Keep in mind that I know almost nothing about either Processing or your project, so I can only give you general advice.
The question that you should ask yourself before every major design change: what problem am I trying to solve by making this change? If the current architecture works, then you should keep it. If it's not working, then you should start by defining the specific things that are wrong with it (which I notice you didn't do).