TGA plugin bugfix
Hi everyone, About three weeks ago now I found a bug in the TGA loader. I patched it and sent the patch to [EMAIL PROTECTED] I got a reply that it had been forwarded to the maintainer of the plugin, but I haven't heard anything since. So I'm trying the mailinglist. The problem is the following: if the TGA file is smaller than 26 bytes the loader will give an error, even though there are legal TGA files possible that are smaller than 26 bytes. I patched it and so far it works fine here. I have a patch but it's from tga.c in 1.1.29 to my fixed tga.c. Should I make a context diff that works from the root of the tree or is it ok to post the file patch (which has to be applied in plug-ins/common? Should I make a changelog entry (read something about that, not sure how it works). I realise that these may be a rather hair-splitting questions but I'm new to all this and I couldn't find anything in the FAQ about them so I'm asking them here. Lourens
Re: *squeak* feature request
Maneesh Yadav wrote: I'm not sure what state the gimp is in (I think you guys are in a feature freeze right?), but I would like to humbly propose the following (if there isn't a way to do it already): Select region, Float selection, run filter, Anchor selection? I think that that does what you mean, but I'm not sure whether the transparent tiles are skipped. Lourens
Re: use of the Delete key on Dec keyboard or similar
Right, but then there's another problem (at least for me). How would I change my Xmodmap so that gimp will do a delete-forward when I press my delete key? There would have to be at least one X key message that gets interpreted as such, otherwise modifying Xmodmap to get the old behaviour back would be impossible. I appreciate that on text terminals it's unavailable, simply because it does not make sense, but that does not mean that windowing systems should remain without delete-forward. It's the common way of doing things, and even if in theory it is wrong then one should ask whether to change the standard, try to change practice, or simply supporting both. Lourens Veen Richard Stallman wrote: Thanks for sending the report. Gimp developers, I asked Olivier to report this because it is a serious (though superficial) problem. Since the Gimp only runs under a window system, it should be able to handle both Backspace and Delete in the same way (as delete-backwards), since both of them can be distinguished from the ASCII characters C-h and DEL.
Re: use of the Delete key on Dec keyboard or similar
Olivier Lecarme wrote: [snip] Although the PC keyboard is by far the dominant keyboard in the world, it is a design mistake to have put a large Backspace key in place of the Delete key of all the preceding keyboards (note that computers and keyboards existed before the advent of the PC). Okay, now if I understand all this correctly, keyboards (and computers) did not have a delete-to-the-right key or keycode. Indeed, www.asciitable.com shows ascii 8 as Backspace and ascii 127 as DEL. If DEL is interpreted as delete-to-the-left, then we have two codes that mean the same, and no code for delete-to-the-right, correct? In order to correct this design mistake, programs like Emacs have interpreted the Backspace keysym as a DEL for years, knowing that the Backspace character can always be typed as a C-h, and that users are accustomed to erase on right using a C-d. However, this has the inconvenience that in the non-window case, the Backspace key sends a C-h, which is interpreted as a call for help. Now where did that C-d come from? Again, according to www.asciitable.com C-d or ascii 4, is EOT or end of transmission, not any form of erase. And I bet interpreting C-h as help is not something standard either (since ascii 8 is Backspace, nothing to do with help). I don't see why Emacs would be a better "standard" to model program behaviour after than the "standard" PC way of doing things. For programs designed after the PC has begun to be the dominant computer, most implementors have taken as granted that a Backspace key is meant to erase on left, and a Delete key is meant to erase on right. This was the simplest solution for them, but it is fundamentally wrong. I have the feeling to preach in the desert when I try to convince people of that, but at least they should try to understand the problem, and even try to find a solution which would work for everybody. Okay, so an error was made. The makers of the pc keyboard should have left the DEL key where it was, and added a delete-to-the-right button in the place where we have delete buttons now. It seems that that brings us to a deadlock. Implementing programs using the old definition would mean making Delete delete-to-the-left, and Backspace also delete-to-the-left (since making it delete-to-the-right weuld be rather unlogical). For people using old-style keyboards like Msr. Lecarme, that would solve all problems, and it would also be consistent historically. However, this leaves us without a key (or keysym) for delete-to-the-right, thereby making supporting the pc standard impossible, even tweaking the xmodmap wouldn't work. The only solution for good default behaviour I can come up with is a rather weird one. We'd have to interpret the Delete keysym as delete-to-the-left, and Backspace as delete-to-the-right. As I said before, this is highly illogical, but it's, as far as I can see, the only solution that would support both original keyboards (automatically, Delete works correctly and there is no Backspace key) and PC style keyboards (the keys would have to be swapped in the xmodmap). The problem with this is that changing the behaviour in gimp (or GTK, since I agree that this would be more of a GTK problem) would "break" it on every PC out there, so that all users would have to change their Xmodmap, thereby breaking other programs that depend on Backspace being delete-to-the-left and Delete being delete-to-the-right. Having written that, I think that there is one solution left. Make a config option in GTK that allows Delete being interpreted as delete-to-the-left. I have no experience whatsoever with GTK hacking but I don't think it should be that hard to implement. People who prefer PC style behaviour would leave the switch to off, while Msr. Lecarme would turn it on and make his Delete key work appropriately according to his standard. And Simon: All true, so it conforms to the PC standard. As far as I understand now (and I think I understand the problem) the Delete keysym should actually delete to the left (ie behave like Backspace) Lourens Veen
Re: freetype plugin
I tried to reach its homepage at http://freetype.gimp.org but never got any response from the server with an error: Cannot open the HTTP connection to freetype.gimp.org port 80; [No route to host]. Anyone with the same problem or a better address? Uwe Same problem here. I ran a couple of traceroutes and everything is fine right up to gig8-1.snr1.CS.Berkeley.EDU (169.229.3.66), after which I get a No route to host too. Tracing gimp.org also got me to gig8-1.snr1.CS.Berkeley.EDU, but that one does work, the box behind it is graft.XCF.Berkeley.EDU (128.32.45.176). Apparently someone at Berkeley messed up the router config and/or the freetype.gimp.org webserver and/or the DNS entries. (that last one sounds plausible, freetype.gimp.org is 128.32.43.176 while gimp.org is 128.32.45.176. I don't see why there would be two different boxes, it could be a typo). At any rate, it's not your connection that's at fault here. Lourens
Re: new plugin
Hi David, Good idea! As for the use of Allegro, isn't Allegro under the GPL? If so, (and I assume your plugin will be GPLled as well) you could just rip out the loading and saving code and paste it into your plugin. That way things are Allegro-independent and if you don't copy the parts of Allegro you don't need it shouldn't be that big (at least not due to the inclusion of parts of Allegro, I can see that this is quite a big project). Lourens david rohde wrote: I am currently writing a new plugin, which I hope if there is intrest in it could be included in to standard gimp distributions. I understand that the gimp is frozen at the moment, but if anyone could tell me the process required for a new plugin to be considered for the gimp. Should I have users before I ask you guys to look at it. Also the plugin uses a fairly uncommon library allegro. I am looking at making the plugin allegro independant, however the resulting plugin may end up being a quite large plugin when complete. The plugin I am writing is an aid for creating seamless tile maps. Basicly a tile editor. It uses allegro primarily because I have used a file format derived from the allegro dat format. Any help on these points would be appreciated Also if you rather i did not post to this list, please direct me elsewhere. Thankyou David Rohde
Re: Some Compile Error 1.1.30
Additional info: I got the same error in configure, however make worked fine on my system (glib 1.2.8 and gtk 1.2.8) and I'm running 1.1.30 without any problems now. Lourens Frank Werner wrote: Hi there, i have problems to compile gimp-1.1.30. First some error occurs while configuring the make script: --- ... creating devel-docs/pdb/Makefile sed: can't read ./devel-docs/pdb/Makefile.in: No such file or directory ... Checking if your kit is complete... Warning: the following files are missing in your kit: po/Makefile.PL po/update.sh Please inform the author. Warning: prerequisite Parse::RecDescent 1.6 not found at (eval 13) line 220. ... --- While executing make this error occurs: --- make[2]: Entering directory `/usr/src/packages/gimp-1.1.30/libgimp' Makefile:1472: warning: overriding commands for target `makefile.mingw' Makefile:299: warning: ignoring old commands for target `makefile.mingw' gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../intl -I../intl -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/gtk-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/glib-2.0 -I/usr/local/include -I/usr/X11R6/include -I/usr/local/include -DGIMPDIR=\"".gimp-1.1"\" -DDATADIR=\""/usr/local/share/gimp/1.1"\" -DSYSCONFDIR=\""/usr/local/etc/gimp/1.1"\" -DG_LOG_DOMAIN=\"LibGimp\" -DGTK_DISABLE_COMPAT_H -g -O2 -Wall -c gimpchainbutton.c gimpchainbutton.c: In function `gimp_chain_button_class_init': gimpchainbutton.c:110: structure has no member named `type' make[2]: *** [gimpchainbutton.o] Error 1 make[2]: Leaving directory `/usr/src/packages/gimp-1.1.30/libgimp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/packages/gimp-1.1.30' make: *** [all-recursive-am] Error 2 --- I have installed glib-1.3.2 and gtk+-1.3.2. Can someone tell me, how can I solve this problem? Thanks in advance, Frank Werner
Re: RFC: The future of The GIMP
I realise that it's probably too late already, but dare I say C++? Did anyone ever even consider this? As for the plugin distribution, I think the nicest way would be to have a plugin manager that would enable you to download plugins from the web on the fly. Something Linux distributions have too, you just connect to the server, list the available plugins, let the user select what he/she wants, download and install them. That would IMHO certainly be the nicest solution. Lourens
Re: RFC: The future of The GIMP
Sven Neumann wrote: Please keep in mind that the main intention of our proposal has been to better distribute work between core and plug-in developers by seperating the source trees during development. Perhaps this scheme could be translated to distribution too, but it does not have to. If we decide to continue to distribute an awful lot of plug-ins with The GIMP as we do know, we can always put them all into one tarball at release time. Or several smaller tarballs, or a single for each plug-in ... Salut, Sven All true, but then the problem is that non-technical users have to wait for someone (or their favourite distribution) to package new plugins. IE, let's say I write a new plugin, put it on plugins.gimp.org in source form. Then Joe User can't use it until Red Hat releases an updated rpm, which may take a while. With the automatic building the plugin is instantly available. For distributing, this makes sense, but what about updates? I don't think anyone would want to download a whole new tarball just to get one new plugin. And if you're going to do separate tarballs, then what's wrong with also creating a standard automated way to build and install them? Lourens
Re: gimp 1.1.31-32 BUG
[EMAIL PROTECTED] wrote: I have just downloaded 1.1.31 and 1.1.32 patches from ftp.gimp.org I notice that 'TODO' file has been updated to show some things that will happen with Gimp. However, I don't see any mention of "improved keyboard operation", i.e. the stuff that generated quite a bit of hate mail on this exact list a few weeks ago. I have to admit though, as soon as the discussion shifted into intelligent suggestions, everyone dropped out real quick. 1) That would be the TODO from the 1.1 series then? 1) 1.1 is in feature-freeze now + 2) Improved keyboard operation won't be fixed in 1.1, and thus it's not on the TODO list. I haven't downloaded 1.1.31 yet so I may be wrong on the first assumption, in which case this argument doesn't work. Lourens
Re: gimp 1.1.31-32 BUG
Apparently Sven's mail about this took 6 hours to reach me, so ignore this one please. Lourens and thus it's not on the TODO list. Lourens
Re: Pupus pipeline: what Adam has been doing, etc. etc.
That sounds good, very good. Does that mean that I will get my layer tree instead of layer stack as well? (from your mail I gather that it's possible but depends on the UI implementation). Being a programmer I wouldn't object to the connect-boxes-with-lines model, perhaps it should still be a possibility.. Lourens
Re: [Lourens Veen] Gimp as a marital aid
[EMAIL PROTECTED] wrote: I bet that gave you a warm and fuzzy feeling to write a response like that. If instead you (or others) focused on the issues rather than "bad language" things would have been a lot better. If you hadn't put them under a pile of fucks and shits then maybe I would have been able to see them. I'm not going to reiterate what has been said already about the developers trying their best, the only thing I'd like to add is that perhaps you should think about other peoples opinions and preferences as well. Just because you don't use tear-off menus doesn't mean nobody does, and that they are therefor worthless. And in the same fashion, you may not like the tree structure of the Preferences box, other people (like me) think it's nice. You're not the only gimp user you know. Then, there's no need to command the gimp developers. You didn't pay for the software, and the license clearly states that there is no warranty for fitness for any particular purpose. If you don't like it, you can always use another program. I imagine Photoshop does have a nice interface. And if you don't like MS then you can run it on a Mac. Buying Photoshop has the additional advantage that you can complain about the product with Adobe and, given the fact that you paid for it, expect them to add the features you want to add. Free Software doesn't work that way. Lastly, it would be nice if you built some sort of argument around your opinions, instead of stating them as fact (I'm talking, amongst others, about the comment you made about GNOME being an "obsolete desktop environment". I'm not saying it isn't, I just wouldn't know why, and I expect some arguments to go with such a statement). This is almost same as flaming a very reasonable email because of "bad spelling". Instead, you should have just written that response in a text file, laughed about it, and then go back to whatever you do for a living. I realise that this is not a humour list and as such my post was off-topic. Also, people may not like my sense of humour, in which case the message was useless to them. If I offended or annoyed anyone with my mail please accept my apologies. However, I don't think that using foul language and an angry, demanding tone is comparable to bad spelling. Spelling correctly is pretty difficult, especially for people for whom English is not a first language (and I even know some English people who make mistakes rather often). People spelling badly try to do it correctly though, and they make mistakes simply because they don't know how to do it correctly. Your subsequent post has proven that you are quite capable of writing in a more friendly and polite manner, and as such I think that you should do so. I don't believe that you really are an evil person, and many of your statements are valid. But as Sven said before, putting them like that and expecting people to read around the insults and give you an answer to your question would be to expect others to be very much more professional in their writing than you are in yours, and I don't think that that is a very reasonable expectation. Lourens
Re: Compilation problems ...
[snip] Basically the following behaviour could be observed: "make" crashes at the FIRST RUN saying that gimpwidgets.o would not exist - even though it does. Running "make" a second time runs smooth - no problems. "make install" crashes always at the FIRST RUN saying: ln -s ../../dialogs /usr/share/gimp/1.2/help/C/toolbox/help/dialogs ln: cannot create symbolic link `/usr/share/gimp/1.2/help/C/toolbox/help/dialogs ' to `../../dialogs': No such file or directory [snip] I'm not an expert, but what version of GTK do you have? You need 1.2.8, it will not work with 1.3 developer versions. I don't think that that's it, because I think you would have gotten other errors too then, but since it complains about the widgets it's a possibility. Lourens
Re: FreeImage
But is the license GPL compatible? And is it as flexible as the current plugin system? Lourens Martin Weber wrote: There is a very very fast (faster than Photoshop) image loader called FreeImage: http://home.wxs.nl/~flvdberg/ With small adoptions it also runs with Linux. -- Sent through GMX FreeMail - http://www.gmx.net
win32 install problem
Hello, I recently got a friend of mine to try Gimp for Windows (she doesn't have Linux yet, but wants to try that as well :). She installed the file from gimp.org/win32, and then replaced gimp.exe with the new gimp.exe from the update. However, upon starting gimp (which worked ok at first) she now gets the following sequence of screens: http://nova.student.utwente.nl/gimp/pagina1.jpg http://nova.student.utwente.nl/gimp/pagina2.jpg http://nova.student.utwente.nl/gimp/pagina3.jpg Any ideas? Lourens
Re: win32 install problem
Well, she reinstalled everything, then replaced gimp.exe with gimp.exe before running it the first time and poof, it works. Perhaps something to put on the download page, prevent people from trying it out while the second file is downloading, apparently this doesn't work. Lourens Lourens Veen wrote: Hello, I recently got a friend of mine to try Gimp for Windows (she doesn't have Linux yet, but wants to try that as well :). She installed the file from gimp.org/win32, and then replaced gimp.exe with the new gimp.exe from the update. However, upon starting gimp (which worked ok at first) she now gets the following sequence of screens: http://nova.student.utwente.nl/gimp/pagina1.jpg http://nova.student.utwente.nl/gimp/pagina2.jpg http://nova.student.utwente.nl/gimp/pagina3.jpg Any ideas? Lourens
