Re: Swing Application Framework Dead
Jan Burse <janburse@fastmail.fm> writes:
Maybe supperseeded by android.app.*.
If you like to read comments regarding your
spelling, feel free to ROT13:
N ?fhccre? vf n yvtug riravat zrny.
N ?frrq? vf n cynag bihyr pbagnvavat na rzoelb.
Gurer vf n ireo ?gb fhcrefrqr?.
But I am currently facing the following problem:
Integrating different JFrame's from different
providers in one application experience. How
could this be done?
It all depends on details of the implementation
of the JFrames and the target design.
You might, for example, design the target to
be a javax.swing.JDesktopPane. In this case,
the former JFrames become javax.swing.JInternalFrame.
Depending on the source design this might be
a snap assignment or hard work. When the source
has a proper separation between the models of
the JFrames and the UI delegates of the JFrames,
it's more easy: You just need to adjust the
UI-delegate code and can ignore both its model
and also all of the internal components (I am
not sure about the last part).
You also need to merge all the former
javax.swing.JMenuBar objects into a single
menu bar. This can be done by creating a
javax.swing.JMenuBar in the main application
and then passing it into the subapplications
to be populated with menus and menu entries.
But if we are left alone with Swing, all that
we have available framework wise is the following:
- organic exit (JVM exits when all
frames are closed and only daemon threads
remain)
I love organic exit and try to accomplish it
with all my code, but I was not aware that there
even is a word for it: ?organic exit? - nice!
But I would replace the word ?closed? with
?disposed? above. A little bit sad: We have
java.io.Closeable
but no
java.lang.Disposable
. I also would prefer ?java.io.Closeable? to be
?java.lang.Closeable?. All interfaces that can be read to
have a general meaning should be part of ?java.lang?.