On Tue, Aug 07, 2001, Nick Lamb [EMAIL PROTECTED] wrote:
IMHO you'd be better off just using:
wad://home/raph/slimy.wad/p/alien.foo
This can be handled today in Gimp 1.2, see url.c
Non-interactive stuff would go exclusively through these URLs while the
interactive user would also
On Wed, Aug 08, 2001 at 01:54:53PM +0200, Raphael Quinet [EMAIL PROTECTED] wrote:
No, using a special protocol in the URI will not work, because it
then how about appendign a space and then attr=value pairs? spaces are not
valid in uris. other options incldue { } or other characters not allowed
On Wed, Aug 08, 2001, Jens Lautenbacher wrote:
On 08 Aug 2001 16:10:31 +0200, [EMAIL PROTECTED] wrote:
the problem is that # is not nestable. and the file system layer might
want to use it itself.
Hmm? No. Fragments are interpreted by the UserAgent.
Exactly. As I wrote in my previous
On Wed, Aug 08, 2001 at 05:05:23PM +0200, Jens Lautenbacher [EMAIL PROTECTED] wrote:
the problem is that # is not nestable. and the file system layer might
want to use it itself.
Hmm? No. Fragments are interpreted by the UserAgent.
so, who is the user agent, gimp or the gimp? the file
On Wed, Aug 08, 2001 at 05:22:44PM +0200, Raphael Quinet [EMAIL PROTECTED] wrote:
and then interpret it locally. As far as I know, there is nothing
that prevents the URI from having one or several # in the fragment
Except rfc2396, which specifically disallows this ;)
The other characters
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:
so, who is the user agent, gimp or the gimp? the file system layer is part of
the gimp, for sure.
Hello? The FS or a web or a ftp server is the Server conceptually.
The UA (gimp) loads the whole Document (a file maybe containing
multiple
On Wed, Aug 08, 2001 at 01:54:53PM +0200, Raphael Quinet wrote:
If we want to avoid 404 errors from the web servers, we could decide
to use # instead of / as a separator between the real file name
and the extra path to the image. I initially thought about this and
then rejected the idea
On Wed, Aug 08, 2001 at 07:49:54PM +0200, Jens Lautenbacher [EMAIL PROTECTED] wrote:
so, who is the user agent, gimp or the gimp? the file system layer is part of
the gimp, for sure.
Hello? The FS or a web or a ftp server is the Server conceptually.
The UA (gimp) loads the whole Document
On Wed, Aug 08, 2001 at 06:52:39PM +0100, Nick Lamb [EMAIL PROTECTED] wrote:
That creates an equivalent problem to your original one. If you really
want gimp-devel to believe that you routinely load remote WAD files
from HTTP then I'm going to have to ask that they also believe that users
On Thu, Aug 09, 2001 at 12:42:33AM +0200, Jens Lautenbacher [EMAIL PROTECTED] wrote:
yes of course, but where's the difference in our problem here?
that the user agent is the gimp and might interpret fragment identifiers
- at leats some underlying library might (and should) do that. my point
is
This is going to be a bit long, but here is a quick summary: I would
like to change the API to the load/save plug-ins by adding one extra
parameter. This parameter would be ignored by almost all current
plug-ins, but it would be useful for the file formats that can contain
multiple images. For
On Tue, Aug 07, 2001 at 05:28:15PM +0200, Raphael Quinet [EMAIL PROTECTED] wrote:
3) Changes to the plug-in API
The File-Open dialog would behave as follows: if the given path leads
to a regular file, open it as usual (no extra path). If the path does
A loong time ago I hacked the gimp to
On Tue, Aug 07, 2001 at 05:28:15PM +0200, Raphael Quinet wrote:
4) Feedback
Any comments?
IMHO you'd be better off just using:
wad://home/raph/slimy.wad/p/alien.foo
This can be handled today in Gimp 1.2, see url.c
Non-interactive stuff would go exclusively through these URLs while the
Hi,
Raphael Quinet [EMAIL PROTECTED] writes:
3) Changes to the plug-in API
The File-Open dialog would behave as follows: if the given path leads
to a regular file, open it as usual (no extra path). If the path does
not exist, then try to remove the last element from the path and see
if
14 matches
Mail list logo
