Re: Status thingy.

[Dave Camp <dave ximian com>]

There was one thing I was interested in having in the anjuta2 project
wizard that I hadn't implemented (and hadn't even really thought about
how to implement).

As things stand now with anjuta2's project wizard, there are a few
different types of projects [ed note: well, there's only one.  We're
talking hypothetically here].  One is a shared library, one is a gnome
application, one is a bonobo component.

This works great, until I have an existing project with a gnome
application that I would like to add a shared library to.  It would be
nice if there was an "Add target" wizard, that could add a shared
library to an existing project, for example.  This should really share
code with a project wizard - creating a gnome-application project should
really just be creating a blank project and adding a gnome-application
target.

This is hard, at least if you're natively using configure.in and
Makefile.am (which anjuta2's project manager currently does), but it
would be nice to have.

Just a thought,
-dave

On Tue, 2002-06-04 at 12:15, Johannes Schmid wrote:
> 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