Re: [Gimp-developer] Kudos to The GIMP Developers!
On Thu, Sep 25, 2003 at 06:18:44PM +, Tor Lillqvist wrote: You're right. If you could tell me such a program... I would have used it. The nearest approximation was xfractint but it's cumbersome to use and doesn't have a gradient editor (and I'm not sure whether it's capable of rendering 2x14000 pixel images). ;-) Wouldn't it then be quicker to render the fractal in smaller pieces in GIMP, output as ppm files, and the just slap the pieces together with pnmcat and convert to PS with pnmtops? I wasn't aware of pnmcat. Apart from that, it's a bit difficult to render fractal tiles with FractalExplorer... And I'm a bit afraid of rounding errors at the edges... it depends on how FractalExplorer handles them - does it render [xmin,xmax] or [xmin,xmax)? Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Update on pre-release schedule
Hi all, As any of you who have been following CVS know, we have been working towards a 2.0 pre1 release for the end of this month, and there are now very few blockers to that release left. However, there are more blockers than are going to be done in the next week. So we're going to have another release (1.3.21). This should come out sometime during the next week. And the 2.0 pre1 release will be pushed back about 2 weeks, to (give or take) the 15th of October. Just to keep ye up to date, the list of blockers for the 2.0 release (which is mostly a filled out list of the things mentioned at camp), and their current status, is below. Blockers for 2.0 prereleases: - Path tool: 1) moving of strokes/paths,*DONE* 2) being able to connect two strokes, *DONE* 3) dragging on curve segments, *DONE* 4) libart stroking,Mostly done 5) im/export into files. *DONE* Text tool features missing: 1) GUI for text boxes Back-end done 2) Implementation of text transforms 3) Font list/selector improvements 4) Text outlineNot a blocker Help browser features missing: 1) Symbolic references for every core function *DONE* 2) Mechanism for cross-referencing with 3rd party *DONE* documentation 3) Registering of documentation files with the core *DONE* at startup, with references. libgimp API changes missing: 1) libgck must die *RESOLVED* 2) Thumbnail API exposedNeary done 3) libgimpmisc API changes 4) gimp_dialog_new () 5) 64 bit clean libgimp All in all, on that list there are 2 or 3 worrying things that might not be done in 2 weeks time, but most of them look like they will be done by then. We do need to clean up Bugzilla a little again. There are now 75 bugs with milestone --, it would be nice to get these sorted to the right place before we hit pre-releases. http://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=NEEDINFObug_status=REOPENEDtarget_milestone=---cmdtype=doitorder=%27Importance%27form_name=query There are also 159 bugs open against the 2.0 release (milestone 1.3.x or 2.0). We need to start reducing this number now. So if you have a little spare time, please have a look at these bug reports, either to help close them or to reduce the amount of time needed to fix them. http://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=NEEDINFObug_status=REOPENEDtarget_milestone=1.3.xtarget_milestone=2.0cmdtype=doitorder=%27Importance%27form_name=query Thanks for your time, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: 2.2 features. was: Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: Well, I have never enve looked at Pango. You will not get around it, see below. My idea would be to get the text chars and attributtes from the GIMP, generate a image without the text only layers with no other layers above it, and hand code the PS code necessary to write a similar layer with the same font and coordinates. To embbed the font, I then would run GS with pdfwrite on a temporary PS. I don't think it will be acceptable to write a similar layer. The PDF text layer will have to identical to what you see on screen. Tiny differences might be acceptable but you definitely want to apply the same font mapping, glyph substitution, line-breaking and bidi algorithms as the text tool. That's why you won't get around using Pango for the text layout. If Pango thinks about providing the pdf layers itself, them I will probably check what it does, and does need improvement. I was talking about a third-party Pango extension. It's not part of the standard Pango package. There are 4 things on this list: 1) The Custom Layer Combination Mode This will record a plain ASCII parasite with a mathematical c-like expression on how to combine pixels from this layer with the one bellow. (And with themselves, like dissolve mode). If not for the flexibility, this mode will avoid cluttering the UI each time one finds a fine-tune to the add mode, as is the Grain merge. I don't see how this would avoid UI cluttering. You don't expect people who want to use an effect like Grain Merge to enter the mathematical formula manually, do you? 2) Improve the postscript export (and maybe import) filter: - Easy: save indexed images as indeed indexed. They are saved as full RGB currently - Save text layers as text - Save multiple layers as multiple pages, with some meta-information - Change import filter to erad multiple page into multiple layers as an option. Use meta-info from above for offsets, and combination modes. 3 and 4 would be just plugins. (2) would be plug-in only as well, no? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Mailing list archive out of date
On Thu, Sep 25, 2003 at 06:22:49PM +0200, Guillermo S. Romero / Familia Romero wrote: b) not searchable (ht://dig error: Unable to read configuration file) Probably related to a, meanwhile try 'site:lists.xcf.berkeley.edu gimp term1 term2 ... termN' in Google. ... which doesn't help if the archive is out of date and you're looking for pretty actual stuff. :-( Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: 2.2 features. was: Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
On Friday 26 September 2003 7:19 am, Sven Neumann wrote: Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: Well, I have never enve looked at Pango. You will not get around it, see below. My idea would be to get the text chars and attributtes from the GIMP, generate a image without the text only layers with no other layers above it, and hand code the PS code necessary to write a similar layer with the same font and coordinates. To embbed the font, I then would run GS with pdfwrite on a temporary PS. I don't think it will be acceptable to write a similar layer. The PDF text layer will have to identical to what you see on screen. Tiny differences might be acceptable but you definitely want to apply the same font mapping, glyph substitution, line-breaking and bidi algorithms as the text tool. That's why you won't get around using Pango for the text layout. If Pango thinks about providing the pdf layers itself, them I will probably check what it does, and does need improvement. I was talking about a third-party Pango extension. It's not part of the standard Pango package. There are 4 things on this list: 1) The Custom Layer Combination Mode This will record a plain ASCII parasite with a mathematical c-like expression on how to combine pixels from this layer with the one bellow. (And with themselves, like dissolve mode). If not for the flexibility, this mode will avoid cluttering the UI each time one finds a fine-tune to the add mode, as is the Grain merge. I don't see how this would avoid UI cluttering. You don't expect people who want to use an effect like Grain Merge to enter the mathematical formula manually, do you? No, I think of having a bunch of pre-loaded formulas as gimp resources (Plain ASCII in a .gimp-2.2/layer_modes/ ). And them, if someone wants to fine tune any of them he will just type his values there. 2) Improve the postscript export (and maybe import) filter: - Easy: save indexed images as indeed indexed. They are saved as full RGB currently - Save text layers as text - Save multiple layers as multiple pages, with some meta-information - Change import filter to erad multiple page into multiple layers as an option. Use meta-info from above for offsets, and combination modes. 3 and 4 would be just plugins. (2) would be plug-in only as well, no? Well yes...sorry, is that this one would come with the GIMP, the others might or not get in. Sven JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut
David Neary [EMAIL PROTECTED] writes: Marc A. Lehmann wrote: On Wed, Sep 24, 2003 at 11:39:44PM +0200, David Neary [EMAIL PROTECTED] wrote: 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. Others do it is never an argument, though. It's an argument, just not a very good one (on its own). Others do it, because it's been shown to be the best way would be a decent argument, for example (I'm not arguing this). In the current situation, I think it's reasonable to fit in with what others do in the general case, which dynamic shortcuts provide a way to revert to the old behaviour. When the others are everyone using a Mac, plus people who come to the GIMP from KDE or GNOME applications, and PhotoShop users, I think the benefits of a familiar keybinding are self-evident. Is familiarity an argument when what's familiar is *way* less comfortable than the less-familiar but better shortcut? IMHO needing shift to toggle between undo and redo is an absolute usability desaster. The reasons have been said earlier in this thread: repetitive undo/redo is a a common operation in graphics applications, unlike e.g. text editors. I completely follow the rationale of consistency but IMHO usability overweights it. If you like, I'm arguing populism here. More people use Ctrl-Shift-Z as redu than Ctrl-R. Therefore, until there is a very good reason to change, we should do the same. In addition, a considerable body of usability work reccommends this keymapping. Yes, and more applications are text editors or word processors or similar things where this absolutely makes sense. Is it our fault that the HIG guys only have GEdit in mind when they write down stuff? And btw, a considerable percentage of mails in this thread voted for ctrl+R, does this count less than questionable consistency? What you need are arguments in favour of Ctrl-Shift-Z, and the only ones that there are is the HIG and other platforms use it, so people are probably used to it, making it easier for them to switch. Yes, that's about it. It's also that current GIMP users probably benefit from having the same keybindings everywhere. There's nothing that annoys me more than using emacs, getting back into the emacs keybindings, and then using vim, and freezing the terminal with C-x C-s. Of course, this is not like with like. But I imagine that people who use both the gimp and photoshop have dozens of little annoyances like these. I guess people will rather find it annoying to do complicated shift trick using three instead of two fingers. Have you ever looked what photoshop *really* does when pressing the undo shortcut several times? Following them when it comes to undo key bindings is the worst we could do... That is one aspect of usability. It doesn't have much to do with ergonomics, and as others already have said, Ctrl-R/Ctrl-Z is much more ergonomical than three-key-combinations. I think two keys vs. three keys is extremely obvious, too. So ergonomics is might have been considered, but it was certainly _dismissed_, as other, much more ergonomic combinations, are available. You have a point here. I think that what was chosen was the consistency of Shift as negation. I think that's probably a goal we could work towards. It certainly makes a lot of logical sense. But then, so does having + to zoom in instead of =, and look how many bug reports that's got us :) And the usability people have considerably more experience with this than either of us :) usable != ergonomic, though. Fair enough. And I think that gimp users have considerable more experience with using gimp than the usability people. If the GIMP were the only graphics application choosing this keybinding I would agree. I guess that when in doubt, following the crowd is a fairly safe bet (note this leaves open the possibility of not following the crowd when not in doubt ;). I don't know about others' doubts, but I have no doubt that we should keep ctrl+R, since we are not talking about feature xy of application xy (how often do you use undo in your word processor), but we talk about the most-used shortcuts in the GIMP. Making them less accessible is no option IMHO. ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-web] new web project
[Note: I am adding the gimp-developer list to the CC:. For those who missed the context of this thread and might be puzzled by some of the statements quoted below, the quick summary is that it started with Carol telling Niklas that he was fired from the gimp-web team. Also, the subject new web project came from Carol's announcement about a new project for a gimp web site. All this discussion should be available from the gimp-web archives when the list archives are resurrected. Niklas' message, to which I am replying below, is a followup to a request for a README file in the gimp-web CVS module.] On Fri, 26 Sep 2003 14:10:23 +0200, Niklas Mattisson [EMAIL PROTECTED] wrote: Yes I did write that http://information.gimp.kicks-ass.org/ and it is still online however like I said before in a mail, I am not in the gimp-web team anymore instead I have joined the gimp-help team for the User Docs and I have been looking at the wiki a lot now to try to help them with this. Sorry but I can't work with a team that does not work as a team. I understand your frustration. But as you have seen in the replies to your previous message with the subject Not quitting but fired, Carol had no authority to fire you. I hope that you will come back and help with the web site. Enough about that discussion. Now I make a README that would use this information and put it in the module. However this could be done even though the site moves. My question is: Why the site is not moved yet? I don't know. Several people worked hard in the last days to update the new site and fix all the broken links, especially after the request from Mitch to do it now. On Tuesday, I posted the status update saying that the site was ready. I thought it would have been moved last weekend or at least this week. Is there anything holding it back? Yosh said he was to tired to do admin thingys last Sunday and this I can understand a lot. Is there anything important that is holding the site back? I am a bit confused now, that's why I am cross-posting this to the gimp-developer list because some of the developers may have some clues about what is happening (I hope). I suppose that Yosh is simply too busy. I can understand that: I had a hellish week at work and I did not sleep much in the last days. If Yosh is in a similar situation, I understand that he does not have much spare time for moving the site. There could also be some other problems, such as lack of disk space for the move (one disk was full on wilber a few days ago) or some problems moving some user accounts. Another theory (please take your tinfoil hat) would be that the move has been blocked because some of those who worked on it some time ago do not want it to move anymore and have requested that the move does not take place. I don't know if there is any truth in that, but I was a bit worried by Carol asking how the gimp-web module could be removed from cvs and saying: mmmaybe will never move. it will never be wgo. play with it all you want, it is not worth the three hours it will take to move it. It is difficult for me to imagine a team of gimp-web contributors lobbying for their own work to be forgotten, but maybe this is happening and all these secret discussions are taking place outside the list? Who knows? ;-) Seriously, I hope that this is not happening. A lot of good work has been put in this site by all those who contributed to it (including Helvetix, scizzo, Carol, Bex, drc, brix, Branko and others) and it would be a shame to sabotage all that. Or are people working on getting it moved? I am still hoping... If it is simply a question of lack of time, then it will hopefully move during the next few days. If not, then I would like to know if there is any other reason that would prevent the switch from taking place. From my point of view (as gimp-web coordinator), the site is ready to be moved. There are some parts that still need some work (various FIXMEs) but they can be fixed later. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut
On Fri, 26 Sep 2003 15:22:05 +0200, Michael Natterer [EMAIL PROTECTED] wrote: David Neary [EMAIL PROTECTED] writes: In the current situation, I think it's reasonable to fit in with what others do in the general case, which dynamic shortcuts provide a way to revert to the old behaviour. When the others are everyone using a Mac, plus people who come to the GIMP from KDE or GNOME applications, and PhotoShop users, I think the benefits of a familiar keybinding are self-evident. Is familiarity an argument when what's familiar is *way* less comfortable than the less-familiar but better shortcut? IMHO, yes. It does not matter how awkard a keybinding is - if you cannot remember it, you might as well not use it. If those who do not use the GIMP frequently can remember the Redo shortcut easily, then it will be easier for them to use the program. And anyone who use the shortcut frequently (all experienced GIMP users do) can bind it to some other key, such as Ctrl-Y, Ctrl-R or anything else. IMHO needing shift to toggle between undo and redo is an absolute usability desaster. The reasons have been said earlier in this thread: repetitive undo/redo is a a common operation in graphics applications, unlike e.g. text editors. I completely follow the rationale of consistency but IMHO usability overweights it. I agree with your arguments, but disagree with the conclusion. ;-) [...] And btw, a considerable percentage of mails in this thread voted for ctrl+R, does this count less than questionable consistency? How many of these mails have been written by the 99% of the users who do not use the GIMP more than once per week (or month)? Yes, I am teasing you. ;-) [... big snip ...] I don't know about others' doubts, but I have no doubt that we should keep ctrl+R, since we are not talking about feature xy of application xy (how often do you use undo in your word processor), but we talk about the most-used shortcuts in the GIMP. Making them less accessible is no option IMHO. If your main argument is that we should not have more than one modifier for Redo because it is used frequently (I agree with that, but I think that we should let the users rebind this _if they really need it_), then we should not use Ctrl-R. We could use Ctrl-Y, because there is a chance that it would be consistent with some other programs. But we should not keep Ctrl-R if all other applications have chosen different shortcuts. Historical reasons are not valid because otherwise we would never be able to improve the user interface. So the choice should be between Ctrl-Shift-Z and Ctrl-Y. I prefer the former, for the reasons that I have stated in another message. I could live with the latter, but please do not bring back the old Ctrl-R. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-web] new web project
On 26 Sep 2003, at 18:34, Raphaël Quinet wrote: [Note: I am adding the gimp-developer list to the CC:. For those who missed the context of this thread and might be puzzled by some of the statements quoted below, the quick summary is that it started with Carol telling Niklas that he was fired from the gimp-web team. Also, the subject new web project came from Carol's announcement about a new project for a gimp web site. All this discussion should be available from the gimp-web archives when the list archives are resurrected. Niklas' message, to which I am replying below, is a followup to a request for a README file in the gimp-web CVS module.] [snip Raphael's reply] I was going to reply in almost the exact same way, but Raphael beat me to it. So basically this is a 'me too'. The difference would have been that I would have cc'ed Yosh, rather than the developers' list. :-) Yosh, are you subscribed to gimp-web? Maybe you should be during the transition period. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Mailing list archive out of date
On Thu, Sep 25, 2003 at 09:23:40PM +0100, Alan Horkan wrote: Hi there, I just tried to figure out where to get Windows binaries for 1.3.=19 and couldn't find any. So I tried to search the archives. The archive is a) out of date (last message from July 26) There is another archive for the developer list here http://www.mail-archive.com/[EMAIL PROTECTED]/maillist.html There is a windows gimp users list at yahoo and they also have a list archive there too and I know that Tor (aka tml) announced binaries of 1.3.20 for testing there last week. Links, anyone? ...head-20030901 might be recent enough though... BTW: I can't use yahoo since you need cookies to view any message and I'm not allowed to use cookies here (apart from that, I don't see a reason, argh!). Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut
From: Tom Mraz [EMAIL PROTECTED] To: Gimp Developer List [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Redo shortcut Date: Thu, 25 Sep 2003 20:18:18 +0200 MIME-Version: 1.0 Received: from lists.XCF.Berkeley.EDU ([128.32.112.242]) by mc11-f15.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 25 Sep 2003 11:35:45 -0700 Received: from lists.XCF.Berkeley.EDU (unknown [127.0.0.1])by lists.XCF.Berkeley.EDU (Postfix) with ESMTPid 5BEDC103B1; Thu, 25 Sep 2003 11:45:30 -0700 (PDT) Received: from penguin.kabelta.cz (unknown [212.11.121.19])by lists.XCF.Berkeley.EDU (Postfix) with SMTP id 46757102CCfor [EMAIL PROTECTED];Thu, 25 Sep 2003 11:32:14 -0700 (PDT) Received: (qmail 1784 invoked from network); 25 Sep 2003 18:18:18 - Received: from localhost (HELO centrum.cz) (127.0.0.1) by localhost with SMTP; 25 Sep 2003 18:18:18 - X-Message-Info: yilqo4+6kc43tBKQfUgFUHBFfx51X4Ib Delivered-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807 X-Accept-Language: cs, en-us, eo References: [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.1b4 Precedence: list List-Id: gimp-developer.lists.xcf.berkeley.edu List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer,mailto:[EMAIL PROTECTED] List-Unsubscribe: http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer,mailto:[EMAIL PROTECTED] List-Archive: /lists/gimp-developer List-Help: mailto:[EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 25 Sep 2003 18:35:46.0183 (UTC) FILETIME=[D57F5970:01C38393] I believe we could hard-code two keybindings to work as the default, couldn't we? Technically possible, but extremely horrible, since the user has to be educated about it. And since the only argument in favour of the less ergonomic C-S-Z is easier to learn, that sounds even worse than leaving it at C-R. I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z. Then if you move from photoshop or HIGified Gnome apps, it will work for you. But the (IMHO) much more ergonomic C-R stays as the default for newbies. As it was said earlier the ergonomics of Redo operation in for example text editor is less important as you don't use it so often and you don't switch between Undo and Redo very fast and frequently. Tom Mraz sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible). just out of interest, what on earth made the GNOME HIG people think that SH+CT+Z was a good combo for anything? and is there a good reason (HIG rules wise) for not allowing use of CT+R? it's not like there's a refresh of reload funciton in GIMP(although it could be handy, i still wouldn't want it attached to CT+R) you've got to remember that from a Photo$hop perspective undo and redo are unimportant, everything's done with history, and undo is normally only one level(that's how i remember those horrible experiences anyway) or is it Ct+Z becomes Redo once you've undone once, either way, it's deeply unpleasant and i don't want to talk about it :P Phil. _ Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-web] new web project
On Fri, 26 Sep 2003 21:06:45 +0200, Branko Collin [EMAIL PROTECTED] wrote: I was going to reply in almost the exact same way, but Raphael beat me to it. So basically this is a 'me too'. The difference would have been that I would have cc'ed Yosh, rather than the developers' list. :-) Hmmm... Yes. But after reading the comments in bug #121299, I saw that several other developers were interested in what was happening to the web site. Since I do not know exactly who is subscribed to the gimp-web list, I thought that the developer's list was the easiest (although indirect) way to check if they had heard of something that I had not. Anyway, I am replying because I forgot to add a little note in my previous message: I spent a large share of my spare time in the last days fixing the new web site because I thought that it would move now. It was ready on Monday, and I posted a message on Tuesday giving a summary of the recent changes and saying that it was ready. I haven't done much on the site since then because I thought that it could be moved at any time and I didn't want to break anything during the move. Seeing it go live would help me to re-motivate myself to fix the remaining issues. I am not saying that I will not do anything until the site is launched (that would be stupid), but I would be more motivated to work on it if I knew that the work is not done in vain. I suppose that I am not alone with that opinion and those who have contributed to the web site (and the GIMP itself) have probably experienced the same feelings at various points in time. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Redo shortcut
[EMAIL PROTECTED] (2003-09-26 at 1933.11 +): I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z. sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible). Grouped undo, or call undo history, ie. Hardcoding would be more problem than harm, btw. just out of interest, what on earth made the GNOME HIG people think that SH+CT+Z was a good combo for anything? and is there a good reason (HIG rules wise) for not allowing use of CT+R? it's not like there's a refresh of reload funciton in GIMP(although it could be handy, i still wouldn't want it attached to CT+R) Probably a mix of related to undo with used in other places reasonings. If you want a real answer, ask them. They did not have any problem about changing button order from the most used one (important button on left side, for LTR languages) to the easier to use one (imporant on right side), OTOH, so logic behind when to change and when not is fuzzy for me. And they proposed shortcuts seem to be text editor / browser oriented, while other kinds of apps seems to be ignored. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on pre-release schedule
Date: Fri, 26 Sep 2003 09:17:56 +0200 From: David Neary [EMAIL PROTECTED] As any of you who have been following CVS know, we have been working towards a 2.0 pre1 release for the end of this month, and there are now very few blockers to that release left. However, there are more blockers than are going to be done in the next week. So we're going to have another release (1.3.21). This should come out sometime during the next week. And the 2.0 pre1 release will be pushed back about 2 weeks, to (give or take) the 15th of October. Is anyone interested in writing a replacement Print plugin, preferably on top of Gimp-Print 4.3, which is basically going alpha (it's still officially development, but that's because of an OS X stopper not related to the GIMP)? A 4.2 plugin would also be of use, but it's getting about time to move people to 4.3. Currently (in the Gimp-Print source), the Print plugin is divided into two components, libgimpprintui (which is a GTK1-based GUI library) and the Print plugin itself (which contains all of the GIMP interface code). It should be possible to rewrite the libgimpprintui library by itself with minimal (hopefully no) changes to the plugin. I'm not much of a UI programmer (which is why the plugin UI is such a mess), and this is really something I'd rather farm out to someone else. I'd like to keep ownership of libgimpprintui within Gimp-Print at least for now, until the API is completely locked down for the next release. I'm certainly willing to maintain the interface into libgimpprint (the Gimp-Print core) against any Gimp-Print API changes that may happen until 4.4 or 5.0 (whichever we decide to name the next stable release). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Redo shortcut
Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2003-09-26 at 1933.11 +): I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z. sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible). Grouped undo, or call undo history, ie. Hardcoding would be more problem than help, btw. I meant to hardcode it in such a way, that it could be reassigned by user keybinding preference to other function. Not that I think it's probable that anyone would reassign it to anything. Tom Mraz ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [Fwd: [Gimp-web] gimp-1.2]
---BeginMessage--- this gimp was released on December 24 or 25, 2000. can you stop already talking about the web site. carol ___ Gimp-web mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-web ---End Message---
[Gimp-developer] Re: [Gimp-user] Noise reduction
Steve Crane wrote: Hi, Are there any built-in functions or scripts for the GIMP that can be used to remove or reduce noise in digital photographs? Does anyone have a set of steps to follow to remove noise? There are several stand-alone programs available for Windows that do this but I haven't found any for Linux yet. Anyone know of any? Thanks. It depends on what kind of noise you are looking at. Can you describe the noise more precisely? Is it salt and pepper noise? Gaussian noise? If you can show an example image I can help you pick a filter. If you just want to use a sledgehammer, you can just use a blur filter, which will reduce many kinds of noise, though you can almost always do better. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Gimp printing UI - was Re: [Gimp-developer] Update on pre-release schedule
I don´t know who will be doing it, but it was not until this week that I noted taht there is no way of printing more than one coppy at once with the print GUI. Not in 1.2.5 at last (at work is what I use. At home, I have no wrking printer at the moment) And also, if it cannot be made possible to spread a image over several pages and tile the results, as that would be too much change, the possibility of making the printable image larger than the printer printable area, and trimming the print would be a nice thing for me at last. Regards, JS -- On Friday 26 September 2003 5:54 pm, Robert L Krawitz wrote: Date: Fri, 26 Sep 2003 09:17:56 +0200 From: David Neary [EMAIL PROTECTED] As any of you who have been following CVS know, we have been working towards a 2.0 pre1 release for the end of this month, and there are now very few blockers to that release left. However, there are more blockers than are going to be done in the next week. So we're going to have another release (1.3.21). This should come out sometime during the next week. And the 2.0 pre1 release will be pushed back about 2 weeks, to (give or take) the 15th of October. Is anyone interested in writing a replacement Print plugin, preferably on top of Gimp-Print 4.3, which is basically going alpha (it's still officially development, but that's because of an OS X stopper not related to the GIMP)? A 4.2 plugin would also be of use, but it's getting about time to move people to 4.3. Currently (in the Gimp-Print source), the Print plugin is divided into two components, libgimpprintui (which is a GTK1-based GUI library) and the Print plugin itself (which contains all of the GIMP interface code). It should be possible to rewrite the libgimpprintui library by itself with minimal (hopefully no) changes to the plugin. I'm not much of a UI programmer (which is why the plugin UI is such a mess), and this is really something I'd rather farm out to someone else. I'd like to keep ownership of libgimpprintui within Gimp-Print at least for now, until the API is completely locked down for the next release. I'm certainly willing to maintain the interface into libgimpprint (the Gimp-Print core) against any Gimp-Print API changes that may happen until 4.4 or 5.0 (whichever we decide to name the next stable release). -- Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
