Re: GAP
Hi, Tigert wrote: Well there is now the gimp/plug-ins/perl/examples/gap-vcr in cvs that is implemented in gnome-perl. It is very basic, but it somewhat works. Oh, how much do I love when new features that would be really useful but would need some good thoughts and probably even the redesign of some core menus are hacked up in a scripting language that is not supported on all systems. Great, now we have two ways to access the GAP. Doesn't that really make it much more useful and intuitive for the average GIMP user. I'd say: Drop this (probably nice) hack and wait for the changes Wolfgang just announced. Salut, Sven
Re: GAP
On Mon, Dec 13, 1999 at 02:19:16PM +, Nick Lamb [EMAIL PROTECTED] wrote: Well, much as I agree that providing essential features from GimpPerl is not the most desirable solution (sorry Marc) No, there are simple pratcical reasons for that. For every feature you provide you have to think about the additional value against the additional dependencies. Some things (that are implemented in perl) would not significantly lower the number of dependencies when done in another language. gap-vcr could be done in gap without any additional dependencies, however. So it's obvious what is better. erm "Plan to throw one away, you will anyway" and all that. Yepp. (I was under the impression that gap was no longer nmaintained anyway, but that was wrong). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: GAP
On Mon, Dec 13, 1999 at 09:59:53AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: would need some good thoughts and probably even the redesign of some core menus are hacked up Sven, I appreciate your comment on my plug-in. Have you looked at it? I do not consider it "being hacked up" thanks a lot and please go on valueing the work of others that low. in a scripting language that is not supported on all systems. That scripting language is supported on many MORE systems than java and gimp together, mind you? The interface to it, if you meant to say that, is supported on all systems except win32 (which would require makefile changes at most I presume). Come on Sven, this is FUD. Great, now we have two ways to access the GAP (Actually, we have over 20 ways or so...) I think the current interface is indeed hacked up (on the PDB level), btw. (for example it isn't even possible to adjust the brightness with filter all layers, at leats not with additional, really disgusting hacks). However, I consider it short-minded to think that a simple addition of a vcr console to gap would fix all the internal problems of that plug-in (that should have been written in perl anyway, where it is *way* easier to implement the very simple functionality of the gap plug-in family in a more correct way). Doesn't that really make it much more useful and intuitive for the average GIMP user. I think the gimp-user is the last one to tell the different between gtk+ and gtk+. It would be really intuitive for the user if Filter all Layers (for example) wouldn't be limited to c and perl plug-ins. I will happily remove my hack once gap is fixed. This has happened before and I didn't cry to be superceded. It has also happened a lot more times, however, that people announced these-and-those improvements and never did it (Hello Sven, btw!). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: When will Gimp support JPEG2000
[...] If it becomes widely used, I'm sure someone will be willing to risk being sued (as I have with TIFF implementation) and provide an ^^ illegal JPEG 2000 plug-in for Gimp, or otherwise a proprietary software company will make use of the LGPL libgimp and provide working JPEG 2000 support that way, but don't hold your breath :) [...] Could you talk a bit more about that, please? Who and why sued you?
Re: When will Gimp support JPEG2000
On Sun, Dec 12, 1999 at 11:56:57PM +0100, Eduardo Perez wrote: [...] If it becomes widely used, I'm sure someone will be willing to risk being sued (as I have with TIFF implementation) and provide an ^^ Could you talk a bit more about that, please? Who and why sued you? Perhaps that paragraph doesn't make it clear. I've never been sued by Unisys (or anyone else) but it seems clear from e-mail communication with them that they considered plug-ins like Gimp TIFF to be in violation of their LZW patent, regardless of how LZW is implemented inside the plug-in. In theoretical terms, I do not know what legal precedents exist in the US or in my home country (Great Britain) so I cannot say whether a court would consider the violation mine, libtiff's or both... In practise, as I have said elsewhere off list, it doesn't matter. If they haven't done more than write unfriendly e-mail in the past I see no reason to expect different in the future. Bringing cases to court would only highlight the unfairness of algorithm patents, which is not in their interest. This isn't really on-topic for gimp-devel, so I suggest you take any further discussion off the list. From the graphics point of view, adequate or even better replacements for LZW TIFF already exist. Nick.
