Re: FEATURE: Icon Resource in application binaries



On Fri, 18 Jun 2004 19:41:51 +0300, Ionut Cotoi wrote:
> why don't we introduce at some point resources in GNOME/GTK+ Apps? And
> by that I mean:

OK, firstly this is off-topic for nautilus-list. This sort of discussion
is better for (and I'm sure Mark will hate me for this :)
desktop-devel-list, though ideally there'd be some blue-sky-research-list
where ideas like this could be kicked around.

Secondly, this is already doable today using the csource pixbuf loader, at
least for images and icons. It's not widely used because almost all open
source APIs assume data is coming from the filing system *not* arbitrary
locations in memory. That can be fixed too.

But the real question is, do we want to?

If you haven't already done so, I suggest you read the namesys future
vision document: http://namesys.com/ - it does a credible job of
explaining why unified namespaces are a Good Thing, and why API
duplication is a Bad Thing.

What you're basically doing is saying: "the standard filesystem is not
meeting my needs, let's invent a new mini filing system and put it into a
file!". This has been done lots of times (see, OLE structured storage for
instance) and typically has lots of problems.

You need to ask yourself, what problem am I trying to solve? All you've
done here is present a solution without discussing what problems it solves.

It sounds like you see this as a way to allow programs to be distributed
in single files that run out of the box rather than need installers. But
that's not possible except in the simplest case - apps will still have
dependencies and require external infrastructure, so you will still need
installers and packages in order to ensure this is all present (or unified
platforms, or better still both).

If that is really the problem you are trying to solve and you aren't
comfortable with apt/rpm type systems then you should investigate autopackage, 
Zero Install, NeXTStep Bundles and so on.

thanks -mike




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