The project information window is specific to the type of project currently being worked on. This
overview explains the options available to the Python project.
General Settings
The General settings allow basic options to be set, the following
is a complete description:
Project Name
This sets the name of the project which will be displayed in the title of the CodeBench screen and
the project window. It is also used as the name of the project file
on disk, which will be added to the recent project list.
Project Base Directory
This sets the base directory that all files will be loaded from. Files can be loaded from
anywhere, but this directory will always be the default in the file requester when
adding files.
The Synchronisation settings allow you to configure how the files in
your project interact with remote servers.
This project uses a local file repository
Specify if this project should be synchronized with a remote file server.
Synchronise plugin name
CodeBench currently includes plugins for CVS and SVN use. You may enter the name in the string gadget,
or easier, select it from a file requester which is opened by the
button on the far
right.
The included example plugins are by no means complete, and as such a developer kit and documentation
has been included to allow development of different plugins. The SDK includes an example, which when
compiled, creates the cvs plugin supplied. The SVN plugin is also based on the same example code but
is slightly more advanced as it offers a system to get the user name and password via a prompt
requester. Once this option has been selected, the plugin then does its job, and it runs synchronously
meaning that CodeBench will wait until the plugin has finished transferring files.
Please see the example documentation in the
"sdk/synchronising_plugin"
directory for more information.
As a far more useful and complete example of what can be done, CodeBench also includes a full plugin
for synchronising with Subversion servers, and is known as
SVNBench. This is explained in detail in
the relevent document.
Synchronising the project is done via the
"Synchronise" menu item.
Check for repository update after loading
If the current project being loaded is specified to be synchronised with a remote repository, then
this option will automatically scan that repository to determine whether any files need to be updated
into the local "working" copy before proceeding with the project.
Check for repository commit when closing
Again, if this project uses a remote repository, then this option, when enabled, will check to see if
any files in the local "working" copy have been changed and should be committed to
the repository before closing the project.
As an added bonus, a fully featured plugin has been included for use with SVN servers, and more
details can be found here.
These settings specify ways to affect the environment that we will be working in. There are four sections,
the first deals with how the "Quick-Link" window is presented, the
next affects how the editor interprets lines after which to automatically add or remove indentation in
lines of text. The third section deals with various aspects of the actual code, whilst the last deals with
recognising files as python scripts.
Each section will be discussed in detail below for completeness, although there are many similarities with
other project types.
The "Quick-Link" window section
Identify bookmarks by this string
This is the symbol string that can be embedded into the source file. When this sequence of characters
is found, the text that comes after it is treated as a bookmark.
This is useful for marking certain areas of files so that the location can be revisited quickly. The
marker needs to be suitable as to not interfere with the general syntax of the source file.
Fold functions section
This setting will allow the function section in the "
Quick-Link" window to open in the collapsed state. This setting
is relative to the current state of the associated section.
Fold bookmarks section
This setting will allow the bookmarks section in the
"Quick-Link" window to open in the collapsed state. This
setting is relative to the current state of the associated section.
The Auto-Indentation section
This section is comprised of two lists of rules, the first for adding indentation and the second for
removing indentation (often referred to as "outdents"). Both lists work in the
same way, so both shall be described here in the same context.
Adding items can be done by clicking on the "Add Indent" or
"Add Outdent" buttons to add to each list respectively. The resulting requester asks for
a string of characters with which a match must be made for the appropriate action to be taken. Due to the highly
versatile nature of programming languages, in order to simplify this process, the strings can include wildcard
patterns exactly the same as used by AmigaDOS. This allows a level of flexibility which should meet the needs of
even the most demanding rules. Most languages use braces to delimit sections of code, and the general programming
standard is to indent the code inside the braces, which can now be automated. Adding a "{" to the indent
list will cause the cursor to be shifted in by a certain amount of columns depending on the size of the
"tab" set. A "tab" can either be a real tabulation character, or we may
opt to insert a series of space characters instead, and is a case of user preference.
To add flexibility, a string like "case #?:" can also be added. This follows the wildcard
convention and results in any line containing a "case" statement should automatically indent.
Items in either list can be removed by simply selecting them, and clicking the "Remove"
button.
The Auto-Indentation settings in this section are applicable to the current project type, rather than the project
itself. This means that the configuration of these lists will apply to all projects of the same type, and saves
having to configure the indentation settings for every project. Both the Indentation type (spaces or
TABs) and the tabulation width are applicable to the current project though. This is especially
useful when sharing code with others via a repository or other common file server, and means that every one can
submit code with a common style.
The width of the TAB (whether it be a real tabulation or spaces) defaults to 4 columns.
This allows configuration of different tabulation width settings for each project for the sake of consistency.
The Code section
Edit New File Header
When you ask CodeBench to create a new file for you, it includes a section of text at the top with some
default information pre-filled in. By clicking the button, you
can edit just what information is included in that header.
As you can see from the default header shown here, the most popular information has been included already.
The list on the right hand side includes all of the "Cookies" that can be inserted into
the file header for you.
Simply double-click any entry in the list to have it inserted into the text at the current cursor location.
Once you have saved it, this custom header will be used whenever you create a new file for use in this
project.
Edit Constructs
You may envoke the construct editor from here. More information on code constructs is available from the
editor page.
The File Recognition section allows you to tell the plugin what scripts
are to be recognised as Python scripts.
As the only requirement for a Python script is that it MUST start with a "shebang"
(a comment in Python), this makes it very difficult to determine whether a text file is
actually a Python script or not.
Python is becoming more and more popular on the Amiga, but unfortunately most instances
seem to use their own naming system for their scripts, although ".py" is by far the most common.
Therefore, the only way CodeBench can recognise a Python script is by its file suffix. Because of the
vast amount of possibilities this presents, the plugin allows you to define file suffixes that CodeBench
should recognise as being a Python script.
By default, ".py" and ".bpy" are defined, which seriously
limits the range of loadable scripts. To increase that range, we click on the
button where we can add a suffix.
As the name suggests, the first gadget is where you enter the actual file suffix. Make sure
to enter ONLY the suffix (for example: ".py3"), do NOT enter any pattern
matching characters, as these are added internally by CodeBench when trying to find matching files.
The second gadget is any optional comment you may want to add. As previously mentioned,
applications tend to use a naming convention that suits them best, so some scripts may be quite obvious
as to which application they are appropriate to. In the case of the more ambiguous suffixes, the comment
added here is shown in the main list on the environment page (as above).
Once you are happy with your addition, click the button, and the new
suffix will be added to the main list.
File suffixes you add here are not only applicable to the current project, but any
project that uses the Python project type. This saves having to enter the same information
for each and every Python project you create.
These settings allow customization of the "Help-as-you-Type" system.
The "Help-As-You-Type" section
Enable "Help-as-you-Type"
Naturally, this option turns this feature on or off as required.
The Dictionary section
The button allows changes to be made manually to the dictionary. You can edit
existing entries, or create new ones from this window.
The Lextras section
The button allows lexicon "extras" to be added to
the current dictionary without the need to fully rebuild it. "Lextra"s are simply XML
files which contain a set of help definitions that are applicable to a particular library or module.
A file requester will appear after selecting this option asking for the path to the .lextra file, and
once loaded it will start the process of adding the contents of it into the dictionary. It is advisable
to keep copies of any "lextra" files that may be downloaded, as these will probably
need to be added again in the event that the dictionary is rebuilt for any reason.
button on the far
right.
