Re: Anjuta

[Naba Kumar <kh_naba yahoo com>]

Miguel de Icaza wrote:

> On 29 Mar 2001 19:12:48 +0530, Naba Kumar wrote:
> >
> > Yotam Medini wrote:
> >
> > > > I cannot do local installation for Anjuta?
> > > >
> > > > A: Take my advice. Do system installation (you must be root to do
> > > > that) and not local installation. Anjuta depends on Gnome for
> > > > supplying pixmaps and Anjuta help works with gnome-help-browser, non
> > > > of which will be happy if you do local installation.
> > >
> > > But on the machine I work at work - I do _not_ have root acceess.
> > > Many Gnu-packeges can build themselevs given any prefix, for
> >
> >             ^^^^^^^^^^^^^^
> >
> > >
> > > target installation, but still refer to more basic packages
> > > installed elsewhere. May be you would like to consider such appoach.
> > >
> >
> > Have you tried with any gnome packages? Gnome packages
> > install the pixmaps in the dir $(datadir)/pixmaps/<package_name>
> > and the help files in the dir $(datadir)/gnome/help/<package_name>.
> >
> > where, $(datadir) is the output of: gnome-cofig --datadir.
>
> GNOME applications should really not be installing pixmaps in that
> directory.  Applications should install their pixmaps (and any other
> data files) in the locations specified by the user at configure time.
>

But as far as I know, *almost* all of the packages install there
pixmaps and help files in the gnome-data dir (of course, that
could be because I haven't tried any local installation).


> The reason some people *might* be using the directory specified in
> gnome-config --datadir is because they are trying to use
> gnome_unconditional_pixmap_file() or gnome_unconditional_datadir_file()
> which are historical functions that really serve no purpose[1].

> Those functions should really be gnome-libs internals only now, and
> every application should really roll-out its own system for locating
> data files.

The function I use is:

full_path = gnome_pixmap_file (short_path);

This function apparently prefixes gnome pixmap dir
to the short_path. As far as the name of this function
is concerned, it looks like a standard utility to find
pixmaps for gnome applications and not something
that is reserved for gnome libs only.

Also consider the pixmap path given in the menu
UIINFO struct for creating menubar. The path
given there is relative to the gnome pixmap dir,
unless, of course we give absolute paths there
which is inherenly very difficult, if not impossible,
to provide to the static data structures used for
UIINFO structs.


> My personal favorite to address this problem is to define in your
> Makefile the installation directory, like this:
>
>     -DAPPLICATION_DIR=\""$(datadir)\""
>
> And then in your C code, you do:
>
>     f = fopen (APPLICATION_DIR "/mydatafile.dat");
>
> Miguel.
>
> [1] Those functions made sense back in the early days when gnome was a
> single tarball, and the functions were in gnome-libs to allow other
> components in the system to locate their data files.

The problem is not with datadir. A package can very well manage
its own datadir (Anjuta does do it and projects created with Anjuta
are also given the appropriate interface with the configure generated
defines for the datadir.

Since, pixmaps can be considered as application data, this can be
more or less handled by the application just like it would handle
any other data (with the expense of messing our code and
contrasting the idea of automation with GnomeApp widget).

The basic problem is with the help files. Gnome searches the help
in the directories that the gnome help system is configured[2] for.

If application start installing all the help files in their own local
datadirs, then two things happen:

1) Gnome won't be able to find the topic.dat file which
    contains the basic help menu configuration of the
    application (configuring it manually is not-so-good option).

2) All the help files would be scattered in the file system.
    This problem is being addressed by scrollkeeper, but
    nevertheless we will be in deep grieve.

Another problem is with the *.desktop file which is
now a days  included in almost every gnome packages.
Where am suppose to put it in a local dir so that
it comes up with the users system menu (but not
on the desktop).

I think this problem should be addressed more
deeply by the the gnome core developers and
provide a more handy way to handle these
files than just the patch with g_strconcat().

-------------------------------
[2] Gnome help system can be configured to
accept custom help dirs, but that would be too
crumbsome if the user is told to do it
manually for every package that is
locally installed.
-------------------------------

--

Regards,
-Naba

-------------------------------------------------------------
God is the tangential point between zero and infinity.

-- Alfred Jarry
-------------------------------------------------------------