Re: running a program in anjuta2

[Gustavo Giráldez <gustavo giraldez gmx net>]

Hi Jeroen,

On Sun, 2003-03-02 at 08:51, Jeroen Zwartepoorte wrote:
> Hey Gustavo,
> 
> I'd like your input on implementing the "Run" command in anjuta2.
> 
> The obvious items are:
> - Having the backend start the program and redirecting stdout/err to a
> GbfRunInfo (GtkTextView).
> - Having GbfRunInfo redirecting its input to the program's stdin
> (anjuta1 has some existing code for this).
> 
> I've already done some very basic hacking in this area.

Cool!

> Some more complex issues:
> - A program may need to be installed before it can be run

Actually the problem is not installing the program itself (most programs
can be run from any directory) but its dependencies, i.e. libraries,
Bonobo components, glade files, etc..

> - A program may be able to be run without installing (a test program)
> - A library cannot be run at all, but can be tested via another program.

(Totally unrelated:  Obviously libraries are out of the question, unless
we have a swig plugin or something :-)  From the manual page: "swig
generates wrapper code needed to integrate C,C++, and  Objective-C
functions and variables with Tcl, Perl, Python, and Guile and produces
documentation."  Maybe even pygtk-codegen.  I would kill for a plugin
which automagically lets me test a library from an e.g. python command
line.)

> Which brings us to "Run Configurations". Having a Run Configuration
> which contains information on what program to run, which parameters to
> pass to it, which environment variables need to be set etc. This needs
> to be part of gnome-build, so all backends use it.

I don't think GbfRunInfo should be related to a project backend.  I see
it more as an isolated object/widget, which can be configured (program
name, environment, arguments), and then ran (gbf_run_info_run or
something).   Something like a g_spawn_async_with_pipes wrapped around
an object, and with an (maybe optional) i/o widget.  Btw, why not use a
Vte widget instead of a GtkTextView?  Should be easier to get working.

> Where to store this information? This can either go in the "workspace"
> or in the project file. (session.xml or project.anjuta file). What do
> you think? The obvious way to store the info is in XML of course.

Given the above comments, I think run configuration should be definitely
stored in the workspace, since all information is not project related.

What we do need is a way for the project backend to tell which of its
targets might be executed, so you can get a list of the programs for the
"Run..." dialog and you know whether to put an "Execute" option in the
project popup menu, as John suggested.

Another thing I think would be cool is the GbfRunInfo object to provide
output filtering.  This is, provide some simple text filtering rules,
such that lines matching those rules are not output to the i/o widget,
but instead are reported via a callback.  Some uses for this feature
could be a valgrind plugin (unless of course it provides an easier way
to interface it), or simply a GLib's warning collector.  If designed
well, you could even re-use the widget for compilation parsing.  Anyway,
just a thought.

Too much dreaming for today :-)

Hope this helps,
Gustavo

> 
> Have i missed anything so far?
> 
> Thanks,
> 
> Jeroen
> 
>