We Keep Coding

In Java, how to implement something like File Explorer?

I'm looking for a really simple widget: tree view on the left pane, folder contents on the right, switchable between icons, thumbnails, or detail view. Basically a functional (not pixel for pixel) emulation of Windows File Explorer, but within the Java app. How to do this using only built-in Java libraries? Or a very lightweight framework?
NOT A DUPLICATE
My question is different from the above and I now realize it's a little harder to explain than I initially expected. Two clarifications:
My question is not about a File Chooser. I'm asking about a File Explorer type of dialog. The difference is that a File Chooser is really focused on one task, choosing a file. A File Explorer is a little less focused, and lets the user browse around without a clear objective.
My question is not about native operating system UI / L&F emulation. At all. I'm asking about the basic capability to display the contents of the filesystem using icons and thumbnails. The style and borders etc are not part of my question.
EDIT
I'm looking for something like this
Notice how it's different from this (JFileChooser)

JFileChooser will do that if you are wanting something built in to Java.
https://docs.oracle.com/javase/7/docs/api/javax/swing/JFileChooser.html

If you are not using Swing but SWT (like Eclipse) you can use SWT FileDialog

You could use the AWT library to customly render the entirety of Explorer. Whilst the only hard part about this is correctly using layout managers to get components exactly where you want them and adding event listeners for each button, using AWT wouldn't make it look like Explorer on different operating systems because AWT uses the native system components.
You could check if the OS is not Windows and then use Swing if it isn't. In that case, you'd have to retexture every single used component such that its look and feel is the same as your targeted Windows version. Even if you did that, you'd still have to somehow change the JFrame's look and feel, which is possible using dark magic, but quite obscur. You can do this in a very quirky way, just setUndecorated(true) and manipulate the JFrame's boundaries until it lets you draw outside the JFrame, so that you can draw the Windows' decoration around it without resizing the Window. On top of that, you'd also have to check if it's maximised, as maximized windows don't quite look the same in Windows.
To cut things short, just use JFileChooser if you just want to allow the user to select one or multiple files. There isn't really any point in recreating Explorer, but if that's what you want to do, I'm not stopping you.

SWT for Windows Mobile: UI Architecture

I have a Windows Mobile application written in Java that uses AWT for the user interface. I am looking at porting the UI to SWT. I got a hold of the SWT libraries for windows mobile and I started looking at what work will be involved in actually porting it over. I think the first thing I have to decide is how to handle a large number of screens in the application.
In AWT the UI is basically a single java.awt.Frame with CardLayout. Each screen is then just an extension of java.awt.Panel, and is added to the Frame. Then whenever we need to change to a different screen we just set that panel to the top-most.
SWT doesn't have such a layout manager (and I'm not even sure if that is the best/most efficient way of doing it anyway, since the system resources associated with every screen in the application are always held). One way I thought of doing it was that each screen would be its own org.eclipse.swt.widgets.Shell. Switching from one screen to another would involve a display manager class creating the new screen (shell) and disposing of the old one (not sure of the performance hit here of creating the shell and all of the widgets every time the screen is shown?). I am not sure though if having multiple shells in one mobile application is a good idea??
Does anyone have any suggestions on the best way to handle multiple screens in a mobile application using SWT? Is there an equivalent to the method we are currently using in AWT, i.e. CardLayout? Or am I right in thinking that this is not really the best way of doing it, given the use of resources for every screen, even if they are not being displayed?

So the answer to my own question seems to be that there is in fact a StackLayout in SWT, which is pretty much identical to CardLayout in AWT. So I can use that and the job of porting from one to the other is pretty easy because they act in the same way.

Not sure how it would play out in Windows Mobile, but MigLayout is a great layout manager for SWT, which may support the kind of layout you describe.
Check out its demos.

Design a GUI for a J2ME app

How do I create a J2ME app for cellphones with a GUI similar to the menus you see in Java games? I've tried MIDlets with Netbeans but they only show you one GUI element at a time. (textbox, choice, login, etc)
And which Java IDE would you typically design these GUIs in? Netbeans or Eclipse? and is IntelliJ IDEA usable for this aswell?
Do I have to write/get a library that draws GUI controls to screen via bitmap functions .. and keeps track of the keys pressed for focus?

Try to use LWUIT - nice UI toolkit for j2me:
https://lwuit.dev.java.net/
http://lwuit.blogspot.com/

You can also use minime: http://code.google.com/p/minime/
It's an open source GUI library for j2me. miniME works on canvas level (lowest level in j2me) to draw every control so your UI will look exactly the same whatever the handset it'll be running on. Other advantage are:
- miniME uses its own event loop to manage user controlled event (botton pressed, softbar, ..), so you Application will "behave" the same whatever the handset.
- miniME support the concept of Views and stack of view, in order to make navigation between different view/screens very easy.
Here is an example: A View is what you have on the screen at a given moment (for example the main menu screen), then to go to a sub menu, you create a new view, and by calling a simple API, you push it in the stack of Views. The previous view (the main menu) is still existing, but inactive. When the sub menu view complete his work (for example, user press back, or do a selection), you can just go back to the previous view by calling a pop api.

Your question is a bit vague to give a specific aswer, but you might want to check out LWUIT or Polish, you can develop both with either Eclipse or Netbeans.
As far as designing GUIs go, neither IDE will help from a visual perspective. J2ME UI development is all done in code, beyond creating any initial graphics in a proper graphics editor you don't get to see your output until you test.
Read up on the LCDUI package documentation which explains how the UI classes work and the differences between the 'High-level' and 'low-level' APIs.

I can't comment on which IDE to use - but I do know that to create custom UI (like the ones you see in J2ME games), you have to explicitly draw the GUI controls.
Beware that you may need to customize the GUI depending on the target phones. You have to cater for different screen sizes, key pad configurations, default theme etc. This would probably mean that you need different builds for things like different screen sizes which would drive up your Java Verified certification costs (if you need it).
You may be able to find a set of nice looking UI controls that you can buy online and use (try J2ME Polish). The easy way out of course, is to use default J2ME controls :)

Links to many j2me GUI libraries: link1, link2
I know that kuix is not bad and free - watch demo.
But i prefer to make my own gui elements - this is much more flexible (but takes some time).
As for IDE - you may want to make some kind of gui-editor tool, construct interface in it, save result to some file, and read it from your app.

It's way too cumbersome to write your own GUI, especially since there are so many available these days. If you're familiar with desktop development in VB.Net and C#, you might find "J2ME GUI" easy to use. You can download it from http://www.garcer.com/. It has a similar feel and makes it easy to learn. This is the kind of GUI that I expected to come standard with MIDP2 when I started mobile development. Would have solved a lot of issues.

If you are familiar with web stuffs then you can use KUIX (kalmeo.org/home/index) framework having xml and css supports. In place of It you can use also Polish framework (www.j2mepolish.org) it's also uses the xml in easy way rather than kalmeo kuix framework.

Range Slider in Java

Hi i was wondering if any has heard of a Java component that provides a range slider. A slider, that is, with two knobs that define a range in the min max values rather than just one.
I found on the web a JRangeSlider in the perfuse library but i have two issues with it.
First (and not that important) is that it has it's own visual style and does not change and blend in with the used look and feel.
Second (and REALLY important for my app) is that when you setEnable(false) on it nothing happens!! You can still use the slider. The reason i want to disable it is that i have a new thread running at some point in my program that alters a value that the range slider also affects. I want to simply disable the slider while my thread is running and enable it after that.
Any thoughts?

I believe you are using an older version of RangeSlider. If you still need it, please make sure you check out the latest release. Here is a screenshot of it under different look and feel. Regarding the look is not so good, we are now using the same look and the JSlider of the L&F you are using. The screenshot below are from under Windows 7, Mac OS X Aqua, Windows XP and Metal respectively.
Screenshot of RangeSlider from JIDE Common Layer

JIDE has an open-source RangeSlider in its Common Layer. You can try it out by downloading JIDE's webstart demo.

I'm not sure what the look and feel of your app is...but you could always give BiSlider a shot:
bislider: BiSlider Home Page

Am not aware of any other than whats been mentioned, but a suggestion for your second problem would be to change the model to a static model (with suitable values) at the same time you disable it. That way it will be guaranteed not get updated.
When you enable it, remember to switch it back to the original model.

Beautifying a SWT application on Mac

SWT is designed to be cross-platform, so it can run on a Mac. The problem is it commits the cardinal sin of Macland - it's UGLY. Toolbars don't look like Mac toolbars, status bars don't look like Mac status bars, etc.
Does anyone have any experience in making an SWT application look more like a Mac application? For example, by making platform-specific JNI calls via the 'OS' class in SWT? If so, how difficult was it?
(This question arises because we are looking at porting an existing SWT app designed to run on Windows)
Thanks

This is usually problem of Swing not SWT (SWT is directly linked to OS/framework provided widgets) - a quote from A gentle introduction to SWT and JFace 2:
SWT is a library that creates a Java
view of the native host operating
system GUI controls. It is host
implementation-dependent. This means
SWT-based applications have several
key characteristics:
1. They look, act, and perform like "native" applications.
2. The widgets provided reflect the widgets (the components and controls) provided on the host operating system.
3. Any special behavior
of the host GUI libraries is reflected
in SWT GUIs.
The pre 3.5 Milestone used to use Carbon framework and now the 3.5+ supports both 32/64bit Cocoa framework 1 so perhaps that has caused you confusion? Or can you be more specific, give us the version you use and some screenshots / sample code to reproduce?
I have been developing java application based on SWT/Eclipse RCP for a while on OSX and have not found and major problem with look&feel (of cause it does not 100% comply the Apple HID 3 as it complies with Eclipse UIG)

The best I can offer is to use either MacWidgets or Quaqua which are both free and in different stages of maturity. The bad news would be that they are both Swing based which is probably not what you want to hear.

You can make your application look and behave like mac application easily. Apple supplies a application called JarBundler with it you can put your menu items up where they belong it will also build a double click able executable, and you can set a icon.
Swing components on Mac OS X looks a lot like their cocoa components, and for OS X you can set some special flags that will make them just like their cocoa counter parts, such as you can set a flag for a JTextField and make it look like cocoa search field.
Also all Macs come with java pre-installed so thats one less worry.

I created support for the Mac OS native toolbar first for Carbon then for the Cocoa version of SWT. At the time I managed to transfer the eclipse perspective switcher to a native toolbar. I had no Obj-C experience so the Cocoa version was more work than the Carbon version, but when all is told, it is not really hard. After supporting the toolbar, I wrote some code to support Alpha Compositing, native image transparency, hardware accelerated effects (CAAnimation). For these, the more difficult part was to understand why some APIs were not even available to be generated by the Eclipse JNI generator. Turned out that the python bridge generator that provided by apple had not been upgraded for the Obj-C 2.0 Property syntax. When I fixed that, I was able to have the SWT JNI Generator spit out the missing APIs. From there, using them was the easy part. You can find some partial pieces of this in the eclipse.org bugzilla server.
I can't say it is always simple, but if you already know Obj-C, then you should be able to do anything you want. A couple days ago I started working on SWT Cocoa again, to add support for ARGB images (as opposed to the limited transparency support offered by ImageData).
Good luck.

I often use the odd "platform queries" to tweak an app. For example, its not really about dressing up an app and more about (for example) making the exit menu option say "Quit" on Mac and "Exit on windows. There are some Mac style guidelines that I can't get round like this but it may help.
See Patform.java for the switching class and ExitAction.java for an example of its use.
Good luck with it :D