Re: [Gimp-developer] writing customized GTK interfaces
On Wed, Jul 18, 2001 at 04:32:09AM +0530, Deepika Sikri [EMAIL PROTECTED]
wrote:
Any help reg writing customized GTK interfaces in PERL for GIMP will
be appreciated.
Basically, it works by NOT using Gimp::Fu. If you don't need arguments
then you can call the register function, which will not open a window
but instead will just call your plugin (e.g. examples/parasite-editor or
gap-vcr).
If you want arguments then it works very much like a plug-in in C:
# register a function that's called when
# gimp requests execution for it from this plugin
Gimp::register_callback plugin_mine = \plugin_mine;
# gimp only clals us when we tell it which functions
# we implement
Gimp::on_query {
Gimp-install_procedure(plugin_mine, see Perl-Server for an example)
};
# optionally, you can define more callbacks:
Gimp::on_run { # optional
# run before any callback
};
Gimp::on_net { # optional
# when started from the network
};
Gimp::on_lib { # optional
# when started using the direct interface
};
# that's mandatory ;)
exit Gimp::main;
Inside your casllback you have to chekc the first argument (run_mode) as
usual. If you want to open a gtk dialog you should use call Gimp-gtk_init
instead of Gtk-init, because the former fetcvhes the corretc values
(ccube, visual etc..)
Thanks in advance.
if you have any questions feel free to aks them ;)
The Information contained and transmitted by this E-MAIL is proprietary to
Wipro Limited and is intended for use only by the individual or entity to which
I pity you...
recipient, you are notified that any use, distribution, transmission, printing,
copying or dissemination of this information in any way or in any manner is
strictly prohibited. If you have received this communication in error, please
and all this to a publicly arhcived mailinglist.. ;)
--
-==- |
==-- _ |
---==---(_)__ __ __ 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] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 03:43:51PM -0500, Kelly Martin [EMAIL PROTECTED] wrote: If you have to use a development version at least pick a fixed point in development and use that. Otherwise you're coding to not one, but two moving targets: your own code PLUS the moving code in the library you depend on. Or, in this case, five. If your goal is to make development as chaotic and difficult as possible, you are on the right track. I am sorry, but what you describe is reality for most plug-in authors. Did plug-in developers develop for gtk-1.0 and gimp-1.0 a year ago? It's more of a social problem: do we *trust* the gtk development model to be stable most of the time? I did trust the gimp developers that they want working code as well, and it worked fine. If gtk+ is as chaotic as you think it is, it is evry bad and gimp shouldn't use the HEAD revision. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 04:40:41PM -0500, Kelly Martin [EMAIL PROTECTED] wrote: Why should we expect the GTK+ developers to keep their HEAD revision compilable at every moment? because that's what they do, what gimp does, what every other project does. if the head revision isn't compilable nobody can wotk with it. That is a completely unreasonable It's completely reasonable ;) expectation in the first place. If I were a GTK+ developer I would be asking that you NOT do what you're proposing because it creates I am not proposing anything. in the GIMP (which it probably is not), I would strongly urge picking a relatively stable snapshot of GTK+ current development (possibly, but not necessarily HEAD today) and use that. We might have to adjust later to any changes GTK+ makes to its HEAD after that snapshot, but at least we won't have to adjust to them willy-nilly as they make As sven has said, they made an API freeze recently. That means they are already pretty late in the development phase. I think it's totally unreasonable to expect non-compilability on a regular base. How often couldn't you compile gimp-1.1.2x? -- -==- | ==-- _ | ---==---(_)__ __ __ 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] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 11:18:58PM -0500, Kelly Martin [EMAIL PROTECTED] wrote: sufficiently large y. We bumped y as it became necessary. The HEAD revision was only occasionally required, and usually only for a short time until GTK+ released a new unstable version. so what? nobody requires the head revision all the time. please calm down! if you think about then you'd see that requiring the head revision as you interpret it makes no sense. I don't know what every project you've worked on. Probably because I didn't mention any. Why should I? Am I required to work on a project before I can tell which libraries they use? This is a completely INSANE model for any project of any size that wants to actually get anything done. It works fine, thank you. Do you have any _reasons_ to object, apart from not personally liking that model? (Of course, project leadership in most open-source projects is almost completely nonexistent You really escape me here. Project leadership is quite strong in most open-source projects IMHO. Gimp is the exception, and worked exceptionally well so far. To the contrary, many projects with strong leadership (glibc, gnome, even gcc althoguh I am not that sure about strong leadership ;) had a lot of problems. Look at all the BSD projects. reason why GIMP development has to be that way. It wasn't in 1.0, at least. I wasn't as involved in 1.2.) I don't think the pre-1.0 development model (if you could call it a model) is a goal to go for, actually. if the head revision isn't compilable nobody can wotk with it. Which is precisely why GIMP developers should not rely on it. GIMP developers are developing GIMP, not GTK+. GTK+ is gimp's toolkit, and breaking ties even more than already is the case is a bad thing for both projects. If an individual developer WANTS to work with the head revision, that's fine, but development should not REQUIRE it, why? should be wary of introducing dependencies on features not yet stabilized. why do you think they aren't? why do you not trust mitch? You should require the OLDEST version that suffices, not the newest. but that might well be the current head revision. your logic is this: we could write gimp using motif and it is stable. let's not move to gtk. progress can only be made by using newer gtk and esp. glib versions. what yo you expect from developers: develop a second glib because glib itself is not released yet, or just plain WAIT until it comes out so they cna finally make progress? usage of GTK+.) Application authors should NEVER assume that their users like to live on the cutting edge. Are you remotely aware of the fact that we are talking about development versions here? Obviously not. EVERY free software project progresses by using other people's work. Otherwise linux would still require gcc-2.5.2, gimp would sitll require motif and Xfree would still have no 3d. Most users do not. Most users use unstable alpha versions of gimp? Hello? upgrade the Linux systems that I'm paid to maintain when something breaks, and we should not force users to upgrade a nonbroken library unless the upgrade provides essential (or at least strongly desirable) functionality. Hello? Development version? totally unreasonable to expect non-compilability on a regular base. How often couldn't you compile gimp-1.1.2x? I broke 0.99.x and 1.1.x on several occasions. Too bad. Nobody would veer had found out if there weren't some savy users out there who, indeed, like to be on the cutting edge and used unstable development versions of gimp. -- -==- | ==-- _ | ---==---(_)__ __ __ 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 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 allow a variable number of arguments in pdb calls - if the code still works then it's already possible to call functions with a variable number of arguments. Each plug-in gets the actual number of arguments so it's a matter of checking it to see wether an extra argument exists. In order to support this, the file_load/save API has to be changed by extended, only, even ;) file is edited. The only thing that would have to change in the current plug-ins is the addition of this parameter that would be ignored. Even if we didn't have variable-number-of-args, the gimp itself knows how many agruments a plug-in takes and could act accordingly, i.e. by not passing in more argument than neccessary. 4) Feedback Any comments? I just looked at gif.c, it does this: if (nparams != 9) in the noninteractive case, which nobody cares about and leaves the interactive case untouched (i.e. it doesn't check). The same is true for pnm.c. I only expect problems with the non-optimal plug-in load/save data api or maybe something obvious that I miss, but it would be sensible to call plug-ins interactively with other arguments (or specially pre-populated agruments) than in the interactive case - the api already allows all this, I think. The noninteractive part is much more difficult (in that it requires sourcecode changes), but we could actually use the argument names (this is off-topic). This might sound ugly in C, but most scripting languages (e.g. perl) actually have functions which accept many arguments. The key is not to use them but default them sensibly: new Coro::Socket PeerHost = gimp.org, PeerPort = 80; and the many other arguments get sensible default values (like Multihomed = 1). In the long run, we need to use this approach anyway (think all the nice gimp functions with waaay to many arguments). -- -==- | ==-- _ | ---==---(_)__ __ __ 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 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 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
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
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
[Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Sorry that it took so long, Simon ;) Anyways, I had some conversation with two graphics designers about CMYK problems and the Gimp at the Systems, and I think it might be worthwhile to read the following sometimes true observations. Remember, they are hearsay ;) 1. colour matching for photos is a don't care. Ok, this is a blatant lie, however, exact colours are not that much of a concern for photos. Much more important are logo colours (most companies have pretty strict definitions of these). If a photo doesn't exactly match the screen colours (which screen colours, anyways) this is often not a reason to not use gimp. If a logo colour can't be reproduced, however, it keeps Gimp from being used. 2. Logo colours are not CMYK. Yupp. Logo colours might not be representable in CMYK at all (gold etc...). Even if, you often (but not always) want seperate planes for important colours. Most uses of spot colours want the concept of an indexed channel, i.e. a channel where each value represents a different palette colour. No bleeding with image contents. Gimp's channels can be used instead, which is not that perfect for all uses, but exists and at least photoshop doesn't offer a better solution ;) They also allow gradients of a single spot colour, which indexed channels wouldn't allow. Wether all this makes them easier or harder to use is something to explore. 3. You don't print from within the gimp. At least you don't print brochures from within the Gimp. You use gimp for artwork, often the logos, but you obviously don't set text using the Gimp. You instead import images into some layout program (quark xpress ;). I was told that the principal reason for bad quality of gimp images within quarkxpress is that quarkxpress imports gimp's rgb tiffs like garbage. I was told that loading the rgb data into photoshop, associating sRGB with it (changing _nothing_ else) improved the quality very much, making the results reproducable on printers. Without absolute colours, they look different. 4. Cheap CMYK vs. RGB makes a difference. Many programs also seem to have problems (looks like shit) with RGB data, not because it isn't associated with a colourspace, but because it's RGB. Cheaply (formula) converted CMYK data seems to help a lot here. That CMY has an additional K is of no concern - users don't sue this additional level of freedom, Things like trapping are handled by other programs or by very expensive photoshop plug-ins. 5. Logos are done by overlays. At least one method of using spot colours is to create them as seperate channels. Tiff/Eps are reportadly able to save additional channels in a way that a program can read them sensibly. The spot colour planes are then laid over the other graphics. For this to work a mask is necessary, since channels range from white (not transparent) to channel colour, at leats in quarkxpress. It seems that traditional masks are not what's called for - instead you want a path saved in the tiff/eps file (don't ask me wether that is possible). This clipping path is then used for the overlay - gimp can't create this kind of paths, nor can it save it. CONCLUSIONS - THE 60% WAY TO CMYK If one were so bold as to draw some conclusions, they would probably be very similar to these: 1. Enhance the tiff/eps save plug-ins to do cheap RGB-CMYK conversion. This would work around conversion problems in other programs. 2. Associate sRGB or any other colourspace with the saved data in tiff/eps. It doesn't matter wether it's true or not, just give programs something to depend on. 3. Educate users about channels and what they can be used for - on this Systems I was frequently confronted with users who were unhappy with the gimp because it didn't allow them to do things as easily as under photoshop. Often(!) I was able to get exactly the same results, with a much easier and faster sequence than the one that user used with Photoshop. This could be a start, to work around bugs in other programs. Also relatively cheap, unlike the following: 4. Find out wether saving paths as paths as opposed to masks is really required to do overlays in common layout programs. If yes: 4a. enhance the path tool to be able to work with generic paths (holes, multipart etc.). 4b. enhance the tiff/eps plug-ins to be able to save these paths together with channels. 4b. (optional) make tiff/eps save images together with their channels in the same file. 5. Implement indexed channels, or somethign else that makes handling spot colours easier. An easy way is to use one channel for each spot colour. Finished. I certainly
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
On Thu, Nov 29, 2001 at 03:17:51AM -0800, Jay Cox [EMAIL PROTECTED] wrote: pretty strict definitions of these). If a photo doesn't exactly match the screen colours (which screen colours, anyways) this is often not a reason to not use gimp. If a logo colour can't be reproduced, however, it keeps Gimp from being used. You should not create a logo requiring Logo Colours in a program such as photoshop or gimp. You will get superior results using a vector based application such as illustrator. That's what I was told, too (together with: many people do it with photoshop anyways ;) Sometimes you will need to match a logo captured in a photograph to a specific logo colour , but the first step would be to convert your photograph to CMYK. But how critical is that process? Do you think that my main point - cheap conversion to cmyk in the tiff/eps-plugin(s) - would really ease life and would enable gimp to enter prepress world (even if not at all perfect)? Logo Colours (aka spot colors or PMS colors) can already be used in gimp if you are only using one ink at a time. Just save your image as a grayscale tiff and place the image in quark using whatever ink you want. What about the clipping path, though? I'd guess you want to overlay these layers often. are not usualy working with a logo. Usually you are trying to match a color in a photograph that is not representable in the CMYK color space Any image that you would want indexed Logo Colours for would be better off handled in a vector based program such as illustrator. I was told that trapping can be done with expensive plug-ins for photoshop only, which would make sense, since trapping is (AFAICS, no idea actually) not really well-defined for photos, what users would buy such a trapping plug-in for photoshop? In my experience people don't use gimp (or photoshop) for logos (I mean for print work, of course the web is a whole different story) But gimp already works fine for the web, so that's a problem ;) I am not certain, but I think that the rgb-cmyk conversion is not done by quark, but by the postscript rip when you print your file. That would nicely explain why it looks like crap. setting the colour profile to sRGB in gimp is the wrong fix. There should be a setting on either quark or the rip that tells it what color profile to use for images that have no assigned profile. Unfortunately, users usually don't have control over the rip. I guess whatever rip is used just uses it's defaults for RGB. quark is a difefrent story - what if quark doesn't have such a setting? But I think that acse would be rather irelevant once we have CMYK in tiff. can't create this kind of paths, nor can it save it. The industry standard way of saving raster files that have spot channels in them is the DCS file format (A very close cousin of EPS). I knew eps couldn't do it (directly ;). Ok, prepare for: REVISED CONCLUSIONS (ordered my importance). 1. implement CMYK saving in tiff and eps. 2. enhance tiff(?) eps to save all channels paths in whatever format is actually understood (DCS for eps). one path must be marked as clipping path (e.g. by name Clipping Path or by some parasite (gimp-clippath on the image containing the ascii form of the path tattoo or somesuch). 3. (optional, but important) finally enhance the paths to be multipart, contain holes etc. simon? smoon? ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 07:33:28PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: have done it before. I can see at least one more advantages of using an external file: The tips don't stay in memory all the time. So we should probably go for it. (just a sidenote: if tips were compiled-in and large enough for this to be relevant, they would still not stay in memory all the time. guess that the parser would take up more memory ;). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: GIMP Tip of the Day messages
On Sun, Oct 07, 2001 at 02:46:35PM +0200, Daniel Egger [EMAIL PROTECTED] wrote: really??? I've heard there are Perl hacks as well. :) There are hacks for a lot of other languages/environments ;) The shortcoming of gettetx lies not int he parsing and input format... which would be easy, nice and probably very small. Yes, but not very versatile... Why? It contains the tips and a minimum amoutn of clutter. If you equate evrsatile == xml because everybody claims to support it I disagree completely. Also agreed, the disadvantage with the headers is that the messages are static after compilation while it's quite easy to extend XML and test it without having to recompile the application. Yeah, but a) nobody does that (right)? and b) this could be said for ltos of other things. Just as SGML was so feature-rich that nobody knew or used all its features we might not need to make everything run-time-configurable. Compare this to the trend of adding 10k of module loading and interfacing code to about each and every program nowadays where it doesn't make sense (pluggable protocol modules for lftp? get real... ;) The problem with SGML is that it's too complex to grok completely and that's why a large amount of people simply ignored it; XML is a subset That's a story I never heard of before. The reson SGML was not used is because it was very powerful and complex to implement. For humans it is easy to grok. You are comparing sgml with xml-applications. I could just claim that most sgml-applications are much easier to grok for humans than xml namespaces or schemas. of SGML which was defined with ease-of-use in mind and that makes it Where do you get the idea that XML was done for ease-of-use? And why do you apply ease-of-use to humans, while XML was designed to be easy-to-use in applications (as opposed to SGML). one of the goals of xml is: XML documents should be human-legible and reasonably clear. this doesn't sound too encouraging, no? yes, it was a goal to keep xml human, but this is a minor goal, others (ease-of-use for machines!) were more important. Anyways, it's getting off-topic and I'll keep it there ;) Exactly. If we decide to use XML, we should do so consistently. Also we can neglect the overhead in this case; in fact I believe that using GMarkup is bloatfree or even better if we throw out the configparser for instance. Fully agreed. Just somebody needed to code it ;) Ha, not me, not me, I am a lazy lamer ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: GIMP Tip of the Day messages
On Mon, Oct 08, 2001 at 03:39:53AM +0200, Christian Rose [EMAIL PROTECTED] wrote: Native support for UTF-8 is uncommon and of course that is bad and Sorry? my mailer supports it (mutt) my editor supports it (vim), my terminal supports it (xterm), my irc-client supports it (epic), my browser(s) suipport it (lynx, netscape, mozilla), my os supports it on the console (linux)... utf-8 support is more common than supprot for most other charsets, actually. Editors aside, simply looking at and otherwise using console text tools on UTF-8 files with non-ASCII content, usually has little if any support. The same is true for anythign except ascii. Hint: you cannot represrnt the majority of languages with ascii. (and I was told emacs can do utf-8. at least people found a way to decode my mails properly in emacs). Maybe it's just that emacs can't natively edit utf-8 text, but it should be possible to just convert it to some native charset. every unix comes with iconv, and most do support utf-8 for example. I'm sure you'll find out many other surprises when you check what text tools in any major GNU/Linux distribution actually fully supports UTF-8, I'd say the majority does. Sure the tools need to get updated in the end, but it's a very slow process that has already taken years with little happening and surely many years remain to come I realyl think you need a reality check. have to use UTF-8 is a big practical problem for translators. Note that s/big/little/ every editor should eb able to pipe through some external program (iconv -f utf-8 -t koi8-r for russian for example) on loading/saving. And I am quite sure translators for non-ascii languages already know how to cope with charset problems - they needed to. That still won't solve the problems: (agreed to all of them - i wa spurely concerned about utf-8 ;) While I do agree with Marc that XML is not the all-purpose solution I really think it's going to help in the case of localisation by the consistent use of UTF-8 and other concepts like includeable files and overrideable tags. XML and UTF-8 are two completely orthogonal concepts - xml is represented in unicode and can be written in almost any encoding (ascii, viscii, whatever). I don't see any problem having multiple different(!) files with different encodings, pleasing whatever a local translator likes. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: GIMP Tip of the Day messages
On Mon, Oct 08, 2001 at 05:00:27AM +0200, Christian Rose [EMAIL PROTECTED] wrote: My mailer doesn't (pine) pine doesn't even parse rfc822 addresses (like mine) - let's face it, pine is the worst mailer around with regards to features, standards compliance etc. Everybody is free to use it, but citing pine as an example of a modern, average program that doesn't support utf-8 is just unrealistic ;) (As a matter of fact, most people use netscape, outlook etc.. which work fine, probably kmailxxxtool does as well. All these programs are maintained and at least try to comply with standards). my editor doesn't (Emacs) It can be taught to. I worked with vim-5.6 and utf-8 for a long time, and vim does have no native support. my terminal doesn't (gnome-terminal) it still doesn't need to support utf-8 to display unicode - at least the subset you are interested in. gtk will soon support utf-8 (put differently: the next release will). my irc client doesn't (xchat), and lots of ordinary console text tools don't. I have no idea what console text tools are meant to be. Most text-utils trivially support utf-8 (they basically don't care, and modern systems often offer a utf-8 locale (glibc does), which makes lots of x programs and text utils act wonderfully! (i can even enter utf-8 in rxvt ;)). I think the main problm is that people aren't aware of all this. utf-8 support is more common than supprot for most other charsets, actually. Hardly compared to iso-8859-1, which I was referring to. Again, by far the majority of languages cnanot be represented in iso-8859-1. Heck, even most of europa can't, strictly speaking. No it's not. Tell me any console text tool that *doesn't* handle iso-8859-1 correctly by default nowadays. I still don't know, but neither bash nor epic nor ircii do that until configured to do so. And pinning down on iso-8859-1 is, again, neglecting most of the world. Hint: you cannot represrnt the majority of languages with ascii. I'm very well aware of that fact, thank you. I don't think so ;) I know that, but if I'm understanding it correctly, you are suggesting that iconv be used manually before and after every translation update as extra steps? Are you suggesting that the holy emacs is incapable of such a primitive thing itself? gnus already converts utf-8 to local charsets (and back) fine. and utf-8 support is high priority I would think. Manual steps that are completely unnecessary since intltool does this automatically. If your editor forces you to do that manually you should exchange it for something that works. But anyways, yes, the single-file-idea is a bad one. I'm sure you'll find out many other surprises when you check what text tools in any major GNU/Linux distribution actually fully supports UTF-8, I'd say the majority does. In my experience, that's far from true. I use them every day - are you sure you really tried? Nevertheless, insulting me doesn't make your opinion more valid. Nobody is insulting you. But if you think so, I will try to be more careful in the future. Why would this manually piping be favorable over using intltool that already does this automatically, requires no additional manual steps in I don't know - I didn't offer an answre to this question. It would certainly make it possible to use utf-8 as the main format for files, though. I'm a translator for a non-ascii language, Make it non-latin1 then. Most of europe has a slight compatibility problem now, since iso-8859-15 will be very common very soon now. And so we do in fact agree... On these points: certainly ;) And even without any insult, believe me! -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Thoughts on CMYK, and getting it without implementing it.
On Fri, Nov 30, 2001 at 03:38:10AM -0800, Jay Cox [EMAIL PROTECTED] wrote: [cmyk comversion] Where I work it is a very critical process. Any tips here? If gimp would support CMYK on-screen, how would the users work be different? Do users actually adjust CMYK themselves or do they just draw using predefined CMYK values? I mean, is the principal problem the missing CMYK colours in RGB, or is the principal problem the looks the same on-screen as on print. The latter could be solved largely outside the gimp (tiff plug-in), the former obviously not. with less compulsive designers it is much less critical. This feature would not get gimp into prepress houses, but might help out the casual designer who is preparing artwork for a short print run. Would it be worth it? ;) The most common/best way to do trapping that I have seen is to trap after the rip using a program like creo/scitex full auto frame (which isn't quite as auto as the name implies:). Obviously, as only then you have the full image. Hey, the new postscript can do in-rip trapping ;- (adobe claims yet another revolution ;) even if it doesn't have a setting I dont think we should modify the default behaviour of gimp to work around a bug in quark :) well, it depends on wetehr you call this a bug or not. if quark lacks the functionality (if!) to bind profiles to images it's not a bug ;) 3. (optional, but important) finally enhance the paths to be multipart, contain holes etc. simon? smoon? ;) How is #3 optional? :) Well... it's the most difficult part. 1 and 2 could probably be done even in gimp-1.2, #3 is a problem. Also, if you don't have clipping paths you still can print many photos ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] XCF support added to ImageMagick
On Tue, Dec 04, 2001 at 02:06:56PM +0100, René [EMAIL PROTECTED] wrote: There will be a new version of xcf eventually - so what? I'll use imagemagick today, and if no-one finds it worth the time implementing support for the new(er) version(s) I'm no worse off than if it hadn't been ImageMagick can read xcf files using delegates for quite some time, btw. Of course, gimp must be installed for this to work. gimp should be able to save .miff files, too, although I am not sure how tested that is. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: your so called optimizations and why we don't like them
On Tue, Dec 04, 2001 at 02:17:06PM +0100, [EMAIL PROTECTED] wrote: agains 0 for example than against negativeness and this part also plays a role when returning 0 or non-null instead of a negative value. Sorry, but before you continue with all this, ehrm, wrongness, would you please first check what you are talking about? Can you give us a single example of such a cpu? No cpu linux runs on has this property, btw. The reason nobody wants to talk reasonable with you is that most of what you claim is simply that: wrong. People cannot trust what you say when they cna trivialy verify most of you claims as wrong. If you would only give the points that _are_ true, then people will be much more open in discussing optimizations. For example if you shift a signed value it has to generate code to take care of the sign and similar with some logic operations. Again, not on any cpu that linux runs on. Trust me, if I see the assembly I can tell you which one is faster and by which magnitude. How can we trust you if most of the easily-verifiable claims of yourself are simply untrue? *please* this is not a with-hunt. *please* re-adjust your attitude. when so many people tell you that you are wrong you could at least check wether tzhis is true. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] XCF support added to ImageMagick
On Tue, Dec 04, 2001 at 11:28:07AM -0500, Leonard Rosenthol [EMAIL PROTECTED] wrote: ImageMagick can read xcf files using delegates for quite some time, btw. Of course, gimp must be installed for this to work. Right, you could have always done this - but it would have meant having GIMP and temp files. True, and the filter I wrote for this was written before gimp had miff-support. saving of .miff is better than GIMP's reading of them. It can only handle about 50% of features in MIFF. Back when I implemented it, it implemented the common subset of miff and gimp. If the format has changed so much that it is a problem, I could improve the miff saver. (this is unrelated to the xcf discussion, btw). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Current work
On Wed, Dec 05, 2001 at 12:07:56AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: Why not directly read XML in a plugin and apply some inline defined styles to it? Just an idea... it might be a good idea to keep the help pages in a format that can be read with standard browsers ?! This could be achieved by filtering xml = html (which is trivial) on install time. The installed help pages would not require special rutime support and would be standard (x)html. this leaves all options open for later. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] EXIF and Gimp parasites (was: Current work)
On Tue, Dec 04, 2001 at 10:36:50PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: The possibility to save the data indepently of the image format in a separate file a good idea but doesn't speak against using parasites for metadata. In fact, it's trivial to implement another Load/Save-Plug-In that implements just this. It could also trivially define a dialog to edit this parasite-metadata. The problem is entirely mapping metadata to parasites, just as it would be a problem mapping it to a non-standard API. That's what should discussed. we already have a rudimentary parasite editor. If you talk about the perl version - it was never finished because obviously nobody uses it for anything else than debugging. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Current work
On Wed, Dec 05, 2001 at 11:44:02AM +0100, Michael Natterer [EMAIL PROTECTED] wrote: This could be achieved by filtering xml = html (which is trivial) on install time. That's IMHO a very good idea. Simply XSLT the thing on install and never fiddle with HTML before... If help with XSLT is wanted, btw, I'd be happy to write some stylesheets (that would be part of my personal starting to work in gimp again campaign ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] EXIF information in JPEG files
On Wed, Feb 06, 2002 at 02:11:28PM +0100, Dave Neary [EMAIL PROTECTED] wrote: Parasite naming is non-standard. Anyone can create a parasite with any name they want. Untrue. Names beginning with gimp- are well-defined as belonging to the core. The gimp itself must, at one point, know how to deal with these. The core also is: the aim of having a metadata editor at some stage, 50 or 60 pieces of metadata with (possibly) non-standard naming is complicated. There is no such thing as non-standard naming in this case. exif doesn't provide a standard name, so you need to make one up. Wether oyu make up one or 50 doesn't really matter, as long as it's documented. parasites if we were guaranteed a consistent approach throughout the gimp, but parasites don't give that guarantee by definition almost. Why? What are the problems? The obvious way to maintain a consistency wrt the metadata is to define it in one place, maintain that list in one place, and have it parsed into a usable structure when needed. I think this is exatcly what parasites provide. You say that any piece of metadata can easily be accessed by name. The problem is going to be: What name? I think keeping stuff in one place offers consistency. Well, the everything-in-a-big-blob-approach doesn't help naming at all. At one point you simply have to make up names to access the exif information. The parasites provide a namespace for this. Inventing yet-another-metadata-in-metadata-abstraction doesn't buy clarity. (with a description) to the list. devel-docs/parasites.txt is something approaching that. But that makes maintenance pretty difficult, compared to having the code document itself (one metadata structure with typed fields, and a couple of parsing routines). I think it's much easier to just look at the documentation rather than to run through header files until I can find what I need, hopefully with a sparse one-line comment, even. parasites. Having one metadata structure provides that one place. But parasites _is_ one metadata structure. I don't see why nesting etadata structures inside each other is a good thing - to me it only complicates things. parasites were created for metadata. If they don't work well enough for that parasites should be improved, rather than becoming a legacy layer. the TIFF plug-in, the PNG developer knows nothing about it - if I as a lazy developer didn't add it to the list of supported metadata he wouldn't know it existed. And let's say I as the PNG developer want to use the same data, but I call it a slightly different name - now we have two parasites which do the same thing. Your approach suffers exactly the same problem, btw. Those kind of problems are eliminated by definition if all the metadata's defined in one place. And the most natural place for this is parasites, which exist only to hold metadata. If their definition isn't clear enough then this is the problem to solve. Adding yet another layer makes the situation worse, not better ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] EXIF information in JPEG files
On Wed, Feb 06, 2002 at 03:41:17PM +0100, Lutz Müller [EMAIL PROTECTED] wrote: It would be _really_ easy if you used the tag names for those parasites, i.e. gimp-exif-FillOrder or gimp-exif-SpectralSensitivity. while i am not strictly opposed, these names are very ugly. more important, though, non-exif-specific metadata (like the above), would gain a lot by being in a common format. exif is not the only metadata format around and it would be nice to have the gimp metadata an abstraction. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] EXIF information in JPEG files
On Thu, Feb 07, 2002 at 04:09:01PM +0100, Dave Neary [EMAIL PROTECTED] wrote: This is untrue (or at least, true only by convention). There's a solid argument (your mail is horribly mis-formatted and very hard to read, btw) that all metadata is plug-in independant, and therefore belongs in the gimp- Why is metadata plug-in independent? group. But there's nothing that forces people to honour any parasite naming Yes there is, it's called rules and conventions. The gimp is not about bondage and discipline. convention. I could write a plug-in that creates a parasite with a name not starting with gimp- and uise it in the core, or with the name gimp- and use it only in one plug-in. You could. You could also send the gimp process a kill signal at anytime. That doesn't make it correct, or right to do. one or 50 doesn't really matter, as long as it's documented. That's the major part of the problem. If someone adds metadata that's not documented, that's a problem. Yes. It's a problem because there's no one place that someone can go and say that they have the definitivelist of parasites. Sure, the documentation. That's fine if there are only a few, but if there are many, tracking them becomes a chore. And more it leads to the possibility of inconsistency. Another abstraction layer, of course, doesn't help getting rid of inconsistency. Yes, it does. We would have one parasite, named something original like gimp-image-metadata, and in one header file somewhere we would have the definition of the gimp-image-metadata structure, and the prototypes of the parsing functions.If someone added an extra bit of metadata and forgot to document it in the docs, well it's there in the code in the one place where all the fields supported in the metadata are - one place, definitive. So what does this buy us, apart from anothe rlevel of indiraction, to the current approach which also does all this? The parasites provide a namespace for this. Inventing yet-another-metadata-in-metadata-abstraction doesn't buy clarity. Perhaps not, but it buys consistency. You repeat this again and again. But people fail to see this. That's fine, when the documentation is accurate - if it lags behind anyone who thinks it doesn't is living in a dreaml world) it becomes best redundant and at worst misleading. Adding yet another place where this has to be documented does not, in my eyes, improve the situation. No, because the PNG developer has the definitive list of parasitres in the image metadata definition. If he's adding a new bit of metadata he's adding it there. And in that case, the duplication should be obvious. the definitive list and adding new bit of metadata contradict each other, at least in my mind. If someone could convince me that there were a way to get a list of all the parasites in use in the gimp (core and plug-ins) using the current structure of things, then I'd probably go along. I just have this use grep ;) vision of having a gimp-image-metadata-author in one plug-in, and gimp-metadata-author in another, and gimp-image-author in another, If you mean that this should not happen, I agree. But how would the other approach help this? One author could add a author field and another an image-author field to the structure. Again, another level of abstraction doesn't help at all. Either one avoids these bugs, or not. and so on. Possibly not for something as obvious as that, but you get my point. Yes, but instead you should gice points on why another metadata layer would solve the existing problems. IMnsHO doing the same thing in a slightly different way only increases the places where problems occur. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] EXIF information in JPEG files
On Thu, Feb 07, 2002 at 02:45:03PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote: not be saved in a new file (unless it is reconstructed by the JPEG/EXIF plug-in) but it would be available after the image has been loaded. If it is valid after the image is modified, yes. Otherwise I think it should not be attached at all. appropriate for each file format to/from UTF-8 if necessary. Oh yes, oh yes! ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Wanted: pixel warrior drones
On Mon, Mar 04, 2002 at 01:11:02PM -0500, Carol Spears [EMAIL PROTECTED] wrote: do you mean something like this: http://www.goof.com/pcg/marc/gimp.html but i think the on demand images on this page were not rendered with there are no on-demand images on that page in the dynamic-html sense. I create the buttons at make dist time, e.g. when my local html pages get published to goof.com gimp. the page is very very informative, yet i was not able to access it with lynx. hey, lynx should work great with my pages ;) at least, as much as lynx can be called great. with a graphical browser, the images are very cool though. all my friends say: well, the idea is nice, but the images are butt-ugly ;) between these images and the usual ones found on web pages. what would be the advantage of this sort of rendering? in other projects of mine I *do* plan to dynamically create buttons (of course heavily cached). If you look at why traditional web design is so expensive the reason (partly!) seems to be the major time effort: redrawing buttons (and other elements) again and again. actions don't help that much (many artists don't know how to use it). Of course, writing perl scripts won't help in that case, too ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Wanted: pixel warrior drones
On Mon, Mar 04, 2002 at 01:55:37PM -0500, Tom Rathborne [EMAIL PROTECTED] wrote: but you may have to wait for Gimp-2.0 to lose the dependence on X and Gtk+. Hopefully Gimp-1.3 will make more functions available via the PDB, but it's already pretty complete. the big problem is indeed fonts (and that's taken care of). the only other problem is long-term-stability, but for real daemonized usage some restarting is inevitable (after all, what's the DBI-ping method for). As Net-Fu shows/solves, the biggest problem is practical availability (caring for gimp restarts, resync, locking), not so much lack of features, as everything is already there in gimp-1.2. So... who wants to invest some time into her existing framework to make it usable for other people (I am quite sure many people have solved these problems for themselves already...) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] action files in GIMP?
On Fri, Apr 19, 2002 at 02:18:41PM +0200, Branko Collin [EMAIL PROTECTED] wrote: For somebody who has never programmed in his/her life, a logical language is probably just as easy, if not easier. How many problems The scheme dialect used in gimp is neither a logical language, nor a real (strict) functional language, nor type-safe It does, however, run under windows, unlike gimp-perl, which should be very easy to port without Gtk. Porting Gtk should be easy too, if the destination is named cygwin. Unfortunately, the developers who do the windows port don't use the same config mechanisms as under unix/cygwin, and Gtk is proven to be hard to port to that environment. So an automatic translation to script-fu would be the most portable choice, since users don't care for the implementation. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] action files in GIMP?
On Fri, Apr 19, 2002 at 10:34:19PM +0300, Tor Lillqvist [EMAIL PROTECTED] wrote: and Gtk is proven to be hard to port to that environment. ... but I still fear that porting gimp-perl might be quite a task. Why? I apart from trivial changes (gimp-perl has to parse the output of gimptool -n --install-admin-bin because gimptool doesn't have an option to output the pluginpath and can't be edited under windows), it compiled out of the box five minutes ago under windows 2000 using cygwin and the binaries from www.gimp.org/win32 (which, as I read it, are not really compatible with my environment anyways). I think the remaining problems are highly trivial (e.g. possible reliance on / instead of \, which mostly isn't a problem under windows anyways, socket functions etc.) It's just that this has to do somebody who knows windows better then me (I lack the time compiler to compile gimp c for windows just to test it). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Script-Fu/Scheme---what is #f
On Thu, Sep 05, 2002 at 11:40:14AM -0400, Roland Roberts [EMAIL PROTECTED] wrote: I haven't played with ImageMagick, so I'm not sure how good a job it does when rescaling. I've been using the GIMP because it's downsampled images look pretty good, at least as compared to using the When using the right settings, ImageMagick usually does a much higher quality job, at a very much higher memory and cpu cost ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] how to make Gimp::Perl script work remotely?
On Thu, Sep 26, 2002 at 02:56:06PM +, forest monk [EMAIL PROTECTED] wrote: through networking. Say, If i start a gimp perl server on a server machine, what should i do to be able to execute the script on a remote machine?I searched online resources and found that on server side, i need to setenv GIMP_HOST to [auth@][tcp/]hostname[:port] for tcp support, but what should i do on client side? do i need to install some client tools on the box or should i modify my script to include gimp::net module? Just the same, i.e. use sth. like this: [EMAIL PROTECTED] and start the server, and then do the same on the client and start the perl script. You shouldn't need to modify your script, although modifying it can make some things easier (program structure can be much freeer, as you can decide when to conenct and disconnect). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] how to make Gimp::Perl script work remotely?
On Fri, Sep 27, 2002 at 02:01:57AM +, forest monk [EMAIL PROTECTED] wrote: Thanks a lot for your reply. Tried what you suggested but still could not get it to work. Got some error message like Cannot locate Gimp.pm at @INC .. this actually looks as if gimp-perl wasn't installed at all. You have to have gimp-perl on both machines, of course. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] how to make Gimp::Perl script work remotely?
On Sat, Sep 28, 2002 at 01:20:20AM +, forest monk [EMAIL PROTECTED] wrote: Thanks again for your reply. I do appreciate it. Not sure about one thing though: Do I only need the perl and gimp-perl module installed on my client box and no more software (Gtk+, GIMP) required? In theory only gimp-perl (you can copy your perl lib dir if you are sure what you are doing). Although, while in theory it should be possible to build gimp-perl without gimp, the Makefiles don't really expect that and won't work. You might try (as a hack, but it might work): perl Makefile.PL on the server machine, then copy the gimp-perl directory to the client make -i -k install. However, it's cleanest if you just install gimp + gimp-perl everywhere. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Perl Server
On Fri, Oct 04, 2002 at 04:32:18PM -0400, Bowman, Terry [EMAIL PROTECTED] wrote: ). It will run as a cron job if I manually start perl server from gimp. I Try to run it with -v, it will most probably tell you that no X-Server was found. You need either a valid DISPLAY under cron (e.g. using Xvfb), or, more realistically, run the perl-server permanently and let the script connect to it. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] How to build a distribution
On Wed, Oct 09, 2002 at 02:51:53PM +0200, Vegard Vesterheim [EMAIL PROTECTED] wrote: no separate gimp-perl package. At the moment it looks a lot as if gimp-1.4 will not have gimp-perl support. separate package from gimp itself, and that the packaging is using the ordinary Perl mechanism (Makefile.PL, etc). AFAIK, PerlMagick is a separate package from ImageMagick, so why should Gimp be any different? The situation is exactly the same with ImageMagick: ImageMagick comes with the perl module, and also builds it in much the same way as gimp does. For some magic reason, the culture clash seems not to be a problem for the ImageMagick developer(s). I guess if automake wouldn't be so limited (there has been development for perl support, but AFAICR it was decided that Makefile.PL works better anyway, and is more portable) the world would be a better place. OTOH, portability isn't much of a problem in the case of gimp, as gimp just doesn't port to a lot of platforms, and I think it might be possible to make gimp-perl completely integrated into gimp's automake system, just as programs embedding perl usually try their own system. I wouldn't want to handle the portability problems, but, frankly, it would need to work on linux, *bsd and (in the future) windows, nobody cares about irix where it's simply impossible to cleanly compile perl modules in many cases. The only drawback would be more difefrences between the CPAN vesion and the gimps version. If anybody would want to try, I'll surely help with how to get the necessary info out of perl. Lots of work, but doable. In any case, before shipping a defective gimp-perl, I'd indeed vote for complete removal. The situation is not as bad as a few years ago, where you a) needed a very specific gimp-perl version for a very specific gimp version (quickly changing 1.1 releases) b) it's part of most distributions, and they know how to build it And as for gimp-1.4: I'd like very much to make gimp-perl work with gimp-1.4, but right now I am quite dead. Very, very dead. Drowned in work. You get the idea. I hope this changes soon, but that soon might still be 4-5 months away. My apologies for playing dead man for such a long time... I _really_ work hard to change this ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Dreamworks, Shrek, and the need for 16 Bit
Just FYI (I have no specific goal with this mail ;): I met some guy from Dreamworks (Shrek) at the LWE in Frankfurt, and he told me that their whole rendering infrastructure is 8 bit, including intermediate results (so the whole of Shrek was done at 8 bits, with a later dynamic adjustment of the results into the necessary range). He also told me that they want to go to 16bits, for 8 bits is only ok for exclusively-rendered movies, that 8 bit intermediate results do hurt a lot, and that they do use gimp, for some unnamed adjustments and especially creating textures, where gimp works extremely well ;) And finally he told me that the need for 16 bit and floating point is there in many but not most cases, so one _can_ get along without it, at leats for rendered scenes. -- -==- | ==-- _ | ---==---(_)__ __ __ 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: Floats (was Re: [Gimp-developer] Dreamworks, etc.)
On Sat, Nov 02, 2002 at 08:16:37AM +, Nick Lamb [EMAIL PROTECTED] wrote: This probably ought to be on our horizon too. Modern FPUs are very fast and RAM gets ever cheaper. And caches get slower... and RAM is _slow_. I don't say not to also support float, I just wanted to point out that performance is very much dependent on cache optimizations, as every fortran programmer knows ;) the 50% saving on storage) for 16-bit integers vs 32-bit float? We can't actually /display/ either of these things on conventional hardware so there's no difference there. I think that we very well can display 16 bits or higher, after all, we can have 16 bit linear and output 8 bit gamma-corrected. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] The Occasional Bug List
On Thu, Nov 07, 2002 at 11:46:14AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: However 280 open bugs (excluding enhancement requests) are still way Could somebody with sufficient priviledges allow me to edit bug reports again (account [EMAIL PROTECTED])? ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Gimp perl Help
On Fri, Nov 08, 2002 at 05:48:35PM +, Hakeem Ogunleye [EMAIL PROTECTED] wrote:
scripts run when i execute it form the command line but when i run it from
a browser it doesn't work. the error_log shows:
Have you tried ./scriptname -v? that will most likely tell you that gimp
can't open the display.
Make sure your script has access to a valid DISPLAY (e.g. set
$ENV{DISPLAY} ina BEGIN block), e.g. by running an Xserver (Xvfb works
nicely).
I have searched the newsgroups and found that this problem is quite common
but no one has provided a solution.
Maybe search any gimp mailinglist archives, write a FAQ and thus help
others who will, no doubt, have this problem in the future ;-
--
-==- |
==-- _ |
---==---(_)__ __ __ 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] Script-Fu - Batch Mode Problem
On Thu, Dec 19, 2002 at 11:29:08PM -, [EMAIL PROTECTED] wrote: I could get a good image, but not to the satisfaction of the customer. It appeared to be the way in which imagemagick scales the image as opposed to Do you have an example image? Really, either you hit a bug in imagemagick itself, or you are simply doing sth. wrong. ImageMagick can use exactly the same algorithm as gimp. gimp. Gimp seems to handle it better. I would think it would be pretty much a wash but based on what i have coded up so farit's not the case. At least not for the client who is really really picky about the pixelation. What, exactly, were you doing (state the command line) with imagemagick? -- -==- | ==-- _ | ---==---(_)__ __ __ 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] perl-fu : cannot save image
On Mon, Feb 24, 2003 at 06:38:42PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: I'd say the bug is in your script. But then you could argue that the bug is in gimp-perl since it's syntax defers from the one that is documented :-( I would prefer if people who could know it better would stop claiming such bullshit. The perl-syntax is well-documented, and even if you insist on using the rather idiotic PDB-syntax, it does work. Also, it should be clear even to you that some languages look diferent to others. I remember that a PDB call uses different syntax in C than in script-fu, for example. Yes, both might be documented, and the same is true for the perl interface. Since you certainly _are_ aware of all that, what's your point? Maybe I should add dummy array-length arguments to all calls involving arrays, because other languages can't handle that? file_png_save(RUN_NONINTERACTIVE, $img, $activelayer, $fname, $fname, 0, 9, 0, 0, 0, 0, 0); in gimp-perl, you need to omit the image if the drawable ($activelayer) is already specified. Actually, you don't. Actually, the script works fine on a standard debian installation (gimp-1.2 1.2.3-2, with the debian gimp-pelr etc..), WHEN I add sleeps at the right place. What's buggy is, again, script-fu, which returns long before the script has run. And the script doesn't work unless you create another image, because it doesn't like image ids of zero. The only solution is to avoid script-fu whereever possible. It has been horribly buggy since many years (I don't remember it being working ever). But obviously it's much more fun to blame gimp-perl for bugs in script-fu, or claim thats cript-fu was never written to be used as a gimp-plug-in, or other fun stuff. Boys, I am really fed up with that never-ending and mindless perl-bashing. If you can't try to help people without shoveling mistakes and bugs around, then please, keep your mouth shut. Or at leats use your brain once in a while. Blaming perl is *not* the solution. Blaming script-fu *is* right. Fixing script-fu *is* the solution. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] perl-fu : cannot save image
On Wed, Feb 26, 2003 at 07:53:31PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: I would prefer if people who could know it better would stop claiming such bullshit. The perl-syntax is well-documented, and even if you insist on using the rather idiotic PDB-syntax, it does work. sorry, I heard that it wouldn't work and I remembered the PDB explorer to document the rather idiotic PDB-syntax. Well, sure, but even if you believed that there was no reason to write what you wrote. So what are you sorry for? You do that in about every mail that has something to do with perl, in case you didn't realize it. The only solution is to avoid script-fu whereever possible. It has been horribly buggy since many years (I don't remember it being working ever). I don't remember to have seen a bug-report about this. I think it gets reported here or on gimp-user every few months since at least 2000. You probably ignored it because there is often perl code in it, and it's easy to dismiss it as yet another perl problem. It's basically become a FAQ even. meantime. I'm not sure however if we will ever manage to fix all Script-Fu problems since it has indeed some rather fundamental flaws. That's true, and I can fully understand that. What I cannot understand is why you reflect these problems on perl again and again. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] perl-fu : cannot save image
On Wed, Feb 26, 2003 at 10:24:13PM +0100, Valter Mazzola [EMAIL PROTECTED] wrote: i'm using mandrake 9.0 and gimp 1.2.3 , removed mail() in exit, but the saved logo is totally different than the gimp do interactively. Try to call flatten on the resulting image before saving ($image-flatten). If that doesn't help, then add a sleep 3 or so after the call to script-fu and keep your fingers crossed. If that doesn't help either you might look at scm2perl and convert the scheme plug-in to perl (followed by a lot of small adjustments, as script-fu scripts are often rather unclean, due to the lakc of type-safeness of the language). ok but io want to create logos using existing script-fu logo script? it's possible With a lot of hacks, it's usually possible. But it often depends on the particular script. It also sometimes helps to open a new image+drawable before calling script-fu, as some scripts seem to have problems with image or drawable ids of zero. Equally often it helps to not have any windows open, as some scripts only work _if_ they open the very first image and/or drawable. Most of these _should_ problems be fixed in 1.2.3, but some probably were overlooked, and debugging these scripts is no fun. I want to do serious scripting work with gimp, similar to cool text.com, can you help me to decide in what direction i should go ? Maybe ask whoever does cooltext.com, they certainly had either similar problems or do it difefrently (e.g. with the script-fu server, however, don'T use it unless you have properly firewalled it). I have not obtained deterministic results till now. That's, indeed, what most people find out quickly when they get in contact with script-fu. Script-fu, perl-fu , interactions between them, outdated documentations ??? I am sorry, you must be fairly confused by now ;) Actually, it's because script-fu doesn't really behave like any other gimp plug-in. The fact that nobody regularly calls script-fu in normal work (there are few, if any, generic script-fu scripts, so there is rarely need to call them from other plug-ins) obviously made script-fu very low priority over the years. The only people who do call script-fu from a plug-in are mostly people who write logo-generators (like you do), and they often use perl. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: perl-fu : cannot save image
On Fri, Feb 28, 2003 at 01:06:41AM -0500, Carol Spears [EMAIL PROTECTED] wrote: On 2003-02-28 at 0102.48 +0100, Marc A. Lehmann typed this: I really wonder what is going on here, but there is a great deal of confusion and misinformation going on... i miss the perl plug-ins in gimp-1.3. Well, the whole disucssion was about gimp-1.2, and it certainly works for that version (the current release, btw). gimp-perl indeed does not work with the cvs gimp. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] gimp-perl moved into its own CVS module
On Fri, Feb 28, 2003 at 06:07:22PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: Hi, pcg( Marc)goof(A.).(Lehmann )com writes: (2) There are a couple of severe problems with the build that have I didn't know this (but I don't use the bugtracker, since despite a lot of tries I never got an account there, so it's rather useless for me). it seems we suffer from the same problem: I've told you about these problems several times and it seems you forgot about it. It seems this is wrong and only you forgot about it. I went through all bug reports you ever told me about and fixed, or at leats tried to fix them in good faith. I remember having given you feedback on them, too, but maybe in the last year or so some mails slipped through, I don't know. forget that there was a problem calling Script-Fu from anything but Script-Fu. Well, you keep forgetting it, don't you? In any case, arguing about open bug reports (that are long fixed) isn't going to get us anyhwere. Perhaps us two just have too many things to care about... Perhaps. But I don't go out in the public and keep claiming wrong things when I _know_ that I _do not_ know. http://bugzilla.gnome.org/show_bug.cgi?id=20052 This bug report is rather outdated and supposedly fixed since MANY years. http://bugzilla.gnome.org/show_bug.cgi?id=35694 Same issue here. http://bugzilla.gnome.org/show_bug.cgi?id=79751 Oops, this is certainly not something you told me about ever. http://bugzilla.gnome.org/show_bug.cgi?id=81791 This also is rather valid - I missed the change from overwriting prefix to destdir. http://bugzilla.gnome.org/show_bug.cgi?id=104726 Well, this is another case of broken compilation environment (gcc doesn't support the native asm syntax and compiler switches). In any case, the two bugs are really easy to fix - I don't think you ever told me about those. Yes, it's not at all your duty to tell me about these - I am not at all arguing about that, or wanting you to invest even more time and work. My problem is that you are investing too much time with misinformation - something that is relatively easy to avoid, especially since I do tell you about this regularly (oh sorry, for you it's ranting - no wonder you keep ignoring it). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] to rower@MovieEditor.com (unrachable e-mail address)
Sorry for this off-topic posting, but Robin Rowe actually is on this list and had a question. From: Robin Rowe [EMAIL PROTECTED] I tried to reply to your mail, but it seems you cannot receive e-mail: [EMAIL PROTECTED] SMTP error from remote mailer after end of data: host mail.movieeditor.com [66.216.55.1]: 554 E-Mail address goof is not legal. If you provide me with a working e-mail-address I will re-send my mail. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] gimp-perl moved into its own CVS module
It's OT, but you started about reality: I didn't start anything. A very important rule to follow on the 'net or anywhere else: do _NOT_ forward private mails to public forums. ;) bugzilla.gnome.org, then I can't understand why you bother to read any mail not signed by some trusted GnuPG key (namely gimp-dev) Did I say anything about that issue? Maybe I really do bother... I regularly have problems explaining to people why a gpg key that is not signed or verified by anybody (self-signature not counted) is still very useful and still has all the same identification qualities as a trusted (or better: verified by showing your ID card) gpg key. (A trusted key, btw, is something that actually _weakens_ your security. If you are paranoic you should never trust _any_ key. And as a general rule of thumb: if you trust anybody or anything, you are not really paranoic ;) not speaking about responding to them. We are probably all evil hackers monitoring your mailing behaviour. Well, that's probably not true, but wether I am paranoic or not, I _do_ respect it when people send me private (off-topic) mails and don't forward them... F'up in private again, please ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] How do I test my perl scripts?
On Mon, Jun 02, 2003 at 07:20:39PM +0800, Kenny Law [EMAIL PROTECTED] wrote: Then I try to run it by entering Gimp, and starting the Perl Server by going to Xtns-Perl-Server Nothing seems to come up at all, so I went ahead and typed ./whatever.pl the perl server only outputs some text on the console (or whatever is connected to the stdout of your gimp process). not seeing anything is, therefore, not a bad sign ;) Thing is, I did not save the pl file to the usr/lib/gimp/1.2/plug-ins directory. that's ok. Is that gonna affect anything? Not that I'd know. Can someone tell me an easy way to test my scripts without registering a script? Or do I need to register it because my script deals directly on an image? If you want your script to show up in the menus, yes, you need to copy it to a plug-ins directory. If you just start it, it should open a dialog. If it is an Image-type plug-in it should enable you to select the image and layer to work on (but that is not heavily tested). I assume nothing like this happens in your case? -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Gimp Arrays in Perl
On Tue, Jun 03, 2003 at 10:54:25AM +0300, Shlomi Fish [EMAIL PROTECTED] wrote: gimp_pencil($layer, 4, @positions ); gimp_pencil($layer, 4, [EMAIL PROTECTED]); To add, arrays are always passed _into_ the gimp as references [...]. Functions returning a single array return a list, e.g. my @images = Gimp-list_images; # or so, foggy And functions returning an array and something else return an arrayref. There is no general rule, but if you do this: Gimp::set_trace(-1); (you can pass in flags like TRACE_CALL etc.. instead of -1, see perldoc Gimp), you will see what, exactly, will be passed to the pdb function. That's very handy when debugging scripts. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] License question
On Tue, Jun 10, 2003 at 02:19:00PM +0200, [EMAIL PROTECTED] wrote: I recently came across http://www.ftgimp.com/, which seems to sell an enhanced version of the GIMP (called FT Gimp) for 19.95 to 29.95 USD. which is fine, of course, except that I don't see any enhancements ;) based on the GIMP (outside of a button at the bottom of the main page that links to http://www.gimp.org/) Well, a button is more than the minimum requirement... FTGimp: Copyright (C) 2002-2003 FlamingText.com. All rights reserved. No reproduction allowed without permission. That might indeed provoke the wrong impression to some people. However, I do interpret this as meaning the site copyright, not the program, which is ok. To find out wether something really is fishy you'd need to look at what you get and wether all the requirements set by the GPL are fulfilled ;) (Personally I'd say it's a rip-off, nothing else ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] there is hope for gimp-perl-1.3 (was:red-eye-removal)
http://fmg-www.cs.ucla.edu/fmg-members/geoff/digicam/redeye Woaw, a PDL plug-in not written by me! Oh my god, I can't believe it happened ;) On Mon, Jun 16, 2003 at 09:54:42AM -0400, Carol Spears [EMAIL PROTECTED] wrote: perl ported to gimp-1.3 and the plug-ins as well. One thing of interest is that I am currently working my way through the Gtk2 module(s) available for perl. Apart from some things I'd really like to have changed and settled to make use of it, this was the major obstacle to a gimp-perl-1.3. Ok, that was a lie, the major obstacle was my lack of time, but now I don't have any other good excuses anymore. It might still take months, but at least I'd like to let you know that I am working on gimp-perl again, even if it's only getting used to the Gtk2 internals. (Gtk2 looks quite good already, btw..) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: there is hope for gimp-perl-1.3
It seems that porting gimp-perl to 1.3 is about trivial, well, at least getting it to compile and run most scripts. The version in CVS compiles and runs, but the scripts using gtk fail (so better not install it or be prepared to skio a few plug-ins when running gimp-1.3). In any case, although the perl-server and yinyang work fine, the 5-minute-port features: - a probably very high dependency on gimpcompat... if not the header file, then the symbols at least have the old names. - it still uses gtk1. porting the Gimp::Fu part itself should be easy, but gimp-perl uses some self-written classes, which is not yet supported the way I want it (sic!). Anyway, it was an experiment, but it shows that the job is doable. On Mon, Jun 16, 2003 at 11:31:16PM +0300, Dov Grobgeld [EMAIL PROTECTED] wrote: Woaw, a PDL plug-in not written by me! Oh my god, I can't believe it Yep, though the author missed the whole point of PDL by looping over x and y. Yeah, shame on me, I only noticed it *after* sending the mail. Ok, that's typical. Instead of the loop the following code would have done the same thing much faster. How about pacthing it and sending it to me for inclusion? *g* Actually, I ported all the non-gui stuff already, Great, I did it, too :() Ok, if you got gtk+ working, please send me what you did ;) straight forward. I then started looking at perl-gtk-xs. What got me stuck is the fact that you created the various widgets by inheritance and perl-gtk-xs still doesn't support inheriting gtk widgets on the perl level. Well, it does support it, sort of strangely-not-at-all-but-actually-it-does. I'd be happy to send you the stuff that I have, but I really don't think that you need it. well.. gimp-1.3 is surprisingly similar to 1.2 (ehy was everybody scaring me off? oh, nobody did.. hmm..). In any case, I only did a rough get-it-compiling again. I hope you got a bit further, so yes, send it to me. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: there is hope for gimp-perl-1.3 (was:red-eye-removal)
On Mon, Jun 16, 2003 at 10:20:03PM -0400, Carol Spears [EMAIL PROTECTED] wrote: anyone who can talk about their GIMP contribution in terms of months should only recieve my gratitude and awe. seriously. :) Ahem.. in some months, not for some months :() The actual contribution might be relatively small, especially since it's not anymore a direct contribution to gimp, but a contribution to a different cvs module now. In addition, i only contribute to projects when I need something for myself... so it's all purely egotistical. months like before gimpcon2? Good question... so far, it looks easier as expected. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] useless plead for honest evrsion numbers :)
On Tue, Jun 17, 2003 at 09:22:23PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: So all we need is an even version number... All around GIMP, most notably with its toolkit GTK+, the 2.0 era has begun. Should we really go for 1.4? Well, all the agruments I see in favour of 2.0 are always of the form well, evereybody else has 2.0. Well, gtk+2 is at 2.2, msoffice is at 2003 etc.. I don't think making up numbers just for the marketing is honest or useful for users. Frankly, I won't be oposed very much to calling it gimp-2.0, but everybody is expecting some _major_ release for 2.0, and 1.2 = 2.0, while having many enhancements, is not, in my opinion, much bigger than the 1.0 = 1.2 jump. So... I'd beg for a little more honesty in version numbering, and a little less marketing. A gimp-2.0 with lots of very nice but minor improvements (where is the modularity? where is support for cmyk? where are the programmable layer effects? and macro capability? even the fact that most perl scripts need not a modification to run does not show major cleanups in that part) is good for initial reaction, but people will aks themeselves where all the great things planned for 2.0 have gone. (Yes, I like the text tool, I etxremely like the undo history.. but that is all nothing major). I really don't think it qualifies as 2.0. That doesn't mean to diminish the work (which is impressive), but I think just randomly jumping on version numbers to have the same version number as everybody else doesn't help - it's just confusing, as version numbers become utterly meaningless. Just my 0.02, I feel that I had to make this point, don't kill me :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] useless plead for honest evrsion numbers :)
On Wed, Jun 18, 2003 at 09:55:52AM +0100, Austin Donnelly [EMAIL PROTECTED] wrote: I like the text tool, I etxremely like the undo history.. but that is all nothing major). But the undo history is not a new 1.3 feature, it was introduced by me in one of the 1.1 testing series and has thus been in all the 1.2 versions. That means either a) I don't pay attention to new features so I should not comment or b) Even less major features for a major release, or both. I see now, it's not mentioned under File=Dialogs as all the other dialogs, thus I kept not finding it. *sigh* -- -==- | ==-- _ | ---==---(_)__ __ __ 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] useless plead for honest evrsion numbers :)
On Wed, Jun 18, 2003 at 11:58:06AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: well, evereybody else has 2.0. Well, gtk+2 is at 2.2, msoffice is at 2003 etc.. I give shit on msoffice but GTK+ is the GIMP ToolKit and we will have a hard time to explain why even it's major release numbers diverge. Pardon? Why would you ever have a problem explaining why version numbers of *different* packages *differ*? You don't even have a problem of explaining why version numbers for single files differ, even less so for different packages. That GTK+ is the GIMP ToolKit is not at all of any concern, after all, gimp is the minority of applications using it. GTK+ has evolved. IF you want to tie the version numbers, better make it a single package. You obviously didn't look at the code. You obviously haven't read my mail. Really, I don't see why you are so pissed off... I don't need to look at the code to see that there are no major changes, and certainly none of the changes planned for 2.0 for a long time. is easy to migrate plug-ins and scripts. Apart from libgimp and some basic core functionality, the whole thing has been completely rewritten. Well, if that would be all, then there would be no reason to upgrade for users at all, as nothing has changed for them. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: development questions
On Wed, Jun 18, 2003 at 11:52:53AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: well-known as The GEGL GIMP with CMYK etc.. It is very hard to change such wide-spread information. And I don't see a real reason either. Such widespread information? Try google with such harmless keywoards as gimp and 2.0.. you might be surprised how many people wait for the new 2.0 backend or other features. After all GTK+ is the GIMP toolkit. This is IMO a very good argument for calling the next GIMP release 2.0. Actually it's the only good argument that is out there (and I don't see any good one against it). Frankly, that makes no logical sense. Just because I wrote some linux-only software does not mean I should make my software version 2.4. A softwrae version should reflect the software's version, not the marketing behind it. You keep explaining tzhat this is a good argument, but people don't seem to be convinced. Why is it such a good argument? It's a very bad argument in most other cases, so why is it a good argument for the gimp? Especially, what's the logical connection between the version numbers of two independent projects? The same argument can be applied to any gtk+, especially gnome. I don't see the benefits, or the goodness, of having the same version number for all software packages. To the contrary, this will just confuse me, as vital information (is the version number the only thing that changed on many software packages) will be destroyed. that warrants to increase the major release number. If you looked at the code you would have noticed that every single file was touched. That's also not a good argument. interface has been completely rewritten. There is not much in the app directory that resembles the old 1.2 code. If that's not worth an update in major release, I really don't know what would warrant it. A major version should be reserved for major changes... There is no major change in the user-interface. (In the code, yes, the UI, no). I do believe that users will not be able to see any major changes. Again, don't get me wrong. I am not trying to diminish all the work that has gone into gimp-1.3, but I fail to see why a bigger version number will be of any practical help, as opposed to more confusion. It might be for egotistical reasons, after all, if I invested a lot of work into a release, I want to bump the version number up appropriately. But that's no service to the users of my module. Better use codenames, that works well with users. (I liked the road to 2.0 ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] What's new in GIMP-1.3 so far
On Wed, Jun 18, 2003 at 07:20:13PM +0200, Hans Breuer [EMAIL PROTECTED] wrote: Hi Sven, is it time to flame again ? Please, although I am easily at flaming, I do not intend to do it, nor was it my intent to put off Sven, who works _so_ much, nor is it useful to start a flamewar with sven, who invests so much effort into gimp, without ever wanting a thanks. It was also not my intent to undermine the efforts that went into 1.3. I *know* a lot has been done. My *opinion* is just that naming it 2.0 is not a good service, regardless of how much work was put into it. I am convinced that a version number like 1.4 or 1.8 or 1.8 or 1.10 or... should be equally fine to tell people just how much work and effort has been put into the release. The reason I was relatively upset is that the main argument is always everybody else has 2.0, and I simply think that is dishonest and not useful to people. It's not dishonest because sven et. al. were lazy, to the contrary. My deepest respects for the whole rewrite, cleaning up etc. of the source tree. It sure was a lot of work that wasn't honored accordingly. I can fully understand if sven gets upset now when he interprets my mails as you didn't do enough to earn a 2.0. If making it version 2.0 is the only way to honor the hard work, so be it, I don't oppose this. I just hope that there are better ways to show this, more fulfilling ways. Please, don't flame (as I almost started to do in my earlier mails), it's of no use and will only give sven the feeling that people don't acknowledge what he does. A disaster that would be. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] What's new in GIMP-1.3 so far
On Wed, Jun 18, 2003 at 11:35:51PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Perhaps I told one or even two people involved in the computer magazine business about it when I tried to get some support for the conference this summer. What did you tell them, that gimp-2.0 will be released or that gimp-2.0 will have all those new features people expect for 2.0? I'm sorry but I need to sell this conference at the moment and everyone seems flat broke. We really could need some good marketing and instead Who is we? A company? You are selling a conference? So the fact that you mentioned the number 2.0 to (maybe) two magazine people means that this version number must be used? Also, who is we? *I* certainly don't need any marketing... I am sorry, but I feel your arguments in favour of 2.0 get more and more confusing, and rather long-winded. Especially if one considers that magazines and websites already published that gimp-2.0 will have cmyk support etc.. and this doesn't bind us in any way, either. you guys take this as an opportunity for flames? Please calm down, I more than once told you that I am not flaming. You are working yourself up into something here, really. No flame was intended, just a discussion about the version number. For some reason you are getting mad at this discussion, not the arguments. Why is this so? Why are you asking for speaking up if you only go mad at people who do? You'd better not have posted anything if you don't want to hear any responses. [google search] impression that most the hits for gimp 2.0 are caused by gimp used on the same page as gtk+-2.0. What exactly do you want to prove by 116,000 hits on google? Stop putting words in my or other peoples mouth, please. I don't want to prove anything by 116,000 hits. I want to prove that the expection for gimp-2.0 having some major new features like cmyk etc. is there, and searches like gimp 2, gimp 2.0, gimp cmyk certainly are good indications that a number of people and websites know about the not-at-all secret plans of adding colourspace support and others for gimp-2.0. Also, if you really want comparison by numbers, than the number of people writing that gimp-2.0 will have cmyk is certainly larger than the number of magazine people you talked to. And this is no wonder, as this has been mentioned publicly a lot of times. See above. BTW: do I have qualified to have an option ? BTW: Yes, indeed you do. What exactly makes you think you don't? Your reaction, I guess. Asking for responses and then critizising people for responsing at all. Please don't take it personally. That's the last thing I or others want. I'd be happy with a disucssion about version numbers, and I laid downmy arguments, namely that there are no major features for a major version number, and the added opinion that we don't need new major numbers just because everything else has (becaus thta's just confusing people). Other people have added that there are great expectations for gimp-2.0, and I think that 1.6 or 1.8 or so would be a nice number telling people hey there, this was a hell LOT OF WORK!, without destroying all the plans mentioned over the years. I even think that not having added major new features, but cleaning up the codebase and adding lots-needed bits here and there, is a good thing, as it enables people to start implementing difficult new features such as using gegl without having to add dirty hacks everywhere. Oh shit, I got one wrong. But wait, I'll put Image templates in as a new feature that I forget to listen. Yes, and swapfiles 2GB as probably a bugfix, not a feature at all, just like 64 bit cleanlyness is a bugfix, and not a feature. Let's not quarrel around features. If you insist that there are major features qualifying 2.0, I do not really oppose. However, I *do* oppose marketing, but gtk+ has it and similar arguments. I simply think it's unneccssary. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] A new filter idea..
On Thu, Jun 19, 2003 at 02:05:25AM -0700, Bowie J. Poag [EMAIL PROTECTED] wrote: Is this the right forum to discuss new filter ideas? If so, I have one i'd like to share. Sure it is, even more so if you plan to implement it, hint, hint :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] David Neary mail problems
On Thu, Jun 19, 2003 at 04:17:52PM +0200, David Neary [EMAIL PROTECTED] wrote: Just FYI, I get relay prohibited to [EMAIL PROTECTED] when replying to you. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] What's new in GIMP-1.3 so far
On Thu, Jun 19, 2003 at 12:56:03PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: I still disagree on that, people are eagerly waiting for 2.0 for the very features it should have. Unfortunately. Are they? I do. Others on this list do. It's up to you to make your opinion on that. I don't really know what people are expecting from GEGL CMYK, floating-point, programmable layer modes, dynamical effects, layer trees... happened. When GEGL is used, users will probably not notice that the crappy code that provides the basis for pixel manipulations in the This from the person who says the gtk+2 rewrite is the major feature people are expecting. Woaw. From all the people that addressed me and asked for CMYK support, only one so far was able to explain to me what benefits one can get from working in CMYK. All others would have made things worse since they Well, it's not just CMYK of course. I am also of the opinion (that I mentioend quite a lot of times), that working in CMYK is not at all the problem, but interoperability is the key problem. postscript paths (For clipping), and cmyk _bit_ format in files (because many programs intrepret rgb as CMY or worse). You also mentioned integration with FilmGIMP or CinePaint. Never did I use these words! I believe I didn't even quote them. ;) Who is you, in this case, again? That said, I don't think I can ensure you that we need 2.0 for the conference but I am still convinced that the amount of added features is worth it. *sigh*, I am confused. Well, I offer you to decide wether 2.0 is worth it from the fund-raising standpoint, and still state my opinion that 2.0 is a disservice to gimp users, and no service to anybody except maybe a ego push because so much work went into it. This release will definitely mark a new era of GIMP. Well, it's exactly as was planned for 1.4 before.. and I really fail to see the new era. My honest aplogies, but that's how I see it. We can rest it here if you want, and agree to disagree. If you agree, I'll be quiet, since I then said all that was to say from my side. When, if not now, do you want to increase the major version number? When there is a major change (e.g. gegl, cmyk). Using another toolkit is not a major change at all to me. Using the same internal representation for images, having the same features, simply doesn't warrant the new major number. I mean, all the concepts in gimp-1.3 are the same as in 1.2, no user visible major changes (yes, lots of small user visible improvements, but none of them qualify as major change). I simply don't think that 100 small improvememnts are one major improvement. In addition, arguments like but others have bumped their version number sound so extrenely fishy and dishonest to me that if such arguments are brought forward as the main and principle arguments to bump the version, I think there is ample reason to question them. The others do it is never ever a sound or reasonable argument to me. I hope the latter paragraph explains why I am opposed so much. It simply sounds fishy to me. Yet again, I let you decide wether it's important enough for the fundraising issue. *That* is an ugly and difficult to digest argument, but it concinves me. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: What's new in GIMP-1.3 so far
On Thu, Jun 19, 2003 at 02:03:50PM +0200, Branko Collin [EMAIL PROTECTED] wrote: So you have to ask yourself: who am I selling to? Graphics artists? (off-topic philosophical rant, not meant as an answer to you!) Personally, I didn't write gimp-perl (the only major contribution of mine to gimp) to sell it to anybody. I wrote it to fulfill a need. My need. This need can either be practical (as was in this case), or philosophical (I wrote a zipcracker once simply because I couldn't find a fere one), or being asked by people (I can do it, and so many people want it). Another way to describe that as the need for personal pleasure or masturbation or whatever you want to call it. Some people might want to sell. I don't. And everybody who tells me marc, you have to sell it to the people will get my sincerest flame, since I write it, you either take it, or leave it. You can comment, or help, or criticise. But if somebody tells me that you have to xxx I cna get rather angry, as all this you want to sell just presumes what I want or even tries to order me around. I know not everybody thinks that way. Alan Cox probably thinks similarly, Linus doesn't. There are all sorts of people. And not all of them feel that selling something they wrote is a must, or a need, or even useful. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] What's new in GIMP-1.3 so far
On Thu, Jun 19, 2003 at 12:14:30PM +0200, David Neary [EMAIL PROTECTED] wrote: I say it's time for a show of hands. My vote is for 2.0, because My vote is for 1.x, or 2.0, if sven decides it on the grounds that we need it for marketing. The other arguments simply don't overweight the confusion I anticipate. How *do* you count? ;= And, actually, I think voting is not useful... we'll have to convince the people with the power (which includes Sven) to do it. Whoever does the release decides. Anarchy. I like it. there are likely to be lots of new bugs and 1.4 makes it sould like a really stable release. Just like 1.0 and 1.2, eh? really stable releases, eh? or kernel-2.4, or.. I am sorry, but there are no stable and unstable branches. 1.2 or 1.4 or 2.0 have nothing to do with stability, but all with branching. You expect stability after lots of testing from users, who will not test cvs snapshots. That is, you create a 1.4.x or 2.0.x branch. This is how it handled about anywhere else, including older gimp versions. changing this wlel-established way if handling releases is going to give much more confusion. Basically, why don't we just use revision numbers from cvs, or a simple counter... really, the current trend makes version numbers less and less informative, so why keep them at 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] What's new in GIMP-1.3 so far
On Thu, Jun 19, 2003 at 05:09:57PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: OK, so replacing the approx. 8,000 lines of code in the base directory with GEGL would be considered a major feature. If we get all the other stuff we said would be in 2.0, yes. The fact that the other 230,000 lines of code that make up the application have been substantially rewritten counts as a minor improvement only? Well, from a user perspective, the improvement from using gtk2 over gtk1 is very nearly nil Even for me, the switch from gtk2 to gtk1 in itself is not at all an important new feature or improvement. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] [long] Suggestions + Patch, Redo (please dontflame), Part 1
On Wed, Jun 25, 2003 at 05:06:00PM +0200, David Neary [EMAIL PROTECTED] wrote: Well, the two big platforms where the GIMP will be used in the future are GNOME and KDE. Both of those follow the HIG guideline of Ctrl-Shift-Z. On windows, the main alternative app (photoshop) uses the same shortcut. While I totally agree to your agruments about following existing standards and/or practise, in Gimp we have the additional problem that ctrl-shift-z is not very ergonomical. Unlike word processors, undo-redo (repeatedly) is quite a normal and very common operation with gimp to compare operations or filters. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Suggestions + Patch, Redo - Part 1
On Thu, Jun 26, 2003 at 09:07:30AM -0300, Joao S. O. Bueno [EMAIL PROTECTED] wrote: of the first things I teach to one who is learning the GIMP is the dinamic shortcut allocation. Which has gone out of 1.3 (yes, you can enable it in the preferences, but people telling me that it probably doesn't work because it collides with gtk2 isn't encouraging). That's actually my only usability problem with 1.3 now... If dynamic shortcuts don't work reliably, they should be taken out and not be offered. The better option would be to fix gtk2 if it needs fixing, or just plain disbaling that part, since I can't say I found anything int he new UI that would let pay me the price of not having dynamic shortcuts. Really, dynamic key bindings is *the* killer feature. Disabling it in 1.3 is a major drawback. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Suggestions + Patch, Redo - Part 1
On Fri, Jun 27, 2003 at 04:07:29PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: However, there is no need to change this at all, I was just under the wrong impression that it was dangerous to enable them *at all*, and not dangerous to enable them because I often bump my head on the caps at the wrong time :) Well, we plan to add more mnemonics to the menus (mnemonics are those underlined characters that improve keyboard navigation). As soon as you start using them, you will find yourself accidentally reassigning keyboard shortcuts quite frequently. When I understand you correctly this means that I will see underlined entries that will not work as the corresponding keys are assigned by me to sth. else. Then this looks like a serious issue, since this feature is probably not used often by advanced users, but often by beginners, while the dynamic shortcuts are used as quick-assign-keys by advanced users. While I am all for making gimp more usable, I think making it more useful to advanced users would be better than to make life harder for them (correct me if i am wrong, but do you know anybody who is seriously using gimp without extensively using dynamic shortcuts? I don't). What you describe clearly is also a bug, since either the mnemonics shouldn't be there if they clash with my own keybindings (just as reassigning a keybinding will remove the old assigment), or the reassignment shouldn't happen when it clashes (less preferable). Also, wouldn't it make sense to use only one mechanism to handle both dynamic assigments as well mnemonics? If menmonics can't do that this might be a shortcoming in gtk2. Lastly, telling me I don't understand something because it works fine and then telling me that the feature doesn't work fine sounds like there might still be a problem lurking in this area... :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Suggestions + Patch, Redo - Part 1
On Mon, Jun 30, 2003 at 02:12:49PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Since the preferences toggle doesn't solve it at all, why do you call it a solution? Toggling it on does not work, as Sven said, as then mnemonics and dynamic shortcuts will clash. Sorry, but I don't think that they clash. What makes you think they do? Well, you made me think that by writing: Because [the dynamic shortcut feature] interferes badly with mnemonics, especially if these are used in the menus and we only just started to add them all over the place. This is also the reason why they are disabled by default in all GTK2 apps. Of course you can construct a usage case where there are clashes but in general they don't clash. Sorry, I don't see your problem. I have no problem, it's just that you said they are currently disabled because they interfere badly. Sorry, I translated that as clash, but still I don't understands why you first say it interferes badly and then say there is no problem... As a user in this case, I am just confused. If you last say is that it works just fine then I have no problem at all, and this thread is immediately dead because I misundertsood you I am just confused at what you wrote about that feature two weeks ago. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] the user installer
On Wed, Jul 09, 2003 at 11:23:57AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: we should just drop a number of files in the user directory. Unlike the GNOME developers we don't expect our users to be stupid. We put a One need not be stupid to not understand the dialog, though. Even experienced artists (== non-stupid) might not understand, nor even care. lot of effort into writing user-editable configuration files. We try to document what the user can do with her personal gimp directory. The Hmm.. yes, that makes perfect sense, but I always wondered why it is hidden inside a dialog I see exactly once, when installing gimp. That dialog is hidden quite perfectly, and users won't normally ever see them again. Just extracting this info into the help pages would probably help, since people are NOT interested in customizing rc files when they have never seen te program running, since they simply can't know what they should customize. to look at it. Hiding this information would not improve anything. Absolutely true. But right now this information is quite hidden to most users. The dialog is great and much better than a html help page for example, but it's presented at a time people will have no clue what it means. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: [CinePaint-dev] GIMP GBR format spec
On Thu, Jul 10, 2003 at 04:08:21PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: in such an approach and I am sure that not many XML parsers will like CDATA blocks of several megabytes. _all_ xml parsers cope with cdata blocks of several megabytes. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] MMX in 1.3 tree
On Thu, Jul 10, 2003 at 01:17:49PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: __asm__ __volatile__ () while the new code in The GIMP seems to be using asm() I don't know this stuff good enough to know the difference, but I'd __keyword__-style keywords are always there, even if gcc extensions should be disabled (strict ansi mode etc.. volatile means that there are side effects that are not (or can not) be properly specified. unless you write a kernel or other arcane magic, the need to use volatile indicates a bug in the constraints (i.e. forgetting to tell the compiler properly about the effects of the statement). for example, gcc will happily optimize away an asm() if the output operands aren't used, as it can then assume that the computing isn't necessary. volatile will keep it from doing that, but that might also keep useful optimizations from doing their work. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] MMX in 1.3 tree
On Fri, Jul 11, 2003 at 12:13:29PM +0200, Steinar H. Gunderson [EMAIL PROTECTED] wrote: I don't think there should be a % in the list of clobbered registers. yupp, there is no %mm1 register :) worse, I don't even think most versions of gcc know about MMX registers at versions 2.x (usually) don't know them, versions 3.x generally do know them. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] the user installer
On Wed, Jul 09, 2003 at 06:48:08PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: users. The dialog is great and much better than a html help page for example, but it's presented at a time people will have no clue what it means. Perhaps we should show it on every startup then ? It's setting preferences, so it quite naturally could be accessible from the preferences. I always wondered why I get this nice fancy wizards only on configuration, but when I later want to change these values I need to set them using a totally different interface (while the installer is s much cooler and nicer :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] GIMP GBR format spec
On Fri, Jul 11, 2003 at 10:08:55AM -0400, Leonard Rosenthol [EMAIL PROTECTED] wrote: A JAR is a special type of ZIP archive, which contains one or more data files along with an XML manifest about the contents. I've worked on a number of projects (both commercial and open) that have used such a format - it works quite nicely and is compatible with existing tools and technologies. Always better than reinventing the wheel!! the ar file format is much better established then jar, quick to access (unlike jar), and very very very much simpler. a complex container format like jar is not very helpful, as the added complexity just gets in the way (we just need to bundle files...) I think the approach of a JAR-like file for the future GIMP (and possibly CinePaint) file format is an excellent choice and allows for many avenues of expansion. i think jar-like is backwards. tar-like is much better (but tar itself is unsuitable due to the lack of rigid definitions and a multitude of different formats, the same is true for cpio). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Suggestions + Patch, Redo - Part 1
On Thu, Jun 26, 2003 at 10:02:41AM -0300, Joao S. O. Bueno [EMAIL PROTECTED] wrote: I don't know how much it's dictated by gtk2, but it seens weird that the GIMP usability gets hurt for changes on The Gimp Toolkit. Woaw, that sounding like a great argument, but I still think that gtk+ deserves it's life on it's own, and although it *is* the gimp toolkit it is also the toolkit for many other programs, which is why it is a seperate library nowadays. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Suggestions + Patch, Redo - Part 1
On Thu, Jun 26, 2003 at 03:21:10PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: You obviously did not understand the reasoning behind this change. Obviusly not, since only you explained it so far, saying that it clashes with gtk+. With the use of mnemonics in 1.3 the chance to make such a mistake has increased. That's why it is disabled by default. So it's basically a beginners mode of menus. That's fine to me, for course. From what you said I took it was dangerous to enable it, which it clearly isn't. keyboard shortcuts, then disable Dynamic Shortcuts again. That way the configured shortcuts are safe from accidental changes. IMO this is an improvement over 1.2. I strongly disagree, since dynamic shortcuts is *the* outstandiong feature that makes gimp usable form the keyboard. You actually suppose that users are incapable of using a keyboard. I don't think that this is an improvement. However, there is no need to change this at all, I was just under the wrong impression that it was dangerous to enable them *at all*, and not dangerous to enable them because I often bump my head on the caps at the wrong time :) Thanks for clarifying this and giving me back the great feeling I have when reassigning shortcuts to filters I often use. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] GIMP GBR format spec
On Mon, Jul 14, 2003 at 10:16:28AM -0400, Leonard Rosenthol [EMAIL PROTECTED] wrote: At 08:38 AM 7/14/2003 -0400, Robert L Krawitz wrote: What happens if in the future someone writes a gimp-java interface (like gimp-perl)? Would there be any security issues there? No. I do not believe people like you. Sorry, but how can you so bluntly claim this? These things happened before, and often times, so instead of a simple No there *should* be very good arguments of why it should be different... And yes, java byte code *is* getting executed without having to kick it off, at least, in netscape, ie, mozilla, opera, konquereor -- -==- | ==-- _ | ---==---(_)__ __ __ 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: Menubar in fullscreen mode [Re: [Gimp-developer] the userinstaller]
On Wed, Jul 16, 2003 at 03:39:25PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Should I file a request in bugzilla, asking for a Fullscreen with Menu option or do you think it would not be worth adding? I think it is not worth to clutter the menu with this since the menu is always available as right-click menu anyway. The menubar has no additional value. That (no additional value) must be the reason why it's enabled by default :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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: new-xcf (was:Re: [Gimp-developer] GIMP GBR format spec)
On Wed, Jul 16, 2003 at 04:28:18PM +0100, Adam D. Moss [EMAIL PROTECTED] wrote: Technically I don't know if that's true. From my ar man page: GNU ar can maintain archives whose members have names of any length; however, depending on how ar is configured on your system, a limit on member-name length may be imposed (for compatibility with archive formats maintained with other tools). If it exists, the limit is often 15 charac- ters (typical of formats related to a.out) or 16 charac- ters (typical of formats related to coff). But, that is of no consequence -- we wouldn't need to keep The archive formats that the ar manpage above refers to are what mortla people call object files. Since ar is part of binutils it tries to be compatible to other object formats which often have severe limitations. ar also handles hierarchical structures within ar files, but for compatibility it doesn't create them. (and there are common extensions that allow unlimited name lengths, these are also handled by ar). can easily be talking HUGE) temporary intermediate file. In this case something like a ZIP (or okay, equivilently, a compressed jar, whatever you want to call it) is a better (and still exceedingly standard in its most basic form) choice of wrapper for the hierarchy-file-plus-linked-resources. something like zip is the key. zip won't do, of course, since it's lousy at compression and also doesn't support random access like we want. Also, I think compression at the file level (whole file) is not a good idea anyway, so we could keep a simple wrapper format (like ar) and implement a more intelligent block structure within the constituent files. However, the reason why people propose ar, jar, cpio etc... as formats is that they cna be handled by users with ease, being well established. If we would design our own extremely simple wrapper format there would be no need to work with the compatibility mess existing formats are (all of them :). If we say that access by other tools than gimp is not important we could get away with an extremely simple format, say, cat files*, index at end which could be just offset and length, indexed by number, meta-info is all handled by an xml sub-file. The question is simply wether it should be a standard format or not. If we want to implement a kind-of tile cache within the image to speed up loadign and operations, using a format like ar/jar/etc. would just be a hindrance, as users wouldn't be able to deal with the files within them anyways. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: new-xcf
On Wed, Jul 16, 2003 at 10:43:13PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: designed as a GIMP-only format. People already use XCF in other apps simply because there is no reasonable format for layered images. That is not true. MIFF was around for years, for example, was always able to store layers, animations, and an unlimited amount of meta information. There are probably others, too. XCF isn't the first (nor the most open) format for this task (and it wasn't intended as one). there's seems to be a need for such a format which is why I would like to make access to it as simple as possible. This, of course, is a good goal in it's own. However: - maybe there is a need to have a gimp-specific file format, especially when you want to store the image data in a non-trivial way to speed up access. - maybe there is a need to have a nicely defined exchange format for complex images (xml + data is nicer than the ad-hoc design of miff). These are conflicting goals. Realisticelly, however, it'll be a long time till gimp wants a special, optimized on-disk format. (as for a format, miff is basically line-based header + image data, iterated, which is very nice... it'S not nifty XML, but the fatc that image data and metadata are grouped so near to each other is also nice...) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: new-xcf
On Thu, Jul 17, 2003 at 09:45:51AM -0700, Manish Singh [EMAIL PROTECTED] wrote: Consider the case of a corrupted xcf file. Maybe only 1 layer out of 20 is corrupted. With this proposal, a user needs either a special tool to (in this case, tar and zip would be preferable over ar, as ar tools are not well-versed at repairing/ignoring corruption, tar/zip tools often are better prepared). which is why I prefer it. zip/jar is especially crappy since the file index is at the end, which means it's harder to recover from a partial file. Actually, zip has all file headers twice: once before the file within the stream, and another time at the end. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] tentative GIMP 2.0 release plans
On Fri, Jul 18, 2003 at 09:59:22PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: decision. We came to the point that it should be called 2.0. It's just a number, so please, before you start the discussion again, think twice if it's worth it. It's not just a number, it is also used in the sources of external plug-ins. (e.g. AM_GIMP_2_0)... this is increased maintainance hassle, again for little gain. Thanks, however, for making it clear that you decided it, instead of just letting the discussion die. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: new-xcf [Re: Gimp-developer Digest, Vol 10,Issue 18]
On Fri, Jul 18, 2003 at 10:16:27PM +0200, Tomas Ogren [EMAIL PROTECTED] wrote: vim? emacs? .. I bet there are many editors that can handle large text files.. One thing (to bring this more on-topic again) to note is that vim doesn't handle large (gigabytes) files nice, loading it into memory. The same is probably true for emacs. The only editor I know (I didn't test millions of them though), that nicely handles large files is joe, as it does't load them into memory. For images, which might become big especially when storing a lot of extra info (undo info etc.), this is an issue ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] tentative GIMP 2.0 release plans
On Sat, Jul 19, 2003 at 12:10:54AM +0200, Sven Neumann [EMAIL PROTECTED] wrote: Gimp is more than Mitch and me, isn't it? Yes it is. And if you are really willing to continue this sinless discussion instead of helping us to get the release done, we can of This is *extremely* unfair. _You_ are proposing a rather big version change, and your only argument is soemthing like I told soma magazine Now claiming that Nathan isn't helping is rather strange. the basic CMYK supoprt finished that we started to work on). I really don't see your point. I am trying hard but I cannot see the lie you are talking about in big bold letters. I'm sorry but I don't have any Well, a lot of people (you can see that by looking at the vote) disagree. Given that it's just a number, you are extremely insisting... ago. This is just ridiculous, especially for a free software project that people work on in their free time. What is ridiculous is the unexplainable insistence on that change when so many people feel bad about it? -- -==- | ==-- _ | ---==---(_)__ __ __ 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] tentative GIMP 2.0 release plans
Sorry for the f'up to my own mail, but to avoid getting pushed into the troll corner I'd like to add this: The reason I am so insisting is that you continously misrepresent what people say, and the current climax is that you totally ignore that the overwhelming majority of people here said they dislike 2.0. If you stood up and publicly said something like: yes, the majority here is against it, but I, the Sven who does by far most of the coding work (might include Mitch, too, since you are his voice here) just overrule everybody else and force out 2.0 against the will of the majority, because I can and will do it, then that would be fine with me. Really. But you don't do this, and this is frightening to me. I don't oppose dictatorship on your side (I don't have reason nor the right to complain, too!), but I extremely dislike dishonesty. So if you are forcing this issue, please at least *acknowledge* it and don't try to misrepresent the issue in your favour. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] tentative GIMP 2.0 release plans
On Mon, Jul 21, 2003 at 04:36:53PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: What is so insisting is that you are not telling the truth, and I wonder why you resort to that. I am not going to let you claim in public that I was lying to you or any other GIMP developer. I didn't claim that. I do claim that you misrepresent facts on purpose, and this is a fact. I wonder what makes you think I would do that. I think you should excuse yourself for this. I think I am excused already, thank you. In any case, you can ignore this issue, misrepresent facts, force 2.0, but please don't ask me to believe you anymore. From my side, I consider this thread finished now. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] gimp-perl-cvs status
On Tue, Jul 22, 2003 at 02:51:16PM -0400, Carol Spears [EMAIL PROTECTED] wrote: is it worth building the gimp-perl module from cvs yet? Depends on what you are needing it for. The evrsion in CVS seems to be fully working, except that none of the examples that use their own Gtk+ interface have been converted to gtk2 yet, and coredump. Also, many constants have different names in 2.0, and, although I hopefully renamed them in the plug-ins, I certainly didn't test all the plug-ins. There are also certainly some edges, but you should be able to work with it quite nicely. And if some plug-ins don't work just delete them. (I even built it on windows for fun.. and as I though, no sourcecode changes were required, although I built with cygwin using gtk+2-win32) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] gimp-perl-cvs status / wingimp
On Wed, Jul 23, 2003 at 09:47:37AM -0400, Carol Spears [EMAIL PROTECTED] wrote: get this message from gimp that if i am elite enough to use threading, then i am elite enough to fix it. ;) i think if i pin perl from woody, i am elite enough to fix it. The problem is that debian woody uses an experimental and very very broken option when compiling their perl, namely the 5.005 threading model. It's known not to work with gimp or many other modules, and since it's explicitly flagged as experimental people really wonder why debian chose to enable it. The perl from testing or unstable (one of them has 5.008) should work. (Please note that it explicitly says that it is a warning only, doesn't mention elite anywhere and all that is requested is to not send complaints when it breaks, as you have been warned). also, i really really never ever thought that gimp-perl would be available for wingimp. The problem is that there seem to be two modes of building gimp or gtk+2, the using unix-like tools, and the (standard!) one. You could have the first (easy, for unixians) way with gtk1, too, but then gimp would only run with an X11 server. Gtk+2 can be built with the normal win32 backend even under cygwin now. That might not be the platform that people want (no nice installer etc.), which is why I think it will take some time until all this works out of the box. gimp-perl would need to be modified in it's config mechanism since the 1.2 wingimp doesn't provide the configuration framework needed. I do not know wether this will be true for the 2.0 version, but I suspect it will (?). while gimp-perl-1.2 could be modified, all hopes are gone when it comes to Gtk1. The situation is very different to gtk+2, though, since standard cygwin builds are available and useful and support pkgconfig. The build framework of Gtk+2-perl is also working with that. So, getting gimp-perl-1.3 Gtk+2 and gimp working under windows is just a matter of a lot of time and patience. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] gimp-perl-cvs status
On Wed, Jul 23, 2003 at 03:33:55PM -0400, Carol Spears [EMAIL PROTECTED] wrote: i am going to spend some time at my moms early next week. this might be one of those cool occasions where i can have the perl I got it working with tml's native build, linking msvcrt and cygwin.dll into the same process (does not work, but actually works) I'll check in a README.win32 soon that describes very roughly what I did. *However* you would better allocate a few days to it. Apart from the compile speed (gcc on win32 compiles 5-10times slower on my machine than under linux), you need quite a lot of time selecting the right toolset and gtk version (there are *many* different gtk+ versions). I'd even recommend against it at this stage, and leave it somebody else to prepare a distribution once 2.0 is out.. :) what is the chances that the gimp perl plugins can run be running on my moms window box next monday evening? close to zero. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Giving a try to gimp-perl
On Sat, Jul 26, 2003 at 01:53:30AM +0200, David Gmez [EMAIL PROTECTED] wrote: I'm using gimp 1.3.16 and gimp-perl from cvs, and i got some errors after running it, mainly in the Net.pm module. I post the output of the script, Most probably there is a problem starting the gimp. Try to run your script with -v to see the gimp's screen output, it will most probably tell you the rpoblem (such as missing DISPLAY, or problems with starting the perl-server). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] [FEATURE] Some plug-in settings should bepersistent accross sessions
On Tue, Aug 05, 2003 at 02:03:09PM +0200, Raphal Quinet [EMAIL PROTECTED] wrote: Look at the comment that I recently added in: http://bugzilla.gnome.org/show_bug.cgi?id=119032 IMHO, global parasites and immediate changes to the settings could make sense for the plug-ins that are used as filters, but not for the file plug-ins. For the file plug-ins, the settings should be a per-image property that is not affected by the changes made to the other images. As I said (or wanted to say, but didn't :): the perl plug-ins do exactly that, as tehy attach themselves as global and per-image parasite. It is unfortunate that the file plug-ins and the other filters are all called plug-ins, because they behave differently. What may make the problem in pelr is the UI. When I added buttons for the various options to recall defaults it became a bit complicated for the user to understand. Your proposal to have two difefrent default strategies (not reflected in the UI of the plug-in), i.e. file == per-image and global, filters == global only (the latter is not gimp-perl's behaviour, though) might make a lot of sense without cluttering the UI. be a property of the filter itself: it is reasonable to expect that applying the same filter to a different image will use the same settings as last time. Personally, I think it's equally reasonable to have the same settings as used on the same image earlier, though. Both are equally useful to me. For file-plug-ins, a fallback to the global default is also useful, although not as useful as with filters. This confusion between what is the right behavior for a filter and for a file plug-in has caused some problems before. See for example: What would be good would be a clever way to enable the user to chose, and have sensible defaults so the user need not to in most cases. For the plug-in writer this is fully transparent (if she uses Gimp::Fu). Yes, this is nice. However, I am not sure that modifying the defaults every time (without user confirmation) is a really good idea. It as, at best, a good guess of what should be done. gimp-perl was mostly modelled after what other plug-ins do in the case of LAST_RUN_VALS. different results because of what they did previously. This would be fine if they knew why (e.g., they had explicitely saved a default set of options) but this is not so obvious now. There is always the button to reset to defaults (and another button to use the previous values). Adding more buttons was not possible (clutter), while a menu with various choices is not quick to use. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] [FEATURE] Some plug-in settings should bepersistent accross sessions
On Tue, Aug 05, 2003 at 09:45:46AM +0200, Raphal Quinet [EMAIL PROTECTED] wrote: It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal I doubt that we can do this in the Right Way before the next release. Saving these preferences should be done by the core through a well- defined interface. Maybe I misunderstand the problem, but all perl-plug-ins can do that (and do that by default) without any extra interfaces, using parasites, for ages. They do that by default, though, and there is no UI to decide when to save - every invocation will overwrite the per-image and global defaults for the next invocation. For the plug-in writer this is fully transparent (if she uses Gimp::Fu). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Portable XCF
On Fri, Aug 15, 2003 at 01:57:35PM +0200, Raphal Quinet [EMAIL PROTECTED] wrote: included directly while others are included by reference. The main advantage of using XML is that it can easily be debugged by hand. The other arguments that have been discussed so far (for or against XML) are not so significant. Opinions differ... for me, debugging is absolutely unimportant. I never had to debug any xcf file, and I don't really want to change that :) An XML format can be easily extended or updated, and extending xcf was a pain, with xml at least this could become easier. and edited by humans, let's go for XML. If we want something compact and efficient, let's go for something else. Indeed, if. Efficiency is not the problem here (efficiency is much more a problem with the underlying image data storage, i.e. use flat or tiled areas etc.). XML isn't that inefficient compared to other serialization schemes, especially when this has to be done on load/save only, while it might be useful to dynamically swap in/out image data from the file (as some modern os'es do, while others rely on copying everything to swap first, as the gimp does :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Portable XFC
On Thu, Aug 14, 2003 at 09:10:37PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: point where no image manipulation program has gone before. However there is still the need for a good format for exchanging layered images between applications. So perhaps it makes sense to also develop such an I don't think there is a need for such an extra format. Existing formats like MIFF can easily cope with layered images and can easily be extended (linearly) with additional metadata. And surely if people want to read/write xcf and don't want to use GEGL i'd firmly say it's their problem entirely. I mean, if people want to read/write PNG without libpng it's their problem, too, and png was designed as interchange format, while xcf is not, should not, and will not. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Allow Maximise in Dialogs, like in Paint ShopPro 8
On Sat, Aug 16, 2003 at 01:21:05PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: (Keep in mind that users might be using text sizes larger than the defaults so static widget layouts are a really bad idea). In general all GIMP dialogs can be maximized and widgets reflow as you described. What are you talking about? File-New is the exception (it's fixed-size), but that's the only dialog I could come up with that has this problem. Because that's the dialog most often perceived as dialog, maybe he was assuming all others are the same? -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Portable XCF
On Fri, Aug 15, 2003 at 03:41:28PM +0200, Tino Schwarze [EMAIL PROTECTED] wrote: BTW: Would it be possible to get a sparse file by zeroing the unused bits? Then it would be quite space efficient (at least with some file systems). No, there is no way to do that. You will need to copy the file if you want to sparsify parts, or use os-specific interfaces to do that (if they exist, they don't exist under linux). The closest you could get is to garbage collect the file and truncate it at the end. -- -==- | ==-- _ | ---==---(_)__ __ __ 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
