Re: .oafinfo and icons

[Miguel de Icaza <miguel helixcode com>]

> In the remote ativation case, you do not even have a local oafinfo
> file. You query the ObjectDirectory on the remote machine, and it
> parses the oafinfo file there. Then it gives you relevant data.

If this is the case, then you should transfer the image over a method
there: remote oaf loads the image from local file, remote oaf provides
the image and the local site never opens files.

So why do we want to encode the image inside the .oafinfo is beyond
me.

Honestly:

	1. If you do not need the .oafinfo file for the remote
	   activation case (you sait it above), 

	2. And you are querying a remote interface.

	3. And the remote site has access to the icon file.

   Then:

	What is the point in embedding the image inside the .oafinfo?
	I can only think the idea sounds appealing but solves
	absolutely *NO* problem (because there is no problem that cant
	be solved by adding a sequence<octed> get_image_stream (void)
	method) and it just makes handling the image harder.

> > Also, adding the icon to the .oafinfo file means that 100% of the
> > existing tools can not be used to edit the icon and that special
> > handling needs to be done for 100% of these tools.
> 
> No, you just need tools to encode and decode. In fact, they
> exist. They are called `uuencode' and `uudecode', if we want to use
> that. In any case they will be trivial.

I am sorry but this is completely bogus.

There are no tools that can edit .oafinfo files with "embedded"
images.  You need manual intervention or a special tool to pull the
image and add an image.  

> There is no existing tool that will work on the oafinfo file at
> all. You will need to get the filename out of the oafinfo file
> somehow. This is somewhat, but not much, easier than extracting and
> decoding the data from the oafinfo file, especially if we provide a
> tool to do the latter.

This one is trivial to handle though.

An artist does not even need to care about this.  He just needs to add
the file to the CVS, and configure will do all the magic of replacing
the filename in the .oafinfo with the installation path for the icon
filenama.e

> Basically I am saying we should not lock into a system that optimizes
> for the world of today only. For distributed server apps this solution
> is lame, and GNOME's object model _should_ have it as a goal to be a
> good solution there too.

Do the interface trick.