--- a/Tools__ProjectBuilderAssistantApplication.st Fri Nov 12 11:56:09 2010 +0100
+++ b/Tools__ProjectBuilderAssistantApplication.st Fri Nov 12 12:30:41 2010 +0100
@@ -69,62 +69,140 @@
!
help
+"
+ Packager - A Standalone-Executable Builder and Packager
-"/ Packager - A Standalone-Executable Builder and Packager
-"/ This assistant-application allows for standalone applications to be built very easily. It will generate all required classes, files, start the compilation process, generate a self-installable executable with a few mouse clicks. A simple demo application like the famous "Hello World" can be generated in a few minutes.
-"/ Prerequisites
-"/ Windows Users:
-"/ Please install either the "Borland Free Commandline Compiler Tools (bcc32)" or the "Microsoft Visual-C++" package (also free). In addition, the "NullSoft NSIS-Installer Package" is required.
-"/
-"/ Due to limitations and bugs in the Visual-C++ compiler (limit on the size of string-constants), some Smalltalk code is still not compilable (classes which contain image-resource methods for big images). Although microsoft is doing their best (a relative measure) to make things better (they increase the string-limit with every new release), they still seem to be undable to figure out how ti use malloc for string-data). We are patiently waiting for a real fix and still using bcc in the meanwhile. Therefore, we still recommend using the borland compiler suite. Please install it at its standard location ("C:\Borland") as our makefiles might still contain hard-coded pathes (yes, we are ashamed about this).
-"/ Unix Users:
-"/ You should already have the gcc compile suite (including all required header files) installed and ready to use. For a lack of time on our side, there is currently no self-installer support for Unix. The packager will generate a zipped tar file, which must be deployed and unpacked for use. This may change in the near future.
-"/ Packages, Projects, PackageIDs and ProjectDefinitions
-"/ Smalltalk basically uses two objects for packaging:
-"/
-"/ * PackageIDs (also called ProjectID's occasionally)
-"/ * ProjectDefinitions
-"/
-"/ Older ST/X versions used instances of a Project class - this is now obsolete and removed from the system (although there are still some minor uses of it, which might remain there for backward compatibility for some time, as some customers have built their own packaging scheme around it).
-"/
-"/ PackageIDs
-"/ These are simple symbols and are attached to classes and methods. If a method has a packageID different from its class, it is called an extension method.
-"/ PackageIDs must have a certain fixed format: they always contain exactly two parts, which are separated by a colon character: the module and the directory part. The module is used as main-selector on where and how the source code repository is accessed. The directory is a path below that repository. If checked out into the local filesystem, the module defines the top-level directory. Thus, if a packageID is "stx:libbasic", the corresponding sources will be found in the repository associated to the "stx" module, under the directory "libbasic". In the local file system, it will be found under "stx/libbasic". As another example, if the packageID is "exept:expecco/plugins/foo", the repository is whichever is associated with the "exept" module, and the subdirectory is "expecco/plugins/foo". The local path to the sourcefiles would be "exept/expecco/plugins/foo".
-"/ Please notice that it does make sense to associate different repositories to different modules: for example, you could setup the sourceCodeManager to use CVS access to the exept repository for everything under the "stx" module, and at the same time, use a local SVN repository for everything under the "myCompany" module.
-"/ ProjectDefinitions
-"/ These describe the contents of a project, such as the classes to include, the set of extension methods, any additional compilation information. ProjectDefinitions come in 3 flavours:
-"/
-"/ * GUI Application Definition
-"/ * non-GUI Application Definition
-"/ * ClassLibrary Definition
-"/
-"/ ProjectDefinitions are stored and managed as class-instances, located as subclasses of one of ApplicationDefinition or LibraryDefinition. As classes, they are themself managed, compiled and packaged as part of the project (and also have the same PackageID as their components). They are also treated like any other class w.r.t. source code management.
-"/ Packaging
-"/ All classes and extension methods belonging to a single package are supposed to be loaded (and possibly unloaded) together. They are also usually deployed inside a single dynamic link library ("dll", for short). In the Unix world, these are called "shared object" or "so". Finally, they are stored in a common directory both on the local file system and in a source code repository (CVS, SVN, etc.).
-"/ Structure of a Project
-"/ The artefacts as manipulated by the packager are:
-"/
-"/ * the ProjectDefinition class
-"/ This defines the type of application (GUI / non-GUI), its contents (i.e. the set of classes to be included in the binary itself and the set of library-dll's to be included in the deployed package), and some other metadata, such as icon, title etc.
-"/
-"/ * the ApplicationModel class
-"/ This defines the GUI, and is typically created using the UI-Painter.
-"/
-"/ * the Startup class
-"/ This is the first class which gets control when the executable is started; it can analyze the command line arguments, read patches or updates, start background ptocesses, and will eventually open the applications GUI.
-"/
-"/ Build Procedure
-"/ All of the three components above can be generated by the packager to provide an initial framework for further work.
-"/
-"/ After the definition of those classes, all required files are stored in a temporary build directory. This means that the above classes are filed out, and make- and other support files are generated.
-"/
-"/ Finally, the actual build process is started. This requires an external C-compiler. Under windows, both Borland-C (free download available via the internet) and Microsoft's Visual-C++ (also available for free) can be used.
-"/
-"/ A self-installing executable is built using the NullSoft NSIS package. This is also required to be installed before the packager is started.
-"/
-"/ After the build, all required files are packaged in a single install-file. This is called "MyApplicationSetup.exe" and found in the project-specific subdirectory of the build directory. For deployment, this single file has to be delivered to a customer and executed there.
-"/
-"/ Summary: It has NEVER been easier to create a GUI application.
+ This assistant-application allows for standalone applications to be built very easily.
+ It will generate all required classes, files, start the compilation process,
+ generate a self-installable executable with a few mouse clicks.
+
+ A simple demo application like the famous 'Hello World' can be generated in a few minutes.
+
+ Prerequisites
+
+ * Windows Users:
+ Please install either the 'Borland Free Commandline Compiler Tools (bcc32)'
+ or the 'Microsoft Visual-C++' package (also free).
+ In addition, the 'NullSoft NSIS-Installer Package' is required.
+
+ Due to limitations and bugs in the Visual-C++ compiler (limit on the size of
+ string-constants), some Smalltalk code is still not compilable
+ (currently, this affects classes which contain image-resource methods for big images).
+ Although microsoft is doing their best (a relative measure) to make things better
+ (they increase the string-limit with every new release), they still seem to be unable
+ to figure out how ti use malloc for string-data).
+ We are patiently waiting for a real fix and still using bcc in the meanwhile.
+ Therefore, we recommend using the borland compiler suite.
+ Please install it at its standard location ('C:\Borland') as our makefiles might
+ still contain hard-coded pathes (yes, we are ashamed about this).
+
+ * Unix Users:
+ You should already have the gcc compile suite (including all required header files)
+ installed and ready to use. For a lack of time on our side, there is currently no
+ self-installer support for Unix. The packager will generate a zipped tar file,
+ which must be deployed and unpacked for use. This may change in the near future.
+
+ Packages, Projects, PackageIDs and ProjectDefinitions
+
+ Smalltalk basically uses two objects for packaging:
+
+ * PackageIDs (also called ProjectID's occasionally)
+ * ProjectDefinitions
+
+ Older ST/X versions used instances of a Project class - this is now obsolete and
+ removed from the system (although there are still some minor uses of it,
+ which might remain there for backward compatibility for some time, as some customers
+ have built their own packaging scheme around it).
+
+ PackageIDs
+
+ These are simple symbols and are attached to classes and methods. If a method has
+ a packageID different from its class, it is called an extension method.
+ PackageIDs must have a certain fixed format: they always contain exactly two parts,
+ which are separated by a colon character: the module and the directory part.
+ The module is used as main-selector on where and how the source code repository is
+ accessed. The directory is a path below that repository. If checked out into the local
+ filesystem, the module defines the top-level directory. Thus, if a packageID is
+ 'stx:libbasic', the corresponding sources will be found in the repository associated
+ to the 'stx' module, under the directory 'libbasic'.
+ In the local file system, it will be found under 'stx/libbasic'.
+ As another example, if the packageID is 'exept:expecco/plugins/foo',
+ the repository is whichever is associated with the 'exept' module, and the subdirectory
+ is 'expecco/plugins/foo'. The local path to the sourcefiles would be
+ 'exept/expecco/plugins/foo'.
+
+ Please notice that it does make sense to associate different repositories to different
+ modules: for example, you could setup the sourceCodeManager to use CVS access to the
+ exept repository for everything under the 'stx' module,
+ and at the same time, use a local SVN repository for everything under the 'myCompany'
+ module.
+
+ ProjectDefinitions
+
+ These describe the contents of a project, such as the classes to include,
+ the set of extension methods, any additional compilation information.
+ ProjectDefinitions come in 3 flavours:
+
+ * GUI Application Definition
+ * non-GUI Application Definition
+ * ClassLibrary Definition
+
+ ProjectDefinitions are stored and managed as class-instances, located as subclasses
+ of one of ApplicationDefinition or LibraryDefinition.
+ As classes, they are themself managed, compiled and packaged as part of the project
+ (and also have the same PackageID as their components).
+ They are also treated like any other class w.r.t. source code management.
+
+ Packaging
+
+ All classes and extension methods belonging to a single package are supposed to be
+ loaded (and possibly unloaded) together. They are also usually deployed inside a single
+ dynamic link library ('dll', for short). In the Unix world, these are called
+ 'shared object' or 'so'.
+ Finally, they are stored in a common directory both on the local file system and in a
+ source code repository (CVS, SVN, etc.).
+
+ Structure of a Project
+
+ The artefacts as manipulated by the packager are:
+
+ * the ProjectDefinition class
+ This defines the type of application (GUI / non-GUI),
+ its contents (i.e. the set of classes to be included in the binary itself and
+ the set of library-dll's to be included in the deployed package),
+ and some other metadata, such as icon, title etc.
+
+ * the ApplicationModel class
+ This defines the GUI, and is typically created using the UI-Painter.
+
+ * the Startup class
+ This is the first class which gets control when the executable is started;
+ it can analyze the command line arguments, read patches or updates,
+ start background ptocesses, and will eventually open the applications GUI.
+
+ Build Procedure
+
+ All of the three components above can be generated by the packager to provide an
+ initial framework for further work.
+
+ After the definition of those classes, all required files are stored in a temporary
+ build directory. This means that the above classes are filed out,
+ and make- and other support files are generated.
+
+ Finally, the actual build process is started. This requires an external C-compiler.
+ Under windows, both Borland-C (free download available via the internet) and Microsoft's
+ Visual-C++ (also available for free) can be used (the later with some limitations as explained above).
+
+ A self-installing executable is built using the NullSoft NSIS package.
+ This is also required to be installed before the packager is started.
+
+ After the build, all required files are packaged in a single install-file.
+ This is called 'MyApplicationSetup.exe' and found in the project-specific subdirectory
+ of the build directory. For deployment, this single file has to be delivered to a customer
+ and executed there.
+
+ Summary: It has NEVER been easier to create a GUI application with Smalltalk.
+"
! !
!ProjectBuilderAssistantApplication class methodsFor:'assistant pages spec'!
@@ -142,9 +220,7 @@
pageTitle: 'ProjectDefinition Selection'
windowSpecSelector: page2_projectSelectionSpec
enterCallbackSelector: updateListOfMatchingProjects
- infoText: 'Choose an existing project definition or create a new one.
- These are subclasses of <I>ProjectDefinition</I> and define the
- type and contents of a project.'
+ infoText: 'Choose an existing project definition or create a new one. These are subclasses of <I>ProjectDefinition</I> and define the type and contents of a project.'
)
(AssistantPageSpec
@@ -153,10 +229,7 @@
isEnabledQuerySelector: #projectTypeIsGuiApplication
canEnterQuerySelector: #canEnterApplicationSelection
enterCallbackSelector: updateListOfApplicationsInProject
- infoText: 'Choose an existing application or create a new one.
- These are subclasses of <I>ApplicationModel</I> and define
- the GUI and control flow inside the application.
- Can also be left blank if the startup class does it all (stx build).'
+ infoText: 'Choose an existing application or create a new one. These are subclasses of <I>ApplicationModel</I> and define the GUI and control flow inside the application. Can also be left blank if the startup class does it all (stx build).'
)
(AssistantPageSpec
@@ -165,10 +238,7 @@
isEnabledQuerySelector: #projectTypeIsNotLibrary
canEnterQuerySelector: #canEnterStartupClassSelection
enterCallbackSelector: updateListOfStartupClassesInProject
- infoText: 'Choose an existing startup-class or create a new one.
- These are subclasses of <I>StandaloneStartup</I> and
- start the application. Command line arguments can be
- interpreted there.'
+ infoText: 'Choose an existing startup-class or create a new one. These are subclasses of <I>StandaloneStartup</I> and start the application. Command line arguments can be interpreted there.'
)
(AssistantPageSpec
@@ -176,9 +246,7 @@
windowSpecSelector: page5_specifyIncludedClasses
enterCallbackSelector: enterContentsSpecification
canEnterQuerySelector: #canEnterContentsSelection
- infoText: 'Define which (other) classes are to be included.
- Press "<I>Scan</I>" to include all classes of the package;
- browse to edit the contents manually.'
+ infoText: 'Define which (other) classes are to be included. Press "<I>Scan</I>" to include all classes of the package; browse to edit the contents manually.'
)
(AssistantPageSpec
@@ -192,11 +260,7 @@
(AssistantPageSpec
pageTitle: 'Specify Build Directory'
windowSpecSelector: page6b_specifyBuildDirectorySpec
- infoText: 'Define where the build-process is to be performed.
- All generated files are created below that directory.
- After deployment, the build directory is no longer needed
- (but you can keep it for a faster compile the next time).'
-
+ infoText: 'Define where the build-process is to be performed. All generated files are created below that directory. After deployment, the build directory is no longer needed (but you can keep it for a faster compile the next time).'
enterCallbackSelector: #checkCompilerAvailability
)
@@ -206,22 +270,18 @@
canEnterQuerySelector: #canEnterBuild
enterCallbackSelector: #restoreMakeOutputsContents
leaveCallbackSelector: #rememberMakeOutputsContents
- infoText: 'Start the build-process. This will run make/bcc to compile
- all required classes and nsis to generate a self-installable
- executable. You must have the borland-cc and NullSoft NSIS
- packages installed for this to work.'
+ infoText: 'Start the build-process. This will run make/bcc to compile all required classes and nsis to generate a self-installable executable. You must have the borland-cc and NullSoft NSIS packages installed for this to work.'
)
(AssistantPageSpec
pageTitle: 'Deploy'
windowSpecSelector: page8_deploySpec
canEnterQuerySelector: #canEnterDeploy
- infoText: 'Find the installer to be deployed (or test-run the binary).
- You can open a WindowsExplorer there to copy the files for
- deployment. After that, the build directory is no longer needed
- (but you can keep it for a faster compile the next time).'
+ infoText: 'Find the installer to be deployed (or test-run the binary). You can open a WindowsExplorer there to copy the files for deployment. After that, the build directory is no longer needed (but you can keep it for a faster compile the next time).'
)
) decodeAsLiteralArray.
+
+ "Modified: / 12-11-2010 / 12:27:56 / cg"
! !
!ProjectBuilderAssistantApplication class methodsFor:'defaults'!