Commit b3a120d0 authored by Johannes Schmid's avatar Johannes Schmid

Fixed in cvs plugin

parent 9b670fe1
2005-02-26 Johannes Schmid <>
* plugins/cvs-plugin/cvs-execute.c
- Use weak reference on mesg_view and reuse tab if
it still exists to avoid cluttering message manager.
- Fixed bug in cvs remove
README, HACKING: Updated Added check for libsvn
2005-02-29 Naba Kumar <>
* plugins/file-manager/an_file_view.c,
......@@ -5,21 +5,13 @@ Development mailing list or the project maintainer)
Getting Started:
The first thing to do is to decide whether you want to work on Anjuta or
Anjuta2. Briefly, Anjuta2 has a much cleaner architecture, so if you are
a component/OOP freak, or are hear to teach yourself good GNOME
programming, anjuta2 might be the right place. OTOH, Anjuta has many
more features and is (arguably) more actively developed and maintained.
So, if you want to contribute to an IDE that works now and use it
yourself, IMO you're better off contributing to Anjuta. There are plans
for a merge of some sort in the future.
Second thing to do is to get a build working. Both anjuta and anjuta2 can be
First thing to do is to get a build working. Both anjuta and anjuta2 can be
built using jhbuild, which is the recommended way to build GNOME
2.2. and Anjuta(2). It is advisable to use '--enable-warnings
2.x and Anjuta2. It is advisable to use '--enable-warnings
--enable-debug' with configure while building anjuta if you want to hack
on it. Anjuta can be used to hack on Anjuta, and there is a anjuta.prj
file in CVS for this purpose.
on it. Anjuta can be used to hack on Anjuta, and there is a anjuta.anjuta
project file in CVS for this purpose.
Once you have got anjuta built and loaded in itself, the most important
thing is to decide what to work on (the TODO, as you say). There are
......@@ -47,16 +39,10 @@ and RFE database at the sourceforge page ( You
can also have a look at the reasonably up-to-date TODO file we maintain
in the source code.
4. Working on the porting anjuta features to anjuta2. This is a noble
4. Working on the porting anjuta 1.2 features to anjuta2. This is a noble
undertaking but likely to be hard work, and probably not suitable for
newbie developers.
5. Working on porting anjuta2 architecture to anjuta. This is probably
the most difficult one. However, if you are an experienced developer,
you'll find this enormously rewarding and very challenging. Read the
ROADMAP file that comes with the source code to understand where we are
and where we want to be in the long term. Then pick up one of the action
points and try to implement it.
newbie developers. Note that this is most code and plugins are ported but
they might not yet be as good as in anjuta 1.2.
......@@ -65,20 +51,20 @@ Resources:
- CVS snapshots:
- Anonymous CVS Access: cvs -z3 co anjuta
- Mailing Lists:
- Bug database:
- Feature Requests:
- Bug database: (the module is called anjuta)
- Feature Requests: See Bug database above
- Forums:
- IRC: (Channel: #anjuta and #devel-apps)
IMPORTANT: please be careful about using Anjuta to develop Anjuta.
Any instabilities in the development version may cause problems.
Anjuta is written using a mixture of C and C++. You will require
the standard GNU tool chain and current stable GNOME libraries to
build and work with the Anjuta sources.
New code should be in C as long as it does not touch the scintilla
editing component. C++ code is only allowed in the editor or if you
need a library which is only availible in C++.
Submitting patches:
......@@ -126,6 +112,8 @@ cvs -d:pserver:annocvs[123]
Details about the anonymous CVS servers can be obtained by issuing the
command "host"
(Note: You can of course use the cvs plugin for all this stuff)
4) If the patch is big or is not high priority (i.e. things other than
stability patches), then either send it to the lead developers directly
(cc-ing them together is a nice idea), or post it on the sourceforge page.
......@@ -143,6 +131,34 @@ bug-544912.diff as the names are more meaningful. Include the bug number
or your name and the date in the name of the file. Thanks!
Coding style:
Anjuta coding style differs from file to file but usually following example
show some kind of standard:
function ()
if (x == y)
Well, both void* pointer and void *pointer are used...
(to be extended)
- Please try to write Oo-code using GObject as baseclass. This will lead to
better design and clear module separation.
- If possible gnome-vfs is preferred to standard UNIX IO functions.
- Try to avoid forward declaration of static functions, try to keep them in
order instead
- Use descriptive variable names like filename instead of f and cur_item instead
of i.
- If you use a "hack" please add a comment and say why this could not be done
General source structure:
When editing the code, adding new classes or methods, etc. please
......@@ -151,9 +167,9 @@ conform with the style already followed in the source files.
If a section of code will require further work, please add helpful
comments of the form /* FIXME: ... */
* _cbs suffix - callbacks
* _gui suffix - UI definitions for windows, dialogs etc.
Separator in filename:
You should always use - instead of _, meaning anjuta-plugin.h
insted of anjuta_plugin.h
Key elements:
* src/ - the main Anjuta sources
......@@ -182,7 +198,7 @@ include/ -> scintilla/include
These are used to compile libscintilla.a, the library which provides
the bulk of Anjuta's editing functions.
The interface into Scintilla is in src/aneditor.cxx. This is based on
The interface into Scintilla is in src/aneditor-*.cxx. This is based on
SciTE and a lot of care needs to be taken when merging code, since it
combines several different files from the SciTE source tree and is
quite flexible in the ways that they are used. Also, note that lexer
......@@ -253,8 +269,9 @@ graphics and do not use the filenames directly.
The current architecture is rather monolithic and inflexible. There is a drive
undergoing to change this. Please have a look at the ROADMAP file for details.
You can find the API documentation of anjuta in the
"Anjuta Developers Reference Manual" devhelp book!
1) Event Driven:
......@@ -268,230 +285,40 @@ class updates etc. While asynchronous event-driven implementation is more
complex than it's synchronous counter part, it gives a smooth and non frustrative
operation. :-)
1a) Executing external commands in non-blocking mode:
launcher (launcher.[c,h]) is the class responsible for executing external commands in
non-blocking mode. launcher_execute takes 4 arguments, first is the command
to be executed, second is the stdout callback, stderr callback and the child
terminated callback. They are called when there is chars available in the
stdout and stderr and when the child terminates respectively.
/* Start a job. */
/* command_str is the command to be executed */
/* stdout_func is the callback to be called when chars are received in STDOUT from the process */
/* stderr_func is the callback to be called when chars are received in STDERR from the process */
/* commnad_terminated is the callback to be called when the job is completed or terminated */
gboolean launcher_execute(gchar* command_str,
void (*stdout_func)(gchar*),
void (*stderr_func)(gchar*),
void (*command_terminated)(gint status, time_t time));
The three callbacks stated above should be of the following prototype:
/* The function names are arbitary */
void stdout_func (gchar * chars);
void stderr_func (gchar * chars);
void command_terminated (int return_status, time_t total_time);
Refer to the file launcher.h for further information and
Remember to use this launcher instead of gtk/glib non-blocking IO interface.
1b) Process synchronization:
The rest of the processes, which are quick (less that 1/10 sec) in execution
or whose IO interfaces are not necessary, can safely be forked just like a
normal fork. For shorter execution wait() system call would suffice it's
synchronization when the process ends, but for longer jobs, asynchronous
notification is suggested.
For asynchronous notification of child termination, a few additional steps
are needed to be done just after the fork() call. Register the child pid
with the call to anjuta_register_child(). It takes two arguments, first the
child pid and second, the callback to be called when the process with that
pid terminates. The call to the callback is shipped with the child exit status.
/* Registers the child for asynchronous notification */
void anjuta_register_child_process (pid_t pid,
void (*callback) (int status, gpointer user_data),
gpointer user_data);
/* Unregisters the child. No notification will be emited thereafter. */
void anjuta_unregister_child_process (pid_t pid);
The callback should be of the following prototype:
/* function name choosen arbitarily */
void child_terminated_callback (int status, gpointer user_data);
For further information, refer to the file anjuta.c.
WARNING: Do not hook up the signal SIGCHLD, for the similar purpose. Just use
the above method to perform the same thing. SIGCHLD is used by Anjuta
internally to manage the children.
For details how to use the anjuta-launcher interface consult the
IAnjutaLauncher reference.
2) How to add new menu items in the Main Menu:
The files to look for are main_menubar_def.h, mainmenu_callbacks.[ch] and
main_menubar.[ch]. You might also need to have a peek at controls.[ch].
2a) How to add new menu items in the Edit->Insert menu:
There are 6 files which need to be updated.
* main_menubar_def.h - update insert_submenu_uiinfo (and others
e.g. inserttext1_submenu_uiinfo) to add the item, help text and name of the
callback function.
* main_menubar.h - update struct _EditSubMenu with the name of the menu widget
* main_menubar.c - update the array of items referenced around mb->edit.insert_*
* mainmenu_callbacks.h, mainmenu_callbacks.c - declare the name of the new callback
function in the header file, and add the new function itself based on the
existing on_insert_*() functions
* controls.c - update the list of gtk_widget_set_sensitive calls with a new entry for
the menu widget em->insert_* (as specified in main_menubar.h)
Anjuta is using GtkUIManager for creating it's menus. Libanjuta does provide
some wrapper functions in anjuta-ui.h. Take a look at the *.ui files in the
plugins, the Plugin docs in the reference and read the GtkUIManager docs for
3) How to add new toolbar items in the Toolbars:
Have a look at toolbar.[ch] and controls.[ch].
This is alos done by with ui files, see above.
4) Dialogs and Windows:
When adding new dialogs or windows, please ensure...
- the WMCLASS attribute is set to a unique value
- a default icon is defined
Dialogs will take the Anjuta app icon by default, but windows (GtkWindow) will
need the following lines added to their creation code:
#include <libgnomeui/gnome-window-icon.h>
Dialogs and Windows should be build using libglade. They should be HIG compliant
5) Property/Config management:
Anjuta does not use gconf (at least, not now), and instead has its own config
manager/properties manager. The source for this is in src/properties.cxx.
There are some advantages in using this over gconf, including the ability to
do variable substitution. Anjuta needs these advantages to operate properly.
Even though gconf have additional advantages, we are not really concerned about
them right now. In future, things may change, though.
When Anjuta was started, there were not many application support libraries.
To cope up with the requirements, anjuta had to implement the supports within
itself. And it is still going.
6) Global shortcut keys:
The following callback (located in anjuta.c) :
on_anjuta_window_key_press_event (GtkWidget *widget,
GdkEventKey *event,
gpointer user_data)
is called when some key is pressed in the whole environement, because the
event is triggered off by the main GtkWindow. It has been created for navigating
between the different buffers (Ctrl-[Shift]-Tab).
It's aim is to implement global shortcut keys. For now on, it only works in the main window.
Note : It's possible to install such an handler in the other windows if it's
really needed, so the new callback can propagate the event to app (the GnomeApp)
and we'll have a central place for those shortcuts.
6a) How to add a global shortcut:
It's pretty self-explanatory, but here's the "how to" :
Just before the callback, you have some GDK modifiers "shortcuts", just because
it's a pain to write this each time, and the 'm_' stuff makes you see in an instant
which modifiers are used (Shift or Control) :
enum {
m__ = 0,
These are to ease filling the structure (1) :
You add an id for your shortcut in the enum :
enum {
Then, you add a line with the modifiers used, the GDK corresponding key, and the
shortcut id.
static ShortcutMapping global_keymap[] = {
{ 0, 0 0 }
Finally, you add a case in the callback's switch :
on_anjuta_window_key_press_event (GtkWidget *widget,
switch (global_keymap[i].id) {
case ID_xxx:
return FALSE;
Anjuta has a very powerful project management. You can read the docs of
AnjutaPreferences in the reference.
7) How to add a new project type:
It is currently a bit difficult - the code is spread around and not
very consistent.
Things to do as a start:
- in project_type.c and add an array for your project type (this
is well-commented). Add it to the load_project_type function.
- in project_dbase.h: Add your project type to the enum PROJECT_TYPE_*
- in wizard_gui.c: create_project_type_selection_page():
Add an icon to the list for the project type and define it in pixmaps.h
(If you are a bad artist, it might be good to ask for help with this on
the mailing list)
- appwiz_page1.c: Add your type in on_wizard_app_icon_select()
So that was the easy part ;-)
Now search for every occurrence of PROJECT_TYPE_* and project_type_* in
the code, and decide if you have anything to add (there are about
10 places where it occurs).
Good luck!
FIXME: For no take a look at the project types in
8) How to correctly credit people:
Anjuta Version 1.2.1 Release
Anjuta Version 1.3 Beta Release
Copyright (C) 2000-2002 Naba Kumar
Copyright (C) 2000-2005 Naba Kumar
Home site =>
......@@ -126,18 +126,25 @@ REQUIREMENTS:
Installation should be a breeze on any reasonably up-to-date *NIX system
with GNOME 1.4 (Ximian GNOME recommended). The following are the minimum
requirements. Development platform is RedHat Linux 7.x with GNOME 1.4
with GNOME 2.x .The following are the minimum requirements. Until the code
reaches some kind stability it is always good to use the latest stable
version of the libraries
1) Installation
# From Tarball:
* GNOME libs (1.2.8 or later)
* GTK libs (2.0 or later)
* GNOME libs (2.0 or later)
* gnome-xml (aka libxml1) (1.4.0 or later)
* ORBit (0.5.0 or later)
* gnome-print (0.35 or later)
* gnome-print
* gdk-pixbuf
* scrollkeeper (0.1.4 or later)
* scrollkeeper
* pkgconfig
* gnome-build (from GNOME CVS, no tarball yet)
* gdl (from GNOME CVS)
* glade3 (from GNOME CVS) to build glade plugin
* libsvn ( to build subversion plugin
# From CVS:
* All the requirements for tarball
......@@ -145,43 +152,19 @@ requirements. Development platform is RedHat Linux 7.x with GNOME 1.4
* Automake 1.4 (or later)
* Autoconf 2.13 (or later)
# From Src RPM:
< RedHat 6.1 or upwards >
* gnome-libs & gnome-libs-devel (1.2.8 or later)
* libxml & libxml-devel (1.4.0 or later)
* ORBit & ORBit-devel (0.5.0 or later)
* gnome-print & gnome-print-devel (0.35 or later)
* gdk-pixbuf & gdk-pixbuf-devel (0.15 or later)
* scrollkeeper (0.1.4 or later)
* pkgconfig (0.10 or later)
* automake (1.4)
* gcc & gcc-c++ (2.95.2 or later)
* RPM (4.0 ?)
* xml-i18n-tools or intltool (for documentation)
# From RPM Pkg:
< RedHat 7.1 or upwards >
* gnome-libs & gnome-libs-devel (1.2.8 or later)
* libxml (1.4.0 or later)
* ORBit (0.5.0 or later)
* gnome-print (0.35 or later)
* gdk-pixbuf (0.15 or later)
* scrollkeeper (0.1.4 or later)
* automake (1.4)
* RPM (4.0 ?)
2) Running
< RedHat 6.1 or upwards >
* GNOME (1.4 full install recommended)
* X-Windows, any window manager should do as long
as the gnome libs are installed)
* Bash command shell
* GNU Indent
* gnome-terminal
* gnome-help-browser (or Nautilus or mozilla)
* yelp to browse docs
* Automake/Autoconf
* GNU Make
* GNU C/C++ compiler
* GNU debugger (gdb)
* GNU grep
* For cvs plugin: cvs
......@@ -191,50 +174,18 @@ INSTALLATION:
and '#' is the shell prompt. You must be logged in as root to
install Anjuta.
1) Get the tarball anjuta-1.0.tar.gz
1) Get the tarball
2) copy it to your home dir.
3) Unzip it by typing: #gunzip anjuta-1.0.tar.gz
4) Extract it by typing: #tar -xvf anjuta-1.0.tar
5) Change dir: #cd anjuta-1.0
6) Type: # ./configue
7) Type: # make
8) Type: # make install
3) tar xfzv anjuta-<version>.tar.gz
4) Change dir: # cd anjuta-<version>
5) Type: # ./configure
6) Type: # make
7) Type: # make install
That's all. If everything went smoothly, congratulations. If not,
then please check that you have the latest libgnome and libgnomeui
installed. Get them if you don't have and repeat the above steps.
# From RPM Pkg:
Note:- The package as an example is taken as anjuta-1.0-1.i386.rpm
and '#' is the shell prompt. You must be logged in as root to
install Anjuta.
1) Get the RPM package anjuta-1.0.0-1.i386.rpm
(visit for latest release).
2) Change to the directory containing the rpm package.
3) Type: rpm -Uvh anjuta-1.0.0-1.i386.rpm.
That's all. If everything went smoothly, congratulations.
Otherwise, some dependency error will come up. You will have
to install the required components first. Then repeat the above.
Because anjuta was becoming too big, it was decided that the rpm
be split into various pieces. The following are all the rpms
available for a perticular release:
anjuta-1.0.0-1.i386.rpm [Base anjuta]
anjuta-i18n-1.0.0-1.i386.rpm [localization support]
anjuta-docs-en-1.0.0.i386.rmp [English documentaion]
anjuta-docs-ja-1.0.0.i386.rmp [Japanese documentaion]
The base package is all you need to have for woring in English
locale and without any documentation (except README and other
basic docs).
If you want to work in different locale other than English,
install the anjuta-i18-* package. And if you want anjuta manual,
tutorial and faq, install anjuta-docs-* package of the language
you want (currently only en and ja are available).
......@@ -573,6 +573,181 @@ if test "$have_ftruncate" = yes ; then
CHECK_PROTO(ftruncate, unistd.h)
dnl **********************************************************
dnl check if we have svn libraries to build subversion plugin
dnl (stolen from kdevelop ;-)
dnl **********************************************************
AC_MSG_CHECKING(for svn libraries)
APR_CONFIGS="apr-config /usr/local/apr/bin/apr-config"
[[ --with-apr-config=FILE Use the given path to apr-config when determining
APR configuration; defaults to "apr-config"]],
if test "$withval" != "yes" -a "$withval" != ""; then
for VALUE in $APR_CONFIGS ; do
if $VALUE --cflags > /dev/null; then
if test $APR_CONFIG ; then
AC_MSG_RESULT([not found])
dnl AC_MSG_ERROR([APR is required. Try --with-apr-config.])
APR_INCLUDE="`$APR_CONFIG --includes`"
APR_LIBS="`$APR_CONFIG --link-ld --libs`"
dnl APR util
APU_CONFIGS="apu-config /usr/local/apr/bin/apu-config"
[[ --with-apu-config=FILE Use the given path to apu-config when determining
APR util configuration; defaults to "apu-config"]],
if test "$withval" != "yes" -a "$withval" != ""; then
for VALUE in $APU_CONFIGS ; do
if $VALUE --includes > /dev/null; then
if test $APU_CONFIG ; then
AC_MSG_RESULT([not found])
APR_LIBS="$APR_LIBS `$APU_CONFIG --link-ld --libs`"
AC_MSG_CHECKING(for Subversion svn-config)
[ --with-subversion-dir=DIR where Subversion is installed ],
if test -z "$SVNCONFIG"; then
_SVNCONFIG="`svn-config --prefix 2> /dev/null`"
if test -n "$_SVNCONFIG"; then
if test -x "$SVNCONFIG"; then
SVNLD="`$SVNCONFIG --ldflags`"
SVN_LIB="`$SVNCONFIG --libs --cflags` -lsvn_client-1"
dnl ugly hack for subversion svn-config problems in 0.14.x, to be removed when svn-config is fixed
SVN_INCLUDE="`$SVNCONFIG --includes` -I$_SVNCONFIG/include/subversion-1/"
AC_MSG_RESULT(not found)
dnl just a fallback to debian's config so that it works for me :)
[[ --with-svn-include=DIR Use the given path to the subversion headers.]],
if test "$withval" != "yes" -a "$withval" != ""; then
if test -z "$SVN_INCLUDES"; then
SVN_INCLUDES="/usr/local/include /usr/include"
AC_MSG_CHECKING([for Subversion headers])
if test -f $VALUE/subversion-1/svn_types.h ; then
if test $SVN_INCLUDE ; then
AC_MSG_RESULT([not found])
SVN_LIBS="/usr/local/lib /usr/lib"
[[ --with-svn-lib=DIR Use the given path to the subversion libraries.]],
if test "$withval" != "yes" -a "$withval" != ""; then
AC_MSG_CHECKING([for Subversion libraries])
for VALUE in $SVN_LIBS ; do
if ls $VALUE/libsvn_client-1.* 1>/dev/null 2>1; then
if test $SVN_LIB ; then
AC_MSG_RESULT([not found])
[[ --with-neon-config=FILE Use the given path to neon-config when determining
Neon configuration; defaults to "neon-config"]],
if test "$withval" != "yes" -a "$withval" != ""; then
if $VALUE --cflags > /dev/null; then
if test $NEON_CONFIG ; then
AC_MSG_RESULT([not found])
SVN_LIB="-L$SVN_LIB $APR_LIBS -lsvn_client-1"
dnl ***************************************************************************
dnl Checks for Additional stuffs
dnl ***************************************************************************
......@@ -20,7 +20,8 @@ SUBDIRS = . \
cvs-plugin \
macro \
class-gen \
patch \
## This a temporary measure to insure anjuta does not crash due to old plugin.
## Make sure there are no old plugins left
......@@ -135,6 +135,7 @@ on_cvs_remove_response(GtkDialog* dialog, gint response, CVSData* data)
anjuta_cvs_remove(ANJUTA_PLUGIN(data->plugin), filename, NULL);
gtk_widget_destroy (GTK_WIDGET(dialog));
......@@ -37,6 +37,12 @@
static GtkWidget* status_text;
static void
on_mesg_view_destroy(CVSPlugin* plugin, gpointer destroyed_view)
plugin->mesg_view = NULL;
static void
on_cvs_mesg_format (IAnjutaMessageView *view, const gchar *line,
AnjutaPlugin *plugin)
......@@ -152,7 +158,8 @@ on_cvs_message (AnjutaLauncher *launcher,
const gchar * mesg, gpointer user_data)
CVSPlugin* plugin = (CVSPlugin*)user_data;
ianjuta_message_view_buffer_append (plugin->mesg_view, mesg, NULL);
if (plugin->mesg_view)
ianjuta_message_view_buffer_append (plugin->mesg_view, mesg, NULL);
static void
......@@ -226,13 +233,21 @@ cvs_execute_common (CVSPlugin* plugin, const gchar* command, const gchar* dir,
mesg_manager = anjuta_shell_get_interface
(ANJUTA_PLUGIN (plugin)->shell, IAnjutaMessageManager, NULL);
plugin->mesg_view =
ianjuta_message_manager_add_view (mesg_manager, _("CVS"),
g_signal_connect (G_OBJECT (plugin->mesg_view), "buffer-flushed",
G_CALLBACK (on_cvs_mesg_format), plugin);
g_signal_connect (G_OBJECT (plugin->mesg_view), "message-clicked",
G_CALLBACK (on_cvs_mesg_parse), plugin);
plugin->mesg_view =
ianjuta_message_manager_get_view_by_name(mesg_manager, _("CVS"), NULL);
if (!plugin->mesg_view)