Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
just to say, yeah, what he said ;) seriously though, i have real trouble remembering to use shft+crtl+z instead of ctrl+r, it's mainly habit, but it is also the fact that i find the old method more comfortable. the only place Ctrl+ r gets me into trouble is Mozilla, when editing an email i ocasionaly refresh the page by accident, thanks to my painfully slow connection i can sometimes stop it before it gets anywhere though :P i'm sorry if i've missed large parts of this thread, my hotmail address is under attack from a worm, so i don't receive a lot of mail(other than security updates) at the moment :( Phil. From: Nathan Carl Summers [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: David Neary [EMAIL PROTECTED], Branko Collin [EMAIL PROTECTED], Gimp Developer List [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Redo shortcut (was: Undo shortcut) Date: Tue, 23 Sep 2003 09:50:58 -0700 (PDT) /me returns from the hurricane, finally able to catch up on several days worth of email. On Mon, 22 Sep 2003 [EMAIL PROTECTED] wrote: However I *love* the Ctrl-R binding, especially because it lets me quickly compare the done and undone versions of an image using a single hand with very little effort. Try to do it with Ctrl-Z/Shift-Ctrl-Z and you'll find that you need either very good coordination between fingers (better than the one I have at least) or to use both hands. I agree. Gimp's undo and redo feature differs from many other programs in that when comparing subtle changes it is useful to switch rapidly between the before and after views, while for a program such as a word processor, that is probably not a useful thing to do. This being the case, this particular need of GIMP users was probably not considered by the HIG. Personally, I compare between the before and after by holding down control and hitting z or r as necessary. For some changes, I switch several times a second, as the human eye is remarkably able to detect small differences when they are animated. Switching between views this fast with accuracy is simply not possible using Shift-Ctrl-Z due the the physiology of the human hand. The optimal hand position is left on the shift and control and right on the z, with the finger on the shift moving every other beat of the other hand and the finger on the control key staying still. Here the body's natural cordination works against switching views quickly, as the nervous system will assume that the finger on the R key and that on the shift key should really be synchronized. This leads to errors. With the old bindings the natural cordination system helps to acomplish the task accurately and faster. So, if it's possible to have two different keybindings for the same command I'd like very much to have both. Unfortunately, it is not. Really, GTK should be made more flexable in this regard, but it is not a trival problem, due to how GTK handles accelerators. Since we only can choose one, it makes sense that we choose the one that ergonomics favors. I'm sure that in this case most usability people would say that actually being able to use the feature is more important than consistancy with some other apps. Especially because this particular funciton isn't particularly consistant between apps. On the other hand, we could go for both ergonomics and consistency by using MS Office's Ctrl-Y. Note that I am not recommending it. I think keeping redo the way it is in 1.2 is the best policy. BTW, the mail program I'm using right now (Forte Agent) uses Ctrl-R to redo. There we go, between that and tradition, we have all the justification we need. ;) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer _ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Kudos to The GIMP Developers!
tongue-in-cheek So the huge image you generated is a fractal? Isn't it a bit silly to render such images (especially if they are huge) with GIMP, where all of the image's pixels are kept in memory (or the tile cache) all the time? Aren't many fractals such that you could calculate the value of each pixel independently of the others, with a very simple and minimal (non-interactive) program? (And if your desired output file format is PostScript, why not let the printer do the job ;-) PostScript is after all a programming language... Just send the printer a PostScript program that calculates the desired image. For many fractals, it might be surprisingly short.) /tongue-in-cheek --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Kudos to The GIMP Developers!
Hi, [EMAIL PROTECTED] (Tino Schwarze) writes: BTW: Is it possible that there is a 3 Gig limit on per-process memory? The machine has 6 GB, no ulimits and I got a could not allocate x bytes message when I gave 3 Gig tile cache to GIMP (it took about 500 Meg for other stuff, so I settled with 2.5 GB tile cache and still got a 3 Gig swap file plus 3 Gig memory usage). On a 32bit platform a single process cannot allocate more than 4GB so I guess you've been hit by that limit somehow. You will need a 64bit architecture in order to address memory beyond 4GB. We haven't tested this but if you were using a 64bit platform GIMP-1.3 should allow you to extend the tile cache beyond 4GB even. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Kudos to The GIMP Developers!
[EMAIL PROTECTED] (2003-09-24 at 1132.48 +0200): I'd just like to say: Well done. I managed to create a A1 poster at 600 dpi - a whopping 1.1 Gig of picture data (about 2x14000 pixels). Was there a real difference between 600 DPI and 300 DPI? I have a mag here that is done in 300-400 DPI, with good paper... and it looks nice, and it is something you look nearer than a wall poster. BTW: Is it possible that there is a 3 Gig limit on per-process memory? The machine has 6 GB, no ulimits and I got a could not allocate x bytes message when I gave 3 Gig tile cache to GIMP (it took about 500 Meg for other stuff, so I settled with 2.5 GB tile cache and still got a 3 Gig swap file plus 3 Gig memory usage). What kind of processor and OS was used? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Kudos to The GIMP Developers!
On 24-Sep-2003, Tino Schwarze wrote: BTW: Is it possible that there is a 3 Gig limit on per-process memory? The machine has 6 GB, no ulimits and I got a could not allocate x bytes message when I gave 3 Gig tile cache to GIMP (it took about 500 Meg for other stuff, so I settled with 2.5 GB tile cache and still got a 3 Gig swap file plus 3 Gig memory usage). Its up to how your os and processor arch works. Like, x86 has a limit of 4 gigs per process, and Linux is defaultly setup for something like 3 gigs for the process, 1 for the kernel. You could be hitting that. -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 signature.asc Description: Digital signature
Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2003-09-24 at 1132.48 +0200): I'd just like to say: Well done. I managed to create a A1 poster at 600 dpi - a whopping 1.1 Gig of picture data (about 2x14000 pixels). Was there a real difference between 600 DPI and 300 DPI? I have a mag here that is done in 300-400 DPI, with good paper... and it looks nice, and it is something you look nearer than a wall poster. IMO - Text...reading text in 600 DPI and on 300 DPI just feels different. For graphics however, the lots of DPI are just used - in most cases - to emulate the color deph we have on CRT. Arranging for the GIMP to be able to generate PDFs with text layers as text is on my todo for 2.2 list. Last month I made an artowork here that went to press either: 150DPI and A4, with text over graphics. Since the graphics in the case were washed out to work as a background, 150DPI was just good for it. The text however loooked a bit steppy ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: Arranging for the GIMP to be able to generate PDFs with text layers as text is on my todo for 2.2 list. To get that done in sane way, you'd have to use a PDF Pango backend. There is such a beast but last I checked it wasn't working that well and it depends on PDFLib. Also the current PDB API for text is definitely not sufficient for this but it would be worth to extend it for this matter. BTW, it would be really nice if you could communicate this better. Your todo for 2.2 should better be made available to the other developers since we will soon have to decide on the feature list for GIMP 2.2. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Kudos to The GIMP Developers!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tino Schwarze wrote: | Hi there, | | I'd just like to say: Well done. I managed to create a A1 poster at 600 | dpi - a whopping 1.1 Gig of picture data (about 2x14000 pixels). | While GIMP 1.2.4 crashed while rendering the fractal, GIMP 1.3.20 | managed to get it done and even save it as Postscript. Weehee! | | BTW: Is it possible that there is a 3 Gig limit on per-process memory? | The machine has 6 GB, no ulimits and I got a could not allocate x | bytes message when I gave 3 Gig tile cache to GIMP (it took about 500 | Meg for other stuff, so I settled with 2.5 GB tile cache and still got a | 3 Gig swap file plus 3 Gig memory usage). If you are using IA32, on linux, then yes there is a 3 Gig limit on per-process memory. 1 gig for the kernel and 3 gigs for the process. If you are using Opteron, Itanion, Power4, G5, UltraSPARC, or Athalon 64, then you don't have that limit. - -- Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/cf4yad4P1+ZAZk0RAhT6AKCWSVCrb8iqNDsBRamHFOyxrkvuqACfVS5t ZYYakwlna9ufenHocYObxYc= =54ge -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
Nathan Carl Summers wrote: I agree. Gimp's undo and redo feature differs from many other programs in that when comparing subtle changes it is useful to switch rapidly between the before and after views, while for a program such as a word processor, that is probably not a useful thing to do. This being the case, this particular need of GIMP users was probably not considered by the HIG. I'm sure that ergonomy was considered for Photoshop when they chose Ctrl-Shift-Z for Redo... I do think it's overstating our importance somewhat to say that what's good for a large portion of the rest of the world is not good for us. Personally, I compare between the before and after by holding down control and hitting z or r as necessary. For some changes, I switch several times a second, as the human eye is remarkably able to detect small differences when they are animated. You will be able to continue to do this, using the Wonders of Dynamic Shortcuts. However, I think that in the general case we should try to adhere to the keybindings which people expect if they have used other applications (and not just imaging applications). Switching between views this fast with accuracy is simply not possible using Shift-Ctrl-Z due the the physiology of the human hand. The optimal hand position is left on the shift and control and right on the z, with the finger on the shift moving every other beat of the other hand and the finger on the control key staying still. That depends where the z is on the keyboard :) So, if it's possible to have two different keybindings for the same command I'd like very much to have both. Unfortunately, it is not. Really, GTK should be made more flexable in this regard, but it is not a trival problem, due to how GTK handles accelerators. I believe we could hard-code two keybindings to work as the default, couldn't we? Then if the keymapping is changed, you're on your own. Perhaps I'm talking through my hat here. I'm sure that in this case most usability people would say that actually being able to use the feature is more important than consistancy with some other apps. Especially because this particular funciton isn't particularly consistant between apps. It's pretty consistent. And the usability people have considerably more experience with this than either of us :) I've added the usability list as a CC to see what they think. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp-Print 4.3.21
Gimp-Print 4.3.21, released September 24, 2003, is a development release of this package. Like all development releases, this version is considered unstable and should only be used by those individuals tolerant of the likelihood of problems. Individuals desiring a stable release of Gimp-Print should use the latest 4.2 release. Gimp-Print is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and newer) and Linux systems in many cases equal to or better than proprietary vendor-supplied drivers, and can be used for many of the most demanding printing tasks. This software includes the Print plug-in for the Gimp, and Ghostscript and CUPS drivers, including Foomatic data. The Print plugin for the Gimp requires the Gimp 1.2 (later versions of the Gimp are not supported). You may need to install a package named gimp-devel or the like on many distributions. The CUPS driver requires CUPS 1.1.15 or higher. You may need to install a package named cups-devel or the like on many distributions. We strongly recommend using CUPS with Gimp-Print as a general-purpose printing solution. We do not currently recommend using Foomatic, as the Foomatic data generator included with Gimp-Print offers very limited capabilities. This will be fixed in a future release. The Foomatic data will work with either Foomatic 2.x or 3.x. Foomatic 3.x has additional capabilities that this package detects and takes advantage of. The IJS-based GhostScript plugin driver requires GNU Ghostscript 6.53 or later, ESP Ghostscript 7.05 or later, or APFL GhostScript 7.04 or later. Users of Macintosh OS X 10.2 and above can use this package, as the printing system is based on CUPS, which is supported by Gimp-print. Note that Macintosh OS X 10.0 and 10.1 (including 10.1.5) cannot use this package. Please read the README file for full instructions on installing this package. Gimp-Print 4.3.21 contains the following major changes over Gimp-Print 4.3.20: 1) This release offers further improvements in quality. The specific improvements are described below. The driver now attempts to use as many small drops as possible before starting to use larger drops when printing on variable drop size printers. This improves the texture of midtones, particularly at lower resolutions (extremely high resolutions typically only use the smallest drop size available). The result is that 1440x720 DPI, or in some cases even 720 DPI, now offers quality almost identical to higher (and slower) resolutions such as 2880x720 and 2880x1440 DPI. The driver also uses more light ink prior to switching to dark ink (for 6 and 7 color printers). This improves smoothness in midtones. Furthermore, the transition between light and dark ink is adaptive, depending upon the amount of black (both black ink and black component printed with color inks) in addition to the color being printed. This allows use of more dark ink in darker regions, reducing the likelihood of overloading the paper and producing a darker gray tone. The combination of these two changes increases ink usage in some cases (mostly saturated midtones, where more light ink is used) and decreases it in others (mid grays). The color correction has been further tweaked based on observations of behavior in 4.3.20. In particular, the desaturation in dark tones has been tweaked to achieve a better match and smoother transitions. The EvenTone dither algorithm has significant improvements in smoothness when multiple drop sizes are used, particularly for black-only prints. In addition, certain artifacts in the light midtones have been eliminated. There are some very weak new artifacts that may occur in regions of transition between drop sizes, but in most cases these will not be visible. Finally, the black generation has been changed, producing more solid dark tones. Instead of a linear ramp between the point at black ink starts to be introduced and the point at which the gray component is printed with all black, the black generation now uses an exponential (gamma) curve whose exponent depends upon the printer and the paper in use. This produces more solid dark grays while avoiding either a sharp transition from muddy grays using only color inks, excessive grain from use of too much black ink in lighter grays, or lack of contrast in dark tones caused by too much black ink. At present, only the Epson driver utilizes these changes. 2) Individual Epson printers have been retuned, producing closer matches between different printers and papers. Specific improvements: * The new Stylus Photo series (780, 785, 790, 810, 820, 830, 870, 890, 895, 900, 915, 925, 935, 1270, 1280, and 1290) has improved dark tones
Re: [Gimp-developer] CVS - core/gimpdrawable.[ch] missing?
On Tuesday 23 September 2003 10:03 pm, Simon Budig wrote: Simply cvs update your local tree again. A broken pipe can happen and is nothing to worry about. We can do nothing about that. No, I meant that the broken pipe happened during the _commit_, and that core/ gimpdrawable.h and .c are completely missing from the repository. If you are using anonymous cvs, consider using anoncvs3.gnome.org, since this apparently is the most stable one. Also hardcoding an anoncvs-server is a good idea, since they might get out of sync and you'll end up with a broken tree. Ahhh... I'm using anonymous cvs via anoncvs.gimp.org. I guess that repository is a mirror. I'll change over to use anoncvs3.gnome.org instead - thanks for the tip! Anyway, anoncvs.gimp.org is still missing those files. I don't know how it's all set up, but it's probably worth someone fixing it, as the instructions on gimp.org refer to that repository. Hope this helps, Simon Yep, thanks! Ben. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
