Re: Anjuta

[Naba Kumar <kh_naba yahoo com>]

Miguel de Icaza wrote:

> Basically the problem is originated by two wrong assumptions from the
> early days:
>
>         * gnome was a single tarball ;-)
>
>        * we were young and restless
>
>> 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).
>
> Which packages would that be?   If there are many of those, we should
> work towards fixing them, because it is a broken scenario.

Well, I think I am missing something here. when I said *almost*, I 
meant *almost* (execpt some gtk only based packages). All the gnome
packages install their pixmaps at $(datadir)/pixmaps/$(package) dir.

Obviously, $(datadir)/pixmaps dir is the standard dir for gnome
to put gnome pixmaps. Here the $(datadir) is the datadir confi-
gured by the gnome and not by the application.

So, as long as the gnome datadir and  the app datadir are
same, there is no problem, but when they are not same, most
(almost all) programs cannot find the pixmaps.

I did an experiment yesterday. I did three types of installations
for a gnome application.

1) prefix=/usr  (root)
2) prefix=/usr/local (root)
3) prefix=/home/naba/local (user)

Only in case of the first installation did the application
found the pixmaps and help topics (for the help menu).
And *that* installation statisfy the condition that
gnome_datadir == application_datadir.

The applications that installed pixmaps in the gnome
pixmap dirs and help files in gnome_datadir includes many 
standard gnome packages such as gnumeric, gmc, eog, gedit,
etc etc. And I am pretty sure about *almost* all gnome
packages.

I am wondering haven't the maintainers of these packages
got this complaint about local installation?

Only a very few gnome packages like Abiword (which I have a hunch
that it is a gtk app and not gnome app) maintained their
own pixmaps in their datadir.

Probably they were smart and they knew this problem would
arrive in future (so they opted for do-everything-yourself
philoshophy :-)).

If an application is forced to manage its own
pixmaps and help files, then that would very much
defy the philosophy of the 'Best desktop environment'.

> This is broken in many areas:
> 
>        people who use /opt/ setups (/opt/gnome-libs, /opt/gnumeric,
>        /opt/...)
>
>        People who compile applications on their home directories, or
>        have development setups in a separate place than their
>        "stable" GNOME foundation.
>
> So we should make sure we fix those applications.  
>
>> The function I use is:
>> 
>> full_path = gnome_pixmap_file (short_path);
>
> This function is even worse.  Again, a rookie mistake we did in the
> early days.  The problem with gnome_XXX_file compared to
> gnome_unconditional_XXX_file is that XXX looks up in the GNOMEDIR
> directory for the file which might lead to unexepcted behaviour. 
>
> I strongly recommend against using those API calls. 
> 

Is there any other API calls with gnome that take cares of
these problems without letting the author handle his/her own
pixs and helps in project's datadir?

I have the assumption that only gtk (not gnome) packages
manages their own  pixmaps and help.

I honestly beleive that we need to do something to allow
local installaions of gnome packages just like gtk and
other non-gnome packages.

I've no idea if these problems have been addressed, but 
I really feel stupid when I can't do local installation
of gnome-packages while others could be very easily done.

>> 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.
>
> It is useful for locating "standard" pixmaps (and honestly, there are
> very few of those, and given that applications tend to install in
> different locations, an app should probably not *depend* on this to
> work out).
>
>> 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.
>
> Yes, a problem that we are now addressing in Bonobo UI XML.  I
> honestly do not like the UIINFO anymore, it was good in its day, but
> now the Bonobo stuff provides the right solution.  A bit cumbersome to
> use sometimes, but the right thing to do.
>
> If anything, we could sprinkle some sugar into the problem
>
> Best wishes,
> Miguel.

BTW, Miguel, you and your frens really did a very nice job witb Bonobo.
Keep the good work up. Someday I would also like to help with the 
development of Bonobo, may be just with the documentation or something
that you ppl don't find time for.

-- 

Regards,
-Naba

-------------------------------------------------------------
To teach is to learn twice.
		-- Joseph Joubert
-------------------------------------------------------------