Some Minor Things

[Jason]

I've been making a list of things that seem weird, and have been
holding off on posting them until I got the mouse working in Linux.
Now that it's (hopefully) working, I think its time. This in
particular is a few of the small and trivial things that I was
confused about. Shortly I'll also be posting some threads covering a
few of the more major things I've been considering.

~~~~~~~~~~~~~~~~~~~~

In /build.xml I noticed that "svn.version" target does not currently
grab the SVN version (instead using the default value of "dev"). I'm
not entirely clear on why this is... Sure, putting "dev" as a suffix
makes it pretty clear that its a development version, but then again
so does an SVN version number...

~~~~~~~~~~~~~~~~~~~~

What's up with the "thin" version of JTablet? Since it includes
neither classes for native libraries nor the 0.9.x backwards-
compatibility layer, I assume that its for bundling with applets that
would like to use JTablet even if it hasn't yet been installed on the
end-user's system.

If this is the case, I'm not certain its worth maintaining 2 different
versions since it only saves ~30 KB. Of the JTablet-enabled applets I
know of, only Shi-Painter is less than 100 KB in size, so its not like
it'd make a big dent in download time...

~~~~~~~~~~~~~~~~~~~~

Back with the original version of JTablet, Java would load the
"jtablet" library. Now Java loads the "jtablet2" library. Since
JTablet2 includes a JTablet-classic emulation layer, wouldn't it make
sense to name the new library "jtablet" as well? I don't do much
Windows development, but it seems like DLL hell would only be a
concern if somebody only got the JAR or only got the DLL... Not a
"normal" case, certainly.

~~~~~~~~~~~~~~~~~~~~

[Marcello Bastéa-Forte]

On Fri, Jun 25, 2010 at 4:35 PM, Jason <kille...@gmail.com> wrote:

I've been making a list of things that seem weird, and have been
holding off on posting them until I got the mouse working in Linux.
Now that it's (hopefully) working, I think its time. This in
particular is a few of the small and trivial things that I was
confused about. Shortly I'll also be posting some threads covering a
few of the more major things I've been considering.

Great! I appreciate this kind of push-back, since I know there are some design issues like this that should be resolved before a beta/final release.

In /build.xml I noticed that "svn.version" target does not currently
grab the SVN version (instead using the default value of "dev"). I'm
not entirely clear on why this is... Sure, putting "dev" as a suffix
makes it pretty clear that its a development version, but then again
so does an SVN version number...

This code was giving me trouble (inserting a : in the version string, which caused compilation problems on mac os x). Never got around to fixing it.

 

What's up with the "thin" version of JTablet? Since it includes
neither classes for native libraries nor the 0.9.x backwards-
compatibility layer, I assume that its for bundling with applets that
would like to use JTablet even if it hasn't yet been installed on the
end-user's system.

Correct. 

If this is the case, I'm not certain its worth maintaining 2 different
versions since it only saves ~30 KB. Of the JTablet-enabled applets I
know of, only Shi-Painter is less than 100 KB in size, so its not like
it'd make a big dent in download time...

I would agree in principle, but fortunately, no maintenance is required. The build script uses pro-guard to automatically strip out unnecessary classes. In addition to saving some KB, it includes logic for determining what version of JTablet is installed.

 

Back with the original version of JTablet, Java would load the
"jtablet" library. Now Java loads the "jtablet2" library. Since
JTablet2 includes a JTablet-classic emulation layer, wouldn't it make
sense to name the new library "jtablet" as well? I don't do much
Windows development, but it seems like DLL hell would only be a
concern if somebody only got the JAR or only got the DLL... Not a
"normal" case, certainly.

I think your last case is exactly the problem I want to avoid.

If the user has an old JTablet installation that didn't get removed correctly, there's no recovering from this error. Since the old DLL is completely unusable by JTablet 2, it seemed like the simplest solution to avoid potential incompatibility.

I'm not sure of how this would affect Linux and on Mac OS X this isn't an issue since there was no official 0.9.x release.

 

Marcello