🚀 go-pugleaf

I think I've figured out how this works... 

The compact story:

Simplest alternative: Just copy the new 1.0.3 files on top of the old
ones, retaining the old names.

If you don't want to copy over the old files, you can instead change the
IDEClassPath in JBuilder.ini to point to the new swingall.jar. In this
case, you will also have to change all swingall.jar references in
Library.ini. (E.g. the reference in the JBCL library classpath.)

Now, if you want to be able to switch between 1.0.1 and 1.0.3, you're in
for a bit more trouble. The only reason I can think of, why anyone would
like to do this, is if the new release is not backwards compatible. I
understand that in some details, it isn't, so here goes:

1. The only way to get the IDE to switch between 1.0.1 and 1.0.3
(without copying over the lib\swingall.jar file) is to change the
IDEClassPath in JBuilder.ini. 

2. Edit the Library.ini file and change the name of the JBCL library
from [Library_JBCL 2.0] to [Library_JBCL 2.0 with Swing 1.0.1]. This
can't be done from within the IDE due to the line Features=3 in the
Library.ini file. (Please, Inprise, tell us what the valid values of
"Features" are!)

3. Add a new library (in the ide or by editing the Library.ini file),
called "JBCL 2.0 with Swing 1.0.3", which is identical with the original
JBCL library, except that it points to the new 1.0.3 Swing files. (All
three paths are affected.)

4. Repeat steps 2 and 3 for the Swing library.

This way, you can easily switch between 1.0.1 and 1.0.3 in your
applications, by selecting the right JBCL and/or Swing libraries (1.0.1
or 1.0.3). But if you want to switch the IDE, you will have to close
JBuilder, edit the IDEClassPath, and restart JBuilder.

I hope this will help someone out there!!

I am a bit worried about what will happen when we want to upgrade to
Swing 1.1. Will it be backwards compatible enough for the IDE to work
properly if we install 1.1 in the IDEClassPath? What if we simply
install 1.1 as a new library? The GUI designer will still be using the
old Swing release, so we won't see the new 1.1 features until we run the
app. Will this mean, in some cases, that the GUI designer will be using
deprecated, or even incompatible, stuff? 

I would like to hear what Inprise has to say about all this! The best
solution that I can see is to separate the classpath used by the IDE
itself and the one used by the GUI designer. Granted - this might not be
straighforward, possibly requiring JBuilder to be running two separate
VMs. But, isn't that the only way you can let the programmer switch
between different Swing releases in any useful manner? Can the GUI
designer be written so that it can make use of new features introduced
in Swing releases after JBuilder shipped? If so, how (from the user's
point of view)?

Thank you for your attention!
Class dismissed! ;)

Kjell Rilbe