You are not logged in.

Dear visitor, welcome to Jabaco - Community. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

theuserbl

Intermediate

  • "theuserbl" started this thread

Posts: 436

Date of registration: Dec 20th 2008

  • Send private message

1

Wednesday, October 21st 2009, 5:23pm

Three ideas: Lib-directory, removing WinLAF, Project-zip

Hi!

Yesterday I have again played a little bit with Jabaco. And me comes three ideas for a possible future Jabaco:

1. A Lib directory.
At the moment there is in the Jabaco-directory one file called Jabaco.jar
JABACO_HOME\Jabaco.jar
But I think, it could be nice, if instead of that, there existing a lib-directory. Where all jar-files in it, are automatically included in new Projects.
Then the Jabaco.jar file could also be devided in more files:
JABACO_HOME\lib\Jabaco200910070500.jar
JABACO_HOME\lib\nativecall-0.4.1.jar
JABACO_HOME\lib\winlaf-0.5.1.jar
And as I said, if anybody wants to include easily more libraries to its project, he don't need to go over the ClassBrowser, including its own jar, and selecting all. He only need then to copy the jar-file to the lib-directory.

2. removing WinLAF.
WinLAF needs a lot of space and have lots of Classes. But is it really needed?
Here some statistics:
Console Application (392) = NativeCall ( 8 ) + WinLAF ( 71 ) + Jabaco ( 175 ) + rt.jar ( 138 )
This means, if you create a new Console-project, there will be automatically 392 classes imported. 71 of it are from WinLAF.

As you can see here, if you choose a SDI-Application for a new project, there are also not much more classes imported:
---------------
Console Application = Class Library (both 392)
SDI Application = MDI Application (both 399)

Console Application (392) -> Web Applet (395):
+ /java/awt/Font
+ /java/awt/GraphicsConfiguration
+ /java/io/Serializable

Console Application (392) -> SDI Application (399):
+ /java/awt/Font
+ /java/awt/Image
+ /java/awt/image/BufferedImage
+ /java/awt/image/RenderedImage
+ /java/awt/image/WritableRenderedImage
+ /java/awt/Transparency
+ /java/io/Serializable
-----------------
Btw: If you create a new Console Program and added then everyting: Class Library, Interface, Resourcefile, ...., then the imported classes are exactly like that of the SDI- and MDI-Applications.

So, WinLAF needs much space and consits much classes. In the result the compiler and IDE works partly slower.
But for Windows there existing Suns WindowsLookAndFeel and other platforms have its own SystemLookAndFeel or the MetalLookAndFeel.
Is WinLAF really needed?


3. Project-zip
Only a idea. But compiled programs can be compiled to jar-files (which are zip-files).
The XML-based document formats OpenDocumentFormat and OfficeOpenXML are also zipped XML-files.
So, would it have advantages to create instead of one .jba file, a lot .jsrc files and a res-directory, one zip file (for exaple .jbprj) in which all files are included?
One advantage of it, could be, that it is easier to copy and move a project. You have then only one file instead of an directory.
On the other side, you could eveytime zip and unzip the project-directory yourself, so it helps not soo much, if Jabaco doing it.
Only a thought.

Greatings
theuserbl

Rate this thread
WoltLab Burning Board