Re: .oafinfo and icons



Maciej Stachowiak wrote:
> 
> Anders Carlsson <andersca@gnu.org> writes:
> 
> > Hello,
> >
> > I had a discussion with miguel about the new bonobo selector and the
> > fact that we need some sort of icon reference in the .oafinfo files.
> >
> > The problem is that an .oafinfo file may not necessarily reside on the
> > same machine as the program browsing the .oafinfo file.
> >
> > So, miguel and I agreed that the best (easiest) way would be to just
> > have an attribute which points to the file.
> >
> > This means that icon paths in non-local .oafinfo files could point to
> > icon files who don't exist.
> >
> > But we won't care about that, since we're more likely to have local
> > .oafinfo files than non-local ones. To quote miguel:
> >
> > <miguelmx> This is not Federico-land
> 
> Well, part of the purpose of OAF is to make remote activation work
> nicely. When people start using Bonobo for doing real distributed
> applications, this will make a real difference.
> 
> I personally think having the icon embedded in the oafinfo file is
> reasonable. It could either be required to be an XPM, or be uuencoded
> or base64-encoded. Another possibility is to let it be a URI and make
> one of the possibilities a "data:" URI, that will allow things either
> way, but I don't know if making oaf depend on gnome-vfs is good.

Making OAF depend on something not network transparent (through
gnome-vfs or not) ruins the whole point IMnsHO.

Base64 encoding the file would make sence. This is what LDAP does too so
its not even without precedent. I don't much care if the encoding is
done by OAF (the deamon) or by whoever writing the .oafinfo files.

./borup




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]