Re: .oafinfo and icons

[Maciej Stachowiak <mjs eazel com>]

Miguel de Icaza <miguel@helixcode.com> writes:

> > > But we won't care about that, since we're more likely to have local
> > > .oafinfo files than non-local ones. To quote miguel:
> > 
> > You still need to handle the non-local case.
> 
> For the non-local case, the worst case scenario is you get the stock
> icon.  What is the problem with this?
> 
> In two years since we have been using CORBA, I have seen barely people
> using remote setups.  It is not even a common setup, and not
> something you distribute to your friends typically.
> 
> And if you do, you do not pass only a .oafinfo file, you typically
> hand over an RPM that would nicely include your .oafinfo, and your
> nice icon.

Miguel,

People are not writing distributed apps that are distributed among
multiple machines with Bonobo today. But I believe (and hope!) they
will in the future.

Working for 100% of cases is not hard - just encode the icon data in
the oafinfo file directly. This is a bit inconvenient but not a huge
burden.

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.

> > Yes, but this is not "use a solution because it works for one thing" land
> > either.
> 
> It works for 99.99% of the cases.  For the 0.01% it will just mean
> that you have to copy another file.

OAF in theory lets me set up a remote service where I don't have to
distribute anything to the user for them to use that component; they
must merely use the proper activation ID to get my specific component
from my machine, or make a query that prefers my machine. I don't need
to distribute an oafinfo file _or_ an icon. Adding distributing the
icon as a requirement for things to be perfect would be lame,
especially since 


> 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.

> The option "use the filename" works with every existing tool.  So I
> think we need to get our priorities right here.

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.

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.

 - Maciej