Am Die, 2002-06-04 um 17.50 schrieb Dave Camp:
> * Project Manager
>
> I'm not working on it much now, except for the new project wizard, but
> I think I'm going to start sticking my dirty little hands into it
> sometime soon.
>
> And here's what I'm working on in the short, middle, and long term
> (amended a bit after the discussion on anjuta-devel).
>
> Short term (ie this weekend) :
>
> I'll probably check in the new project wizard that I'm working on.
> Right now it only generates bonobo components ('cause that was the
> most interesting project to implement). I'll probably try to make it
> support simple gnome applications before I check it in (if I don't get
> around to that this weekend I'll just check it in how it is).
>
On anjuta-devel lists sourceforge net we have discussed a new template
system for project and file generation. There does not exist any code
and even when we start coding it will be mostly anjuta independent but
it might be useful if you participate in the design decisions. The core
is by Biswa, here is a copy:
>The library should be able to handle:
1) Creating a new project customizing it automatically as per user
specified options.
2) Creating a new source file from template with customization.
3) Adding code blocks from template with variable substitution.
I've been thinking about this for the last few days and here is a brain
dump of what I think should be the (very high level design):
---------------------------------------------------------------------------
The template language:
----------------------
The basic and most important part is to chose a good template language
language which is usable from C as well as from shell scripts. I've been
looking around and it seems that NEW ( http://www.flyn.org/projects/new/
) is a good candidate. It is free, available as a standalone program as
well as a C library and has some builtin functions for standard
substitutions which I think are pretty useful. Of course, there are many
others, but IMO, the main things to look for here are:
1) Size: It should be as small as possible since we'll probably have to
bundle it with Anjuta.
2) It should be usabe from C as well as from Shell scripts.
3) It should be free (beer + speech)
4) It should be feature-rich.
Now onto the main stuff:
Project Templates:
------------------
A project template should consist of:
1) A logo (PNG image) and a preview image - these will be shown in the
main wizard page.
2) A gzipped tarball containing the actual stuff (code, build files,
etc.).
3) Pre-processing script (optional)
4) Post-processing script (optional)
5) a Glade GUI file (more on this below)
6) A manifest file (XML) which will contain:
(a) The names of the files corresponding to (1) to (5)
(b) The name of the project.
(c) Names of the widgets in the GUI file and their types.
The files corresponding to one project will reside in it's own directory
(or as a ZIP/JAR file). The name of the manifest file will always be
manifest.xml since the project creator will need to know this to show
all project types and to read the necessary data from it during project
creation.
Going into a bit more detail:
The gzipped tarball will contain all the code and other files required
for a fully runnable project. The files, however, may not the be exact
code but can contain:
(a) variables which will be substituted by their values during
expansion of the tarball.
(b) Conditional code blocks which will be written or not based
on
environment variables.
(See below on how these are going to be set)
The pre-processing script will be optional and might contain stuff that
need to be customized based on user's project directory, set variables,
etc. The post-processing script will serve a similar purpose but will
run after the code has been generated. All variables will be passed
through environment variables.
Now for the GUI file. The first page of the wizard will be exactly like
it is now, showing the project type names and the correspoding image
(which IMO should be a preview + a logo, sort of mix between what
KDevelop has and what we have currently). Once, the user selects the
project, the top project directory and other stuff common to all
projects, the GUI kicks in and shows it;'s window using libglade. Now,
here is the interesting (and tricky part). The project wizard will have
a piece of code which will read the widget names from the manifest file
and the corresponding type. When the user has finished whatever he/she
wants to do and presses 'Next' (this part will be mandatory and a
callback will be automatically attached to this button by Anjuta), the
callback will, for each widget name, get the corresponding widget using
lookup_widget. Then, depending on the widget type, it will use
gtk_entry_get_text/gtk_togglebutton_get_state/etc. to read the values in
those widgets. Then, it will use setenv()/putenv() to set name/value
pairs where <name> is the widget name and <value> is the corresponding
value. Then it will fire the pre-processing script, extract the tarball
to the project directory and run the post-processing script, which will
have access to these env. variables.
Basically, what I have in mind is conceptually similar to Kaptain
(http://kaptain.sf.net/). This will give us an extremely flexible design
for generating new project types without ever touching the code. Plus,
it would be exceedingly simple to generate new project types.
New Source File From Template:
------------------------------
We can reuse the substitution library and the Glade concept here as well
- only, for single source file, this will be much simpler. We'll just
need a Glade file and a template file with the code in it (with the
usual placeholders + conditional code blocks). In this case, using
scripts will be a overkill - we'll simply use the template library from
the callback to substitute stuff on the fly.
New code blocks:
-----------------
Virtually the same as above, but will write to the current text buffer
instead of creating a new file and opening it. For this and the source
file templates, the Glade file should probably be optional since there
will be many code blocks and file templates which will only need very
basic information like name, date and file name.
Which brings me to global variables. Some variables will be
automatically set by Anjuta. Examples of these are:
(a) User information (Name, company, Email, etc.)
(b) Current Projects directory
(c) Current file name if any
(d) etc.
------------------------------------------------------------------------------
Well that's about it - the so-called grand plan :-) Greatly in need of
discussion, refinements, ideas, flames, etc ;-). If you noitice, I've
deliberately kept this as Anjuta-independent as possible, since, as you
say, the PM of Anjuta (and Anjuta itself, what with Anjuta2, etc.) is in
a state of flux and our goal should be to create something which can be
used in both the 1.x as well as the 2.x code base.
Regards,
Johannes
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil