I've been trying to research for existing web browsers that do not have an address bar or additional controls on the UI. Ideally a web browser that has just the window frame. The reason is that I am writing a web application, which ideally I do not want the user to have the ability to navigate to other websites or have the ability to navigate backwards/forwards etc. Obviously I can write additional code that can prevent people from navigating other side/ backwards, etc, but ideally would like a clean Window for the user to work from.
So far i've explored the option of building a web browser UI using JavaFX. However the web application is built using Angular and the JavaFX web browser window flickers from time to time during a screen transition.
If there is anyone that can provide a recommendation of such a browser that would be greatly appreciated. Thanks.
Just curious if you have already looked into Kiosk modes for browsers as that is built in and meant to display a single website. If chromium has that then could could use that.
Chromium kiosk mode no address bar or menu
Edit:
https://github.com/chromium/chromium
Related
I've been pondering over this problem most the afternoon and haven't yet found the most ideal solution so thought I would see what others think..
There is a legacy Win16 application that has to be modified (with the least effort) in order to communicate with a web based application.
The idea is such that in the Win16 app, the user will want to look up a specific code, so they'll click a button which will then launch the browser and allow them to navigate a specific set of pages until they find the result they desire, then they have the option of either pressing Select or Cancel.
Pressing Select should pass back a small string back to the app (around 10 characters) and close the browser. Cancel will likewise send a Cancel message back to the app and again close the browser window.
I can't see many choices available in implementation as the Win16 app is not able to call webservices, so I'm looking at using the clipboard, however that is not without problems.
I hope there's some other alternative I haven't thought of,
As always - all advice appreciated.
Thanks,
is JavaFX capable of loading and embedding OCX Controls? I would like to use the Internet explorer in my Application, because the WebKit browser lacks support for ActiveX. And since I have to rely on third party ActiveX Controls (I know they are evil), I am bound to the IE.
This question is not purely related to "Can I use OCX in Java" because I would like to have some kind of component for JavaFX I would like to use.
Or do I have to rely on libraries posted here:
Use a .OCX Control in Java
Thanks in advance,
Sven
You have to rely on the libraries posted in the link you supplied in your question.
Or you need to write your own JNI interface.
If you do access OCX components, you may need to place them in their own window rather than sharing a window created by a JavaFX stage as you may run into issues with the JavaFX renderer conflicting writes on the window portions in which the OCX components are displayed - you would have to try it and see what happens to confirm.
The easier way to do this may be to request that users of your application set their default browser to IE, and then call the JavaFX hostservices.showDocument(uri) api to launch an IE page which embeds the OCX components you need.
Another alternative is to:
Embed your JavaFX application as an applet in a web page.
Also embed your activex controls in the web page.
On display of the web page, check the browser and, if it isn't IE, tell they user that the must be using Internet Explorer.
Have the user accept any miscellaneous security warnings the Browser displays.
Have the user (or perhaps JavaScript) resize the browser window to fullscreen (see IE9 Full Screen Mode or Full Screen Browsers with JavaScript).
Communicate between your active X controls and java app using javascript invoked via calls from the javafx/javascript bridge and control your active X controls via VBScript embedded in the page.
It would probably work, but it is such an ugly Frankenstein solution . . .
If you can convert your media to a format which JavaFX supports and just play it back direct through JavaFX, that would be much preferable, or it may also turn out that due to a deep ActiveX integration requirement that JavaFX is not the best solution to your problem and you could be better off with something like Silverlight.
I'm developing an application using Vaadin framework. The application has a main menu, when user clicks a menu item, application executes descendant of AbstractMenuCommand class like
public class RunReportCommand extends AbstractMenuAction {
#Override
public void execute() throws MenuException {
Window = .... // create window here
openWindow(window);
}
protected void openWindow(Window window) {
application.getMainWindow().open(new ExternalResource(window.getURL()));
application.setMainWindow(window);
}
}
After this main browser window content is replace with needed window. After spending a lot of time I came to this solution: if you want replace browser window content with Vaadin Window you should always do
application.getMainWindow().open(new ExternalResource(window.getURL()));
application.setMainWindow(window);
Recently I got a new task to add a feature to application: users should have ability open windows in diffirent tabs and so the problem is that I have only one main window in vaadin (and window.open works only for the main window) but user can have a lot of diffirent windows in diffirent browser tabs, so if user clicks a menu item in browser tab that contains not main window, reloading vaading window content won't work.
Vaadin 7 & Vaadin 8
With versions 7 and 8 came the new concept and class of UI. You can now very easily open another window/tab in the user’s web browser. Fantastic new feature and great advantage for the Vaadin platform to support multi-window apps.
All the open windows/tabs share the same user session.
The tricky part is that for purposes of security and avoiding obnoxious behaviors, browsers do not allow JavaScript to directly open another window, known as "pop-up window". The new window/tab can only be opened as a direct result of a user gesture such as clicking a button.
So in Vaadin, you must use associate a BrowserWindowOpener object with a Button. You pass the .class of your UI subclass you wrote. That UI subclass is automatically instantiated for you, and displayed in the new window/tab.
All of this is explained well in the Handling Browser Windows page in the manual.
One limitation is that I see no direct way to pass objects to the new window/tab, that new UI-subclass instance. You might be able to do so indirectly. Perhaps posting an attribute in the session. Or perhaps setting string parameters on the URI of the new window/tab. I have asked about this issue of passing information to the new window for Vaadin 7 and asked again for Vaadin 8.
Vaadin 6
In 2011, I spoke with members of the Vaadin development team about the issue of multiple web browser windows or tabs for the same Vaadin 6 app. They strongly recommended against doing so. They said while it is possible, doing so requires much effort and tends to be troublesome and error-prone.
Instead they suggested using Vaadin TabSheet within a single browser window/tab.
The TabSheet is quite dynamic, so you can add and drop tabs as needed. Performance is surprisingly fast in my experience. Remember that only the content of the frontmost tab is actually in the user's browser window. The other tabs' content is in memory on the server, but is not a burden to the web browser/client. While tabs cannot be word wrapped and so tend to be wide, the TabSheet automatically provides scrolling through too many tabs to show.
Until release of Vaadin7, you can look at Navigator7 add-on (found here)
Navigator7 allows multi browser tabs navigaton. (A click in a browser tab, only affect this browser tab)
We use it in our application and it's work verry well.
Regards.
I've implemented an interactive map applet, which is embedded in a web application. The application uses some Ajax, but has a predominantly page based structure.
The problem is, navigating away from and back to the page containing the applet causes an applet reload, which takes several seconds.
Possible ways to alleviate this problem I thought of are:-
Make the applet run continuously in a separate browser window (I lose integration with the main web app though)
Convert the web app to use Ajax exclusively to avoid page reloads
Implement the map view as a standalone desktop app
If there is some way of preventing applet reloads in the browser I would be very interested to hear about it, but I don't think this is possible due to the applet lifecycle.
I think that you enumerated all options, their advantages and disadvantages.
I'd like to suggest you a combination of options you suggested.
You can separate you applet into 2 components. First, heavy-weight application that will be started using a java web start. It will contain all application logic and will run in minimized (or even transparent) window. It will prepare image and send it via network to light-weight applet that just shows it.
I this case you do not loose your application integrity: map is shown in browser. The applet is very light weight, so it starts fast. The stand-alone app implements the most of programming logic.
Here is how to make window transparent: http://java.sun.com/developer/technicalArticles/GUI/translucent_shaped_windows/
I recently played around with the SWT browser widget (which is great). I am wondering if I could write a full desktop application with it (with java services behind - e.g. persistence) and what drawbacks I would have to consider. The advantage would be that people without java knowledge could work on the gui. Of course it depends on the requirements and I know that this is not a very specific question. But mabye someone already tried to build a bigger app this way and is willing to share insights.
Thanks
Marcel
I'm not sure I share your opinion of the SWT browser widget. AFAIK it's merely a shell into the default browser on your machine, merely with a few API access points. I've used it for minor things when I needed to show a web page from within the application. But writing a whole application? That doesn't make sense.
If you want to build a web-based application that runs in the browser against a Java based server framework, there are many AJAXian frameworks to do it. You'd still be doing JavaScript for your client code. And you'd still be dealing with all the complexities of different browsers. I'm not sure why you would want to host it inside an SWT application instead of just directly in the browser window.