Re: [Gimp-developer] Re: Gimp menu thumbnail
Hi, myself wrote: We want to allow plug-ins to register an icon together with their menu entry and I'd prefer this solution over trying to create an icon automatically. I'm sorry, I hadn't looked close enough. Of course this is essentially what you did. I was under the impression you had managed to create the icons automatically by applying the respective filter to the wilber icon. We should consider using GParam and GParamSpecs as defined in GObject for an overhaul of the Gimp plug-in protocol. This needs some serious thoughts and discussions so we get it right and we should definitely consider extendending the plug-in registration to allow for menu icons when we do this. At the moment, the Gimp core is under heavy development, so I'd like to delay the implementation a little so we don't break everything at the same time, but it might be a good time to start to think about it... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Auto save?
On Tuesday, 7 Aug 2001, Michael Soibelman wrote: Well, one of those plug in crashes and it's all gone. ??? Please let us know which plugin crashing causes the entire GIMP to crash. This is a very serious bug. The whole point of plugins is exactly to isolate the main GIMP program from crashing plugins. If a plugin crashes and takes out the main program then we may as well not have bothered. I repeat: if a plugin crashes and kills the main gimp program, *please* file a bug report! Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
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 need an Open, and possible Save As... handler for the WAD file itself, which would simply be a browser or other UI for picking sub-directories and files. No, using a special protocol in the URI will not work, because it should still be possible to retrieve the file using any protocol such as http: or ftp: (the only difference being that you only use a part of it). For example, I would like to be able to load the following images (the first two are based on existing URLs): http://www.microsoft.com/favicon.ico/16x16x4 ftp://metalab.unc.edu/pub/Linux/games/doom/doomv18.wad.gz/S/S_SKY1 /home/bofh/lart.tiff/page3 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 later because local files can have a # in their name, but this should not be a problem if the Gimp always starts by trying to open the local file with the full path (if no protocol is specified) and then tries a second time without the part that follows the crosshatch sign. So the examples above would become: http://www.microsoft.com/favicon.ico#16x16x4 ftp://metalab.unc.edu/pub/Linux/games/doom/doomv18.wad.gz#S/S_SKY1 /home/bofh/lart.tiff#page3 These URIs are in accordance with RFC 2396 which defines the URI syntax. Chapter 4.1 of RFC 2396 specifies that the fragement identifier (the part that follows the crosshatch) has to be interpreted locally by the user agent after the retrieval of the object, which is exactly what we want to do. The semantics of the fragment identifier depend on the media type of the retrieved data, which is also what we want to have. On Tue, Aug 07, 2001, Sven Neumann [EMAIL PROTECTED] wrote: I don't think this is a good solution to your problem. It is in no way compatible with others programs or file system layers we might want to use in the future (like gnome-vfs for example). If we follow the URI syntax described above, then I think that it would work well. It is important that the virtual path contains the real file name first, followed by the name of the image within this file (the fragment identifier) so that we can use any protocol to fetch the file. Also, the semantics of the fragment identifier will be interpreted by the plug-in after having retrieved the data, and this part cannot be done by a file system layer. For example, a Doom WAD file contains several types of images that are stored in different formats: the floor and ceiling textures are 64x64 flat bitmaps, the wall patches have a variable size with 1-bit transparency using RLE compression, and so on. These images have no file extension or magic number that could be used to get their type; their format depends only on their position within the file: the path /F/... is used for floor textures (stored between F_START and F_END) and implies that they are 64x64 flat bitmaps, while the images under /P/... are wall patches (stored between P_START and P_END). Furthermore, all images are indexed and implicitely refer to one or several indexed colormaps that are also stored in the file, in a section called COLORMAP. Loading an image from a WAD file must also load the colormap from the same file, or ask the user for an appropriate colormap if the WAD file does not contain one. All these semantics are specific to the manipulation of images and are not suitable for integration in a file system layer. How is this supposed to work with non-local files? I don't think we want to wait for timeouts or interpret File not found error messages from a web|ftp|nfs|smb server while recursively stripping off stuff from our filename. If you want to support special filetypes that support filesystems inside files, please stay with standards and use a correct URI. As Nick already pointed out, the current API already supports this sort of stuff. If it needs additions or changes, we can of course change it now during the development cycle towards 1.4, but please let us find a reasonable solution. If we use the # as a separator, that would solve the problem for non-local files. RFC 2396 specifies that the user agent must strip anything after the # before sending the request, and then interpret it locally after having received the data. This means that we will not get any timeouts or errors as long as the file exists, because the Gimp will fetch the real file directly. The local files are allowed to contain # as part of their name (if they are specified without using a protocol prefix), and in this case the strategy can be as I described previously: try first
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
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
in uris. or 8 bit characters (still not allowed in uris etc..)
should still be possible to retrieve the file using any protocol such
as http: or ftp: (the only difference being that you only use a part
of it).
the question is, could it hurt us doing things like this:
http://www.microsoft.com/favicon.ico subimage=16x16x4
of course, there is a user interface issue: users like to enter broken
uris (usually a cutpaste issue).
and the extra path to the image. I initially thought about this and
then rejected the idea later because local files can have a # in
their name
wenn, if we insist on uris in the api this is not a problem as # must be
escaped. but it's bad because of other reasons: # makes sense for http
uris (e.g. xpointers!) already, so we would have this:
http://...#fragment#subimage
or
http://...#subimage#fragment
both of which are wrong.
anything after the # before sending the request, and then interpret
the problem is that # is not nestable. and the file system layer might
want to use it itself.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and APIchange for load/save plug-ins
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. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
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 mail, the user agent must send the request without the fragment identifier (anything after the first #) 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 identifier (actually, section 2.4.3 of RFC 2396 is not really helpful about that, but we can assume that it would be accepted). Take a look at chapter 4 of RFC 2396 that defines the fragment identifiers: http://www.ietf.org/rfc/rfc2396.txt The other characters that Marc proposed (spaces or 8-bit characters) are not valid in URIs and their behavior is undefined (they should be url-encoded). Taking one image from a multi-image file matches very well the concept of fragment identifier, so I think that # is the best choice. Many people are already familiar with the meaning of this character in a URI. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
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 system layer is part of the gimp, for sure. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
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 that Marc proposed (spaces or 8-bit characters) are not valid in URIs and their behavior is undefined (they should be url-encoded) That's the whole point, that they are not valid in URI's and as such it's not possible to find a URL that would clash with our definition. Using # means that common URI's to find documents (including #fragment) might suddenly clash with gimp, since the gimp interprets # as the image component. Here is how I see it: - # precludes using fragments to subselect ressources, since only one #fragment is allowed in an URI. - # is the natural thing to choose sub-objects - other characters thta are not valid in a uri make this unamigious - other characters are unnatural Another option would be ot use something like this: ...#gimp(name) ...#gimp(subimage=name) ...#subimage(name) ...#entry(name) ...#image(name) or soemthing alike, which would make our fragment identifers coexistent with other fragement identifiers. (and soemwhat off-topic: the uri definition with respect to characters is a single bug: it requires character sets that are strict (bytewise!) supersets of ascii and, worse, gives no possible way to interpret it. so I say that using # twice, even if forbidden would not be a problema t all ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
[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 images) and interprets the fragment identifier locally -- according to the type of the document. This is more or less for what fragment ids where invented in the first place... There is also not more than on # needed. The uri would only clash if there are UAs who already have some widely accepted meaning for a fragment id in e.g. an animated gif. There are none. And if there were, I suppose it's quite probable that they would use the FID much the same way and not for e.g. addressing a coordinate in the image (or any other random stupid thing one could think of) jtl ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
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 later because local files can have a # in their name, but this should not be a problem if the Gimp always starts by trying to open the local file with the full path (if no protocol is specified) and then tries a second time without the part that follows the crosshatch sign. 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 routinely create files called foo.wad#Q/S_SKY1 serious Further, this problem is actually blocking your original proposal for users being able to save their Doom textures back into the WAD. With the wad:// URI scheme and associated interactive browser we can make this work seamlessly but with your #fragment solution it becomes harder to make it work at all without second guessing the user. /serious Raph, don't let me stop you if you're sure this is the Right Thing, but maybe you should consider bolting Doom itself into Gimp, so that we can just use weapons/ tools to retexture things from inside the game and see the results instantly? :) Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
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 (a file maybe containing multiple images) and interprets the fragment identifier locally -- i assumed that gimp does have a file-system layer. or otherwise who handles paths that really are urls for example? will every plug-in implement it's own http:// parsing+fetching? no, i guess gimp handles this, the file system layer within gimp, specifically. The uri would only clash if there are UAs who already have some widely accepted meaning for a fragment id in e.g. an animated actually, it's dependent on the media type. and my concerns are not about compatibility to current browsers or servers but in the future. it would be bad if gimp became successfull and would create/user uri's internally that cnanot be parsed by other programs (not even like: oh, i can't parse this). my suggestions make them unambigous. that they would use the FID much the same way and not for e.g. addressing a coordinate in the image (or any other random stupid thing one could think of) well, xpointers are quite new and use their own namespace, and i think that's for a reason. gimp should also use it's own namespace. yes, it might not make a difefrence in the future, but I expect the difefernce between path and uri to go away completely in the future, and it's betetr to be safe and sorry then. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
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 routinely create files called foo.wad#Q/S_SKY1 Well, gimp should not work routinely only (at the moment it does with respect to the plug-in api, and everybody agrees that this is a bug that will be fixed eventually). Also, invention does not come from limiting ourselves to the common case. otherwise i think out-of-band information might be better in the end. or use fragment identifiers ina sensible way. I also think that uri's and the user interface should be seperated, i.e. the user should rarely be bothered to enter plain uris, as most people don't understand the rather complex syntax (most html writers don't, for example, so i don't epxect gimp users to do). so there must be some translation layer between user input and internal paths. which in essence means we are not limited to uri's that look nice, but can implement the right thing. users being able to save their Doom textures back into the WAD. With the wad:// URI scheme and associated interactive browser we can make The wad uri scheme sounds backwards to me. like file uris, there is no inbuilt access method available for wads. (i mean, this looks like gif:// jpeg:// and so on). Raph, don't let me stop you if you're sure this is the Right Thing, but maybe you should consider bolting Doom itself into Gimp, so that we can just use weapons/ tools to retexture things from inside the game and see the results instantly? :) ;) at least we should loudly think about the issues. i mean, nobody talks about the enw gimp core, or... so let's discuss the _really_ important topics ;) (I must admit i am quite picky about uri/url/protocol issues since they bite me every day). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] happy with gimp-print
Here's an article by somebody who's very happy with gimp-print: http://www.linuxplanet.com/linuxplanet/opinions/3689/1/ It is very complimentary. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
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 that we shouldn't just claim fragment identifiers as being plug-in namespace. why should any future app that groks uris be unable to parse these??? http://www.mozilla.org/images/mozilla-banner.gif#eeek when I type this in a web browser, there's no problem. There's in fact no problem with any app that correctly handles uris. Wrong. Some app might validly try to interpret eeek as something strange. for example, some (bad) app might want a number there and might display nothing. For some deifnition of correct this is correct, but... The problem is that nobody knows how to interpret that eeek except the gimp, and using a more verbose form at leats might give a clue that a subimage with name is meant. And not only does it not make a problem, the outcome is also the expected --- it loads the gif. You are arguing backwards. That current technology is quite low-level does not mean that it won't improve in the future. You are arguing that ua's basically thwo away fragment identifiers on images, which is the case currently, but I don't think that's what people want. I mean, the fragment identifier is there for some reason so ignoring it is not nice. GIMP on the other would maybe throw a warning for this uri, as there's no subimage of any sort in this gif. But that's just the added value we get because we decide what a fragment means for e.g. a wad file. Indeed. Why not do it as others and mark our namespace with something like subimage(xxx) or gimp(xxx)? As the meaning of a fragment is left to the media type (and the UA) there will just _never_ be a problem. Sorry, I really cannot follow you here. When that logic is applied to, e.g. URI's or form data sets I get this sentence: As the 'character set detection' of a URI or form data set is left to the server, there will just _never_ be a problem. Sorry to disagree, but I think that's just plain backwards: we need _less_ ambiguities, not more. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
