[Gimp-developer] running gimp withou't make install?
Hi there, I recently uploaded teh 1.3.14 source code, to start to look around the code. Actually, I humbly intend to actvely join GIMP's development along the next couple of months, if I can get enough of what is going on. ./configure, make make install went as smoothly as one could ever dream, in a shinny install of MDK 9.1 - Congratulations to whoever manage this part. And them, I just started to hack around the code to take a grasp of how things itnerconnect around there. My intent almost worked out at first try (well, sometimes we might be able to say that a seg fault is ok as 'almost worked out', might not? ). But what I do need now is a faster way to go from edit code to running gimp. Make Install asctually eats out a lot of time on my system. Is it possible to run the gimp-1.3 binary generated from make straight, without make-installing it? How can it be done? And about my hack: I am trying with a xor layer combine and brush modes. I jsut based my work on the multiply mode, and worked on a copy of pixel_multiply in app/paint-funcs/paint-funcs-generic.h , and the related enuns in various other files. It seens like I am missing something yet - I will work on it tonight. The final effect is just too like the difference layer combine mode to be of any interest, I think, But if it get's interesting enough, I will mention it again. Thanks for all help. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] What happened to the deceased features?
I am taking a deeper look at the GIMP manual (even when you are messing with the source itself, the GIMP is so full of surprises, they neve stop showing up) And I noted some features on that manual (which is mostly from GIMP 1.0 times, I believe) that are missing on the current program. Such features are marked with an (X) inside a triangle in the manual. What is of them? Where they ever implemented? Have they been removed from 1.2? Examples are the newsprint artistic filter, and a whole transform menu for layers. Thank you again, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images
I was thinking abiut the subject , and came to a way of doing it - if PDB calls can be made normaly from inside these plugins - which I assume thay can, without problens. Therefore, if you will allow me, I will describe what I was thinking in gimp pseudocode. Someone more familiar to the core than I could tell me if there is a fundamentla flaw. If it allright, than I think it could be implemented in less than a couple of weeks: In summary before for performing a preview in such filters, this could be done: 1 - Test from viewing window and scale, and from memory avaliability, if it's worth to use these optimizations. 2 - Create a new image - new drawable if we are working in a single layer image, or top visible layer in normal mode. 3 - If the current selection is larger than the viewable area store it somewere, and intersect it with the viewable area 4 - if the image is zoomed out copy all visible layers to the new image created, and scale it down in linear mode, in a manner that each pixel in it is equivalent to a pixel on the screen at the subject image. 5 - perform the filter action ont he corresponding layer on the new image. 6 - copy visible the new image 7 - create a new temporary drawable on top of all visible layers on the subject image 8 - paste draft image visible contentes on new drawable, position and scale it accordingly. 9 - repeat 5,6 and 8 until the filter is commited or cancelled 10 - restore selection, delete temporary layer and temporary images 11 - commit changes. What do you think about it? Of what I've seen on the code, it seens that each such filter does it's own changes on the images. They all would have to be individually modified to use the steps above. Still doesn't seen hard: a - if filter is in preview mode, calls a procedure that makes steps 1 - 4 above, and return a new drawable. b - perform filter action on drawablem and call a procedure that will perform 5, 6,7 (once) and 8 above. c - on ok or cancel, call something to make 10, and perform 11 Feczak Szabolcs wrote: Feczak Szabolcs [EMAIL PROTECTED] writes: Changing the color balance/brightens-contrast/ color curves are significantly slower in gimp vs. photoshop on the same machine. The problem is not the processing time alone, but the preview takes the same amount of time as the final processing. I have relized, that gimp calculates all the data in preview mode as I would have pressed the ok button. Very well spotted. Other good idea came from my friend: creating a smaller image in memory, which has the resolution of the screen and calculating the preview on that image. That is obviously the approach that should be taken. AFAIK, there are no plans to do such an improvement. Considered that we still lack some funding for our developers conference this summer, perhaps we could be persuaded to give it a try. Ok, what do you need to be more persuaded ? JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] makes it sense to add native CMYK support toGIMP?
Hi, On Sunday 08 June 2003 06:13, Stefan Klein wrote: Hi all, I am a computer science student looking for a final year project. I'd love to do something in the Open Source community and I am looking around where my help might be needed. Having a little interest in graphics design and prepress, I came across GIMP and CMYK support. The little research I've done gives me the impression that over the last couple of years it's regularly been asked for and it might be an important feature to get GIMP into the pre-press world. Men, would that be great. I just joined this list about a week ago, trying exactly to check this issue: a native CMYK model. However, taking a look at the code, I just thought it was too much for me, and was waiting for this subject to pop up on the list. As Sven had pointed out, it seens that such profound changes will have to wait gimp 2.0, and a re-writng of the core. It, however, have to be done, and its about time to start with it. In the meantime, one of the things I am planning is developping a paliative plugin, that will separate the CMYK in different layers - or channels -. Such a Plugin could work from gimp 1.2 already, and has no need to make it in the official GIMP, while it waits for a true CMYK support - but could however make the GIMP more usable for pre-press. Currently there is a image-mode-split to cmyk option, that however keep the colors addictive. Printing them requisres an aditional inverting in each channel. BTW, the plugin wihich I talk above could be as simple as calling this, and automatting the inversion. Adding some crop and register marks seen not to be hard, via plugin and PDB as well. For crop and register marks, however, the thing could be a little morre permanent than the color separation plugin, and would be a serious candidate to get to the oficial release. I know very little of color separation theory by bnow, but it seens me that this separation ma ynotbe accurate. The newsprint filter (filters-distorts-newsprint) can make the separation as well, with an extra degree of control. All in all Stephan, I am wiling to work along with you on this issue, even if I can be of little help. And...Sven.. maybe there would be time to add a provisorie(sp?) CMYK to the Color Curves tool only before the release? What would you say? Thanks, JS -- What I'd like to know is the following: 1. Is anybody actually working on this? There were hints now and then that people are thinking about it, but I didn't find anything definite, apart from an entry Additional ColorModels on the GEGL todo list (http://developer.gimp.org/gegl-todo.html) that seems to point in that direction. 2. How important is this really? What I am talking about is native CMYK support, not just a conversion function. There was a thread on the developers-list in November 2001 (http://www.mail-archive.com/[EMAIL PROTECTED]/ msg01350. html) that gives the impression that it might not be all that important and that there might be cheaper workarounds (converting when saving, spot color channels). How important is a CMYK mode for people working in prepress? 3. Any guesses on the effort to implement this? I'd appreciate it if you could answer asap, since I have to hand in my project proposals very shortly. Thanks Stefan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Adding feature - user defined layer combination
Hi again! I wrote yesterday that I was writting a XOR layer combine mode. Well, today it just working fine. While it does have it's interesting applications, I think that including it as a default layer combine/paint mode would bloat the User Interface, as undoubtley, there are lots of other creative specific layer combination effects that could be written. On the other hand, adding a new layer combine/paint mode gives possibilities to the final user that are not, afaik, feasible with ordinary pos-compile plugins, as with new layer modes there comes completely new brushes and effects. So, it ocurred to me that with something more elaborated than what I did, there could be implemented a custom layer combine mode. Them, one custom option would be added in the layer mode/paint options,a nd the actual pixel operations for this would be defined in a dialog box somewhere else, maybe even as a plugin. Therefore, one could, for instance,ina single work use a combine 50% blue as green mode, and on his next image, the artist could make an add red to alpha combine mode. The differene is that the option is up to the user, and there will be no need for him to patch the Gimp to get the desired effects. So, I would like to know if you think this could be an itneresting feature. What could and could not be done here. If we get to an interesting final idea here, I think I can write, with ocasional questions to you, the necessary code to make it work. Thank you for the support, JS -- ___ 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 Tuesday 17 June 2003 18:51, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: where are the programmable layer effects? Hmm..are these the ones I did suggest I could do a couple of weeks ago? I am working on them...unless the freeze is quite soon, It may very well go into 1.4/2.0 . Although in 1.4.1/2.1 they will be quite more usable. -- 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
Programable layer modes - was Re: [Gimp-developer] useless plead forhonest evrsion numbers :)
On Wednesday 18 June 2003 00:25, Joao S. O. Bueno wrote: On Tuesday 17 June 2003 18:51, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: where are the programmable layer effects? Hmm..are these the ones I did suggest I could do a couple of weeks ago? I am working on them...unless the freeze is quite soon, It may very well go into 1.4/2.0 . Although in 1.4.1/2.1 they will be quite more usable. Oh well. spent the best part of the last houe reading about the GEGL, which I did not know this far. Certainly people HAD tought of programable layer modes before I mentioned it. :-) . But it doesn'seen to be in GEGL either, altought it is quite apropriate for it. I will go on with my work (quite on early stages) on them using the 1.3 codebase, but with an eye in GEGL - If anyone besides me like what I am doing, it wont'be hard to be added to the GEGL core. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A new filter idea..
On Thursday 19 June 2003 06:05, Bowie J. Poag wrote: Is this the right forum to discuss new filter ideas? If so, I have one i'd like to share. Maybe... But might be gimp-user, or [EMAIL PROTECTED] Just send the idea at once. :-) Cheers, Bowie ___ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New thread on GIMP 1.3+
On Friday 20 June 2003 07:10, Marco Wessel wrote: On 20 Jun 2003, Daniel Egger wrote: Am Don, 2003-06-19 um 21.44 schrieb David Neary: I'll get the ball rolling: 2.0 I wil stay with 1.4 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tile cache default
On Sunday 22 June 2003 06:55, Sven Neumann wrote: Hi, David Neary [EMAIL PROTECTED] writes: The current default tile cache size is 32M. I would like to suggest 128M as a more reasonable default value for 1.3 CVS. Are there any objections? Yes. 128M sounds unreasonably large. I think we can assume that most users have 128MB RAM nowadays but it would be wrong to assume that a large part of users work with 256MB RAM. If we want to change this default, I'd say we go for 64MB. Dito. I would see 64Mb as a reasonable amount as well. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GAP Filters
Hello ... Where have teh GAP filters gone in the 1.3.x tree? I've found them in the plug-ins-gap in the 1.2.x, and I am intending to modify the filter all layers, to do aply another filter with variable parameters based on the Value information of a mapping drawable. Easy to do, and powerfull enough to make a lot of cool effects. Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestions + Patch, Redo - Part 1
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: 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. BTW, an area in which GIMP just TOTALLY SMASHES OUT Corel Photo Paint 9 - the stuff I had to use before managing to swtch at work. In that crappy program, the Undo history is erasen after a couple of seconds of idle activity, sometimes randomly. Which means one can never be SHURE if the changes of a filter will possibly be undoable. Also, that crappy program will erase the undo history after File Save actions. That turns very difficult to save a version of an image with a filter applied, and them go back to working on the image without that filter. Anyway, I will have no say on what Key I'd prefer for the GIMP Undo at this time. Both CTRL + R and Shift + Ctrl + Z have good arguments. Just please, do keep Ctrl + Alt + Z out of question, it is hard to reach and ALT do indeed have some issues in the KDE enviromment. And, anyway, one of the first things I teach to one who is learning the GIMP is the dinamic shortcut allocation. Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestions + Patch, Redo - Part 1
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: 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. Agreeded. 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. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the user installer
Sven Neumann wrote: I would agree with you if we would force the user to calibrate her monitor. But please note that you can go thru the full user installation process by hitting the default button 5 times. Now compare this to the installer of whatever windows software. It's just silly to say that the GIMP user installation would be overly complex or annoying. Seven said it all here. The one important fact for clueless users is that the install works by clicking on the default button. I find myself quite oftenly cliking them, when I run the GIMP from a CD-ROM linux distro, like Knoppix, for demonstration purposes, and even them it's not a burdden. One can go through them while saying And here I will show you why you won't miss your pirate copy of Photoshop Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ 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, Vol10, Issue 18]
Christopher W. Curtis wrote: The downside to using 'ar', really, is that WinZip doesn't support it. I haven't verified this - I hope a Windows user can do so for us. Just for reference, attached below is a CP of an ar archive I just made: Hmm..that just seens just plain as no downside at all. You see..windows users don't even have a comom tool to edit large ASCII files. Saying that a proprietary tool doesn't support this archive type should be of no concern. They will be able to open the New Gimp File based on ar on Microsoft Word, if there is such a need of a format hackeable by windows users. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gradient dithering
I tried the patch. It worked just fine, and IMHO should be used as a fix to the aforementioned bug. I tried to aply adptive supersampling with maximum depth, to compare the effects with the ones from the patch: I had to kill out gimp after 20 minutes of 90% CPU use and no response. Austin Donnelly wrote: Conceptually I like this, and the gotchas are toggleable via the UI. I like the idea too. It should be checked in and turned on by default. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ 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 Friday 18 July 2003 16:59, Sven Neumann wrote: Hi, I'd like to inform you about our plans for the GIMP 2.0 release. (...) Originally we wanted to get GIMP 2.0 out at GimpCon. Since that is actually in three weeks, we will definitely not make it but I am still optimistic that we will manage to feature-freeze at the Camp and do something that we can call a 2.0 prerelease. Perhaps we will need to declare one or two missing features as bugs but basically the release made at GimpCon should have everything that GIMP 2.0 will have. Sven, I am here working, though slowly, on the programable layer mode, which I proposed when I first joined the list. It's not such a small change, since adding layer modes breaks the cross-reading of .xcf files. So what I need to know now is: - If I deliver a partially working patch by next week, could it be included before the feature freeze? - Else, I think the proper moment to bring it up would be when the new GIMP file save format, which is on topic nowadays, would be implemented. Could that be 2.2 ? Or do we have a chance of having this new file format in 2.0? If yes, I think it could be done in a way that new layer formats could be made not to break badly the backwards compatibility. Thanks. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] When Gegl?
On Monday 21 July 2003 4:47 pm, Adam D. Moss wrote: Patrick McFarland wrote: So, if gegl isnt going to be in gimp2, when will it be? Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4? gegl isn't a panacea... Perfectly said. Actually, I've skimmed trhough some docs on the GEGL, and I wonder, what are its actual uses for the final user? I can see it provides the grounds for easier hacking in the GIMP, and will facilitate the implemanetation of internal CMYK and FLoating point images, and such. But for GEGL alone, what does the artist takes? I can also see that it could be a nice engine to provide a customizable brush, or layer combine mode. I am writing such a resource for gimp 1.3, whithout GEGL, and even if it doesn't make it in the official tree, it will be avaliable to whoever wants to try it. Of course, I am probably missing a lot of uses of the GEGLL - but I am gneuinely interested in knowing more about it. Thanks, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Custom layer mode combination
Hi, Maybe some of you can remember that, when I joined this list about two months ago, I proposed a programable layer combine mode for the GIMP. The basic idea is that besides the normal addition darken only layer modes, to implement a custom mode. In it, the user gets to type a c-like expression of what to do with the pixel values in each channel when combining the layer. For example: RD=(R2 + R1) /2; GD=G2; BD= B1; will average the red component, pick the green component from the upper layer, and the blue component from the underlying image. Another example: ED=VD 0.5? DARKEN_ONLY : LIGHTEN_ONLY; If the Pixel value is greater than 0.5 (50%), then combine it as in the Darken Only mode, else, use Normal mode. And it also works as a paint mode, so custom paint mode comes as a bonus with this feature. I had little time to fuss with it over the first month, and now I could manage to get some work going on - still only on a few hours per week. I should make it clear that although I'd like to see it in the GIMP, at this time it's not what concerns me. If people think it's a nice feature, it can be made to work in a clean way before August 10th - actually, it already does work in a clean way, just lack features. If no one is interested, I will appreciate help and feedback nonetheless, and once it's finished, I will just publish the patch to a stable version of the GIMP on my page. However, I am getting some results now, so, I'd like to bring the discussion here, for there is a lot there is unknown to me in the GIMP tree. (From here on, this message should be readable by people familiar] to the source code of the gimp. I mean - if you are confused with this, just skip the rest of the mail.) First of all, I have the engine fairly complete in the app/paint-funcs/paint-funcs-generic.h file. Unfortunattely, I am working off-town, and can only recompile my GIMP, and hack it at all on the weekend. And now, I am thinking on a way to get the custom combination data getting to it. For testing, so far,I had hardcoded the combiantion expression on the source file. As far as I have thought, I'd like to feed it through a call in the combine_sub_region() paint-funcs.c function, passing extra data if mode==GIMP_CUSTOM_LAYER_MODE than it passes to the other functions. Actually, it will have to be this way. At the same time the most obvious way to keep track of this data is putting it in image parasites. So, if a layer has got a custom mode, it's mode is attached to it in a parasite. One issue I am having at the moment is that I'cannot figure out how to get the Parasite data from inside the combine_sub_region function - that function doesn't seen to be aware of in which image it is operating. I think that once I have the image id, it's allright to call the parasite functions on the libgimp-base api from within there. One other doubt I have is where to put the ENUMs I need for the operators inside the engine. I can see the easier way is to add them to app/bse/base-enums.h. Is there any problem with it? And, while away from home, I try to get more familiarized with the code through browsing the cross referenced code on the developers page. But that only shows the files up to line 206. Is that correct? Is tehre a way to see the whole code files from that site? So far...any feed back is welcome. Thanks everybody. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Could someone add the CVS modules to the devel page?
Hi there. The information about the CVS modules on the web is this bit (from http://www.gimp.org/devel_cvs.html ) __ (...) The avalable modules relating to gimp are are: gimp gimp2 (no code here, just holding place for ideas) gimp-data-extras gimp-plugins-unstable glib gtk+ gegl (experimental code for gimp 2.0) There are also several branches in the GIMP cvs tree: the main or HEAD branch is GIMP 1.3 (the development version), the old GIMP 1.0.x is in gimp-1-0, the stable version GIMP 1.2 is in gimp-1-2; and there are a few other experimental branches such as the HOLLYWOOD branch for deep image support. To check out a branch, gimp-1-2 for example, try this commmand line: cvs -z3 co -r gimp-1-2 gimp (...) __ I know from at least gimp-gap and gimp-perl more, maybe there are a couple I have not heard about. Possibly tehre is a fair easy way to know about the modules using CVS itself. But by knowledge on CVS is close to zero. :-( sorry about that. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Could someone add the CVS modules to the develpage?
Daniel Egger wrote: Am Fre, 2003-07-25 um 09.31 schrieb David Neary: Up until pretty recently, GNOME CVS had a habit of creating a module as an alias for a directory... I suppose this was so that the aforementioned cvs co -c would work... there is actually no way to know what directories exist in a cvs repository other than looking, I think. Either with a gui tool, or with a file browser. I may be wrong, though. http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome This is what I was looking for, thanks. The cvs co -c command had some missing, notably gimp-gap, gimp-perl, gimp-data-extras. As for the dependencies, I was not asking about that. INSTALL, HACKING and the output of ./configure say enough about those. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: ANNOUNCE: gimp-plugin-template 1.3.1
Hi. I do not know the X11 license, but changing the license of the plugin template recalls me of one thing: If the GIMP is under the GPL, with no exceptions listed were appropriate, them it is ilegal for non GPL-compatible plugins to be installed. This is quite clear on the GPL-FAQ. And for great that it may seen for some people to have some proprietary plugins developed for the GIMP, that otherwise would not, we get better respecting the GPL or __else__. To allow for non gpl-compatible plugins to run with the GIMP, the license of the GIMP itself must include an exception note, stating that. Sven Neumann wrote: Hi, going hand in hand with the 1.3.17 release, there's now an updated version of the gimp-plugin-template available from ftp://ftp.gimp.org/pub/gimp/plugin-template/ The template has been relicensed to a less restrictive X11-style license (thanks to Adam for his patch) and was updated to follow the GIMP-1.3 API changes. It requires at least GIMP-1.3.17. If you want to write a larger plug-in for GIMP 2.0, this package should give you a good start. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Custom layer mode combination
On Friday 25 July 2003 1:36 pm, Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2003-07-24 at 2031.28 -0300): The basic idea is that besides the normal addition darken only layer modes, to implement a custom mode. In it, the user gets to type a c-like expression of what to do with the pixel values in each channel when combining the layer. IMO you are forgeting a kind that users will like a lot more: call other GIMP functions, specially some like levels or curves (in this case, using the layer to control strengh in a channel by channel basis, or maybe using value (V in HSV) to get a single number and work like a selection mask, you should have to checke what makes sense). I guess users will find more use to those than playing around with formulas. I used the filter that lets you do math formulas to test ideas, but dunno how many people would like to use that daily. My idea is that in the end, the custom layer formulas get recorded in a gimp directory, just like brushes and patterns. So, a set ofrather itneresting formulas would be shipped with the Gimp (or with the patch). That would provide alone could provide a lot of functionality. My idea for the PDB entry is just to accept such a formula. I am sorry - I coonot think of another interface for this thing I am creating. When I first presented the idea, someone came up with the idea ofan interface like those used to set filters to e-mail prograns. Maybe it can be done... But when it´s i n formula type and go stage,, I will have some of you using the feature, and we will be able to think together on a new interface. The formulas are nice, I am not saying you should drop that, but you should find a way to cover both if you can, formula and PDB. If you are going to get dirty, make it really worth it. Maybe even you can do the PDB way only, and provide a new call that does formulas (sounds simpler to me, more generic). I don't get exactly what is your idea. I will probably, in the end make a gimp_custom_layer_set_mode (drawable, custom_layer_formula); where custom layer formula is a string exactly like the one taht would be typed on the interface. The rendering engine use a stack - I am in the proccess of writting a compiler from the c like expression to the operand stack. Hey, maybe you can fit into it effect layers. ;] Well, probably not, they are not simple operations to layers below them. Depends if you want to apply filter to the result, which is just the call idea, or to the layer data only, Actually, thta already happens. The formulas are simply. The input operands are the letters describing a channel, followed by 1 if the channel belongs to the image bellow, or 2 if it belongs to the actual layer. And letter+D makes the destiantion channel. So something like: RD=R2*R2; GD=G2*G2; BD=B2*B2; will actually square the values of each channel. Since they are treated as normalized (i.e. from 0 to 1), it's akim to using the curves tool to enhance contrast sharply. The main difference is that you can work on the drawing while experimenting with the contrast levels, without wororring about spoiling the RGB data on the process. Just change back to normal mode, and all your raw data is there. which is what you need for auto bevel or auto drop shadow when working with text, ie. Last case would be more like having a layer hidden as input and a visible one as output, and recalculate output one only when input changes, not every time layers below change. Hmm. I am working ont he paint functions..gimp s smart,a nd the code on this are is rather clean now...The paint functions are only called when changes are made. Drop shadow however is not an option - I can use the blend of the pixel directly bellow the one I am processing, and none other. In any way, all are interesting ideas to explore. I can barelly finish to get it working na reasonabvle dinamic form, so thatI myself can experiment with it. On the technical side - I will need to code in some string manipulation now. Are there API's for string deeply hidden ing gtk/gimplib? I had seen none so far (did nt pick GTK reference however),a nd I a m goint staright to stdlib's strlen and strncpy. Is there any issue with using these? GSR Cheers, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Custom layer mode combination
On Saturday 26 July 2003 5:44 am, Adam D. Moss wrote: Joao S. O. Bueno wrote: My idea is that in the end, the custom layer formulas get recorded in a gimp directory, just like brushes and patterns. How are they recorded in the XCF file? (I may have missed that part of the thread.) Parasites. So the only difference to current XCF files would be anm extra layer_mode number. So, a set ofrather itneresting formulas would be shipped with the Gimp (or with the patch). Users won't apply patches -- I doubt that more than a couple of percent of users are even actually building from source (especially for 2.0). yes..that is why I'd be very pleased to see it in 2.0 (but even if I get it ready, it will be so close to freeze date, that maybe the mainteners reject it), or at least for 2.2 . Hey, maybe you can fit into it effect layers. ;] Well, probably not, they are not simple operations to layers below them. Depends if you want to apply filter to the result, which is just the call idea, or to the layer data only, Actually, thta already happens. The formulas are simply. The input operands are the letters describing a channel, followed by 1 if the channel belongs to the image bellow, or 2 if it belongs to the actual layer. And letter+D makes the destiantion channel. So something like: RD=R2*R2; GD=G2*G2; BD=B2*B2; will actually square the values of each channel. Since they are treated as normalized (i.e. from 0 to 1), it's akim to using the curves tool to enhance contrast sharply. (Well, contrast enhancement would be more like a sigmoid function -- what you describe here is basically gamma adjustment for a fixed gamma value.) Ok, gamma them. Sorry, I am not versed in the mathematic fundamentals of thes corrections. However I will implement an exponentiatio operand - so one may use other gammas as well. But it´will have to use F.P. so expect it to be _slow_ . I think that what GSR is really asking for in effect layers is stuff like 'blur layers', 'pixelize layers', etc, which basically is what everyone really wants. :) These require a decorrelation between the positions of pixels of different drawables though -- I made a working prototype of this during 1.1.x and it wasn't pretty. Yes...no way to do taht just hacking in the paint-funcs already existing. On the technical side - I will need to code in some string manipulation now. Are there API's for string deeply hidden ing gtk/gimplib? Not as such -- but if you're using GTK/gimplib then you're already using glib, which has some great string manipulation functions (go look them up). Thanx. I will. :-) --Adam JS -- -- 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. --- -- 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
Re: [Gimp-developer] writing german online help
On Sunday 27 July 2003 3:13 pm, Daniel Egger wrote: - I'm not sure which article to use for GIMP in German so I normally don't write one. A male article sounds more strange than none at all but if we can find a good ruling -- all the better. In Portuguese, the current use is for a male article - and trying making it female would be pretty bizarre. As fa as I can recall, all computer prograns or aplications are refered as male here. But anyway, many words have their genders swapped between German and Portuguese anyway. JS -- -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Grain modes are just the beginning - was McFarland's Re: StartupNotification support...
As we say in my land, her e I come selling my fish again. :-) Back to the Custom Layer Mode. On Saturday 26 July 2003 9:44 pm, Patrick McFarland wrote: Also, the additional layer blending modes are nice. Ive used both Grain modes already in some images, and they are nice additions to plain Addition and Subtraction. So...just wait until the custom layer modes are put to work in a usable way. :-) You will just love it. Unfortunatelly I got a new project at work and will have even less time to write it. So it will probably not get ready to feature freeze. :-( Not final use ready, but maybe it gets working sans a good UI. Under the custom layer mode, one would not have to wait for a GIMP major release to get the grain modes. For example, this is the line in current gimp code that does the merge mode : sum = src1[b] + src2[b] - 128; It will be doable by typing: ED = E1 + E2 -0.5; as the custom layer mode. (E stands for every channel. A is already used for alpha - I myself dislike the every, and will accept other suggestions) The advantadges? Even the above formula throws information away - it kees a better average than ADD layer mode. With the custom layer mode, you willbe able to adjust the cnstante factor for every layer on every image. Thus if it is too light, with large white only areas, one will just have to edit the layer mode expression from the above to: ED = E1 + E2 -0.7; , for instance. Cheers, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Grain modes are just the beginning - wasMcFarland's Re: Startup Notification support...
On Tuesday 29 July 2003 1:25 am, Patrick McFarland wrote: On 28-Jul-2003, Joao S. O. Bueno wrote: It will be doable by typing: ED = E1 + E2 -0.5; as the custom layer mode. (E stands for every channel. A is already used for alpha - I myself dislike the every, and will accept other suggestions) The advantadges? Even the above formula throws information away - it kees a better average than ADD layer mode. With the custom layer mode, you willbe able to adjust the cnstante factor for every layer on every image. Thus if it is too light, with large white only areas, one will just have to edit the layer mode expression from the above to: I have no issues with E. It might also be nice to have YUV (independant of the image's mode). I have implemented R G B, H S V, and A besides E. BTW, E doesn't affect the alpha channel - as the majority o f the fixed combination modes do not. - ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Fwd: Re: [Gimp-developer] Grain modes are just the beginning - wasMcFarland's Re: Startup Notification support...
On Tuesday 29 July 2003 5:38 am, you wrote: Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: For example, this is the line in current gimp code that does the merge mode : sum = src1[b] + src2[b] - 128; It will be doable by typing: ED = E1 + E2 -0.5; I don't want to discourage you and it's certainly a nice expert/geek feature but I doubt that the casual GIMP user wants to type in any formulas. I know that. Thats why in the future, I want to make them loadable resources just like brushes and patterns. This way, less oftenly used layer modes could go packaged with the GIMP - or be put in a resources page - without cluttering the UI. And even those who will not like typing formulas may fell tempted to tweak a little the numbers - like the .5 to .7 above. Unfortunattely I cannot think, as I've said, of a graphical way to build such formulas. But...when it's time for it, maybe people here ont he list can give e some subjetions, and the raw formula writting canget put behind an advanced button. Sven JS -- --- -- 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
Re: [Gimp-developer] http://mmmaybe.gimp.org changes
Niklas Mattisson wrote: - Bugs have now changed to be a section with information and there is HOWTOs in that section now also. I wrote a How To Submit a Patch this weekend also and would like people to look at it and give me comments and some feedback to make it even better. Maybe you could add some information about witch switches to use on the diff command to create a suitable patch. I know that it may be well known for everyone here, but I for an example, had to re-submit my first patch to the gimp because I've created it without the -p switch. Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Second try
hmm...Agreeded. I'd suggest 10 days instead of 5 (if I, for an example, am on a heavy workload week, 5 days could not be enough to make my points, if they need soem expermenting on the codebase), But since the decision was taken, so mote it be - it's not gonna hurt. As for the foundation., I'd be happy if it was in Europe. USA is getting more and more of those stuppid laws, including states passing super-DMCAs¨ , that if enforced would stop the Internet alltogether. The foundation has to care off one other thing I did not see on the summary: most, or all of the codebase must be owned by it. It would legally allow small adjusts in the license, like the recently one that clarified that there could be proprietary plug-ins for the GIMP. (Strictly in terms of the GPL, as currently the copyright holder is each individual author, there would be the need to have express permission from each author for this change). Also, there is the GNU motive - if the need arises to defend GIMP's IP in court, it is easier if the foundation is the owner, and not a lot of people spread over the world. Off course there must be foolproof safeguards to keep the foundation from doing non-wanted things to the codebase. So, that GIMP should be free software should be specified in the reason of beingof such a foundation. These are my points so far. Cheers, JS -- - Decisions --- Not too many of these... we will have a release manager, but we need to define exactly what his/her remit will be. And who it will be. We agreed that the 5 days and it's dead rule for threads makes sense, so that will be done. - Future 1) Roadmap - rough release schedule, we will have a first draft today. 2) GIMP Foundation - we need to define its responsibilities, set up election rules, and get this set up. The principle of the foundation is more or less agreed. 3) Communication 4) Release Manager - what'll he do, who'll he be. This should be short once we have discussed communication channels a bit. 5) Technie stuff - Sven and mitch are going to talk to us about the re-organisation of the code, GObjectification of everything, and other stuff. Daniel and Calvin are going to talk to us about Gegl and how they feel the GIMP could use it. This will probably be a two-way discussion about what kind of things we expect gegl to furnish as well. 6) GIMP tutorials - jimmac and nomis are going to do some presentations for people, which should be good. 7) Plug-in distribution - 3 years ago this was discussion, yosh has been working on something as a proof-of-concept, it would be nice to address this and get something in place soon. So there you go. Hello everyone from camp. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Portable XFC
Thank you for the comments. I quite much agree with all of them, I just threw it in because I think it'd more interesting than TIFF or PSD alltogether. Quite informative is the part about Adobe patents. I will no longer mention PS as a native file format, GSview is quite good as a PS loader as it is today. As to Leonard who suggested that postscript doesn't accept plugins, I have to point him for the fact that it i s a programing language - and the dedcoding algorithns I mentioned would just be placed in the file as postscript procedures. And why PS instead of PDF? You can edit good Postscript files with a text editor, just as you can do with XML. Regards, JS -- Mukund wrote: On Wed, Aug 13, 2003 at 08:32:00PM -0300, Joao S. O. Bueno wrote: | But on this new thread were proprietary formats batle along with mutant | ideas, here I go: | Why not settle for a Postscript subset? PostScript is a proprietary format controlled by Adobe. Adobe has several patents on various aspects of the PostScript format any implementation would be affected by. | The major one, of course, is that the file would be essentialy auto | renderable - no need of GIMP, neither of any other program, to get it | printed. This is a good idea, but it would also mean GIMP would have to read back a PostScript file. PostScript is a huge standard outside the scope of an application such as the GIMP. Developers would have to put in kludges and special comments which'll help them represent structures which cannot be natively represented using PostScript. Isn't this just as expensive as implementing a new specification? What's more easier? A Have a native file format designed for the GIMP. Those who want to use it with PostScript aware applications export the native format using a plug-in. If XML is used for the underlying data representation, any XML parser can be used to parse information, especially information such as the author of an image, size and colour depth of the image, etc. B Use a subset PostScript as the native file format. Design and implement representation of unrepresentable structures in PostScript comments. Implement a PostScript parser (which is as good as a stack based interpreter). | Since PSD and TIFF are used by ADOBE, ADOBE also has a program that | makes use of postscript subsets.. I just do not remember which file type | it is. | | It can have color profiling support - it is on the specifications. It | has support for multiple compression standards... (ok, maybe you have to | encode the decompressor algorithm inside the file as well if you want | something too different) Support for multiple compression algorithms can be implemented in an XML based format. One can also have data in other image formats such as TIFF, PNG or even the same GIMP native format itself embedded as CDATA, or the file format may be an archive of associated images, etc. The features implemented depend on how far developers want to take the new file format. The developers themselves are capable of doing what they want :-) Mukund ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon RFC: Portable XCF
Stephen J Baker wrote: Austin Donnelly wrote: How is the serialization done then, just a raw 32-bit IEEE float dump with a predefined endianness? 64-bit doubles just as easy? The real problem comes when your code is running on a system without IEEE float support, and you need to manually convert from IEEE float to your local weird-ass machine float. Not common, I grant you, but a real pain when it bites. So it's somehow preferable to come up with our own wierd-ass float format and make life equally hard for everyone? By far the vast proportion of modern machines have IEEE float - so let's make life easy for the majority. The minority need a conversion routine no matter what we do. The last machine I used that didn't have IEEE float (some wierd Hitachi microcontroller) had convenient library functions to interconvert between it's native format and IEEE. I am all for IEEE FP as well. Just as an ilustration, the code I am working on for custom layer modes uses fixed point - 32bit , being 16.16. There are reasons that lead me to choose it, I can comment if it they are of interest to anyone. If the internal image format is 32bit IEEE it will be easy for me to add the needed convertions, as the 8 bit unsigned integer and 16 bit unsigned integer conversions are in place already. The only other alternative is to use a storage mechanism for which there is universal conversion support - but the only format that fits that bill is ASCII - surely we aren't contemplating that for bulk image data? Steve Baker (817)619-2657 (Vox/Vox-Mail) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fun with Adobe forums
On Monday 25 August 2003 9:32 pm, Branko Collin wrote: Sometimes, when I get bored, I start scouring forums on the net for GIMP related chat. Of course, it's extra double plus fun to search Adobe.com's forums for talk of the GIMP. Most of it is talk about GIMP-print, of course. --==+++==-- So, did you guys know that Disney considered using the GIMP and/or Cinepaint, but instead paid some coders to make sure PS runs in WINE? http://www.eweek.com/article2/0,3959,1210083,00.asp Yup. I saw this over on slashdot. And when I commented there something about preferring to see th GIMP, if not for anything else, for the free-software question, I got some 15 replies flaming me all over. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal for protesting against softwarepatents in Europe
As far as I am concerned, I'd be pleased to see it there. If they aprove it in Europe, it will be a matter of a few months before they catch on here (Brazil). We are at risk even with Europe being free. Regards, JS -- On Tuesday 26 August 2003 10:07 am, Raphaël Quinet wrote: http://www.gimp.org/nopatents.html ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fun with Adobe forums
Alan Horkan wrote: On Tue, 26 Aug 2003, Joao S. O. Bueno wrote: So, did you guys know that Disney considered using the GIMP and/or Cinepaint, but instead paid some coders to make sure PS runs in WINE? http://www.eweek.com/article2/0,3959,1210083,00.asp Yup. When this was on Slashdot I did mention at least in a PS at the end of one of my mails. /me thinks of searching the archive but is the archive working again? will the alternative link suggested be up to date (last time I looked it was lagging by a few days) Let it be. I actually remember a post on this list, and it should be this one. ... but anyway I am logged in on a console, so I'll skip finding a link this time. I saw this over on slashdot. And when I commented there something about preferring to see th GIMP, if not for anything else, for the free-software question, I got some 15 replies flaming me all over. 1) You will probably get flamed no matter what you say on Slashdot, although I am would be interested to read exactly what you wrote. I am finding out that trying to defend free software brigns more flames and bad moderation than other subjects. :-) I will try to find my post and paste it at the end of this message. 2) Gimp and CinePaint were incidental to the article, the big deal was that Disney *EVIL* actually spent some money and helped improve WINE *GOOD* (although some looonatics object to WINE on a twisted notion that compatability with legacy applications is a bad idea). Correct, that is what the article was about 3) They probably only evaluated GIMP 1.2, and even though GIMP 1.3 is a lot better I dont think any of you will deny there is 'room for improvement' 4) Although there are some tradeoffs CinePaint better fills the niche for a movie studio, higher colour depth and support for file formats such as OpenEXR are important. Dunno. The only cinepaint I had seen was called filmgimp 5) Adobe Photoshop users, particularly proffesional artists love Adobe Photoshop. Price is not really an issue when the company is paying (up to a point, companies will eventually draw the line (no pun intended)) GIMP/CinePaint needs to be more than just as good, it needs to be significantly better for that kind of specialist user to make the effort to change. The killer feature(s) in the GIMP is freedom, and so cheap it is free. Proffessionals who depend on Adobe Photoshop are probably the last people that will convert to the GIMP. The value they place on Photoshop is not just the box price, it is the years of time and effort invested into learning it inside out and more. Actually, one of the many replies pointed to this: Disney, better, the departament that went Wine/photoshop, actually tried pushing GIMP or CinePaint, but got a big No from the artists. That means you are completely right, Alan. However after saying all that a whole lot could have been done to improve the GIMP or (and you are not going to like me for saying this) more likely CinePaint, with the hefty amount of money that Disney was willing to spend on this project. Perhaps if Adobe Photoshop 8 fails to maintain WINE compatibility they will look this way again. Has anyone mailed the man at Disney yet? I probably will, and encourage him to provide feedback, hopefully with a little more detail than just make it more like Photoshop. He seems to be in some way affiliated with CinePaint already (I forget his name but I looked it up when the article was first mentioned). - Alan My post on /. on this subject was: (I am Pope Raymond Lama there) __ Re:Disney supporting open-source? (Score:*, Insightful) by Pope Raymond Lama (57277) on Tue Aug 05, '03 12:25 PM (#6616021) (http://www.geocities.com/gwidion23) No. Disney non-supporting Open Source, as it has always been. Now, instead of using, and helping improving The GIMP, linux people will just run their pirated Photoshops and be happy, as oftenly such users do not know the difference between free and proprietary software. -- -- no .sig is good sig. __ In reply to: Disney supporting open-source? (Score:5, Funny) by Prince_Ali (614163) on Tue Aug 05, '03 12:13 PM (#6615846) (Last Journal: Sun Oct 27, '02 05:19 PM) I can feel the slashdotters' brains explode with conflict. -- Money follows votes; it does not buy votes. Two legs better! __ URLs follow: /. Article: http://slashdot.org/article.pl?sid=03/08/05/1552255 /. Comment: http://slashdot.org/comments.pl?sid=73635threshold=2commentsort=0tid=106mode=threadcid=6616021 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current state of path tool.
ok, 4:21 n the morning... I just could run gimp 1.3.19 now. I don't know how many of these changes came in after 1.3.19, but I can only see 2 modes on the tools options. I am feeling sleepy, and I could not follow the guidelines below . It seens me that the edit mode is not there at all. I will try to build the gimp from HEAD tomorrow (I sometimes have problens with this, but I am interested enough in the vector tool to help out. So, if I cannot build it, expect me on #gimp looking for some help) I hope you are willing to change some of these key strokes. I remember being able to iamgine something that would make more sense, while awake - so I will write more on later. Now I can only note that the behavior of the SHIFT key on the simetry of Handles should not toggle like that, and IMO should be more consistent. But I will have more to say on the keys once I get all the functionality you list bellow. The ability of changing a segment curvature by draging a randon point of it is quite amazing, rest assured. As for teh future plans, inr egards to import and export to other file formats, There is Python code from both Sven, and another implementation by me to export bezier paths to SVG. There is also some python code of mine to export them to Postscript and POV-Ray sphere sweeps. (http://hopey.nervo.org/~gwidion/gimp , Sven's code seens to float up somewhere in the Tools directory, and I am not certain if it moves to anywhere that makes sense when installing) . Needless to say, there is no code to read any of these back. If you feel like python will not be universal enough in Gimp installs, I can rewrite some of my scripts in C. So far, expect me to write more about vectors tomorrow. I will get some sleep now. Regards, JS -- On Friday 29 August 2003 6:04 pm, Simon Budig wrote: Hi all. Here is an overview on the current state of the path tool as well as a summary of its usage. Please try to use the tool and tell me about problems. If you have suggestions on how to improve the tool, please discuss them on the list. Bye, Simon Overview on the current state of the path tool. --- The path tool has three major modes. The Edit-Mode allows to create anchors/handles as well as moving of anchors/handles/curve-segments. The Insert/Delete-Mode enables you to insert anchors on curve-segments, connect strokes as well as deleting anchors and segments (splitting up a curve). The Move Mode moves whole strokes or the whole vectors object. Changing between modes: --- You can change between these modes either by clicking in the tool options or by using the CTRL/ALT modifiers. If CTRL is pressed the tool will switch to the Insert/Delete Mode, ALT does the same for the Move Mode. When you selected the mode in the tool options please note, that the CTRL/ALT modifier will switch back to the Edit-Mode when released. Edit-Mode: -- If there exists no vectors object, a click will create a new one. If a stroke exists and there is just one marked anchor at the end of a stroke a click in the canvas will extend the stroke. If there is no marked anchor or it is in the middle of a stroke a new stroke will be started. You can click on open ends of strokes and extending will continue there. If you click over an anchor or handle you can move them around. When dragging around handles the SHIFT-Key will restrict the opposite handle to symmetric movement. (Also after pressing down the mouse button to place the anchor you can drag out control handles and position them until you release the mousebutton. Both anchors will initially move symmetrically. If you want to break the symmetric movement you can push down and release the SHIFT key while dragging. This is a special case to enable quick creation of bezier strokes). If you click over a segment you can drag it around without the need to add more anchors to the curve. Also pressing SHIFT restricts the movement of the adjacent handles to symmetric ones. Insert/Create Mode: --- This tool only works when over the curve or over anchors. If over a handle. Clicking on the curve will insert a new anchor, you can drag it around directly afterwards. SHIFT-Clicking on a node will delete it. Clicking on an endpoint of a stroke enables you to drag out a straight line you can drag to another endpoint to connect these strokes. Please note that the resulting connection will be curved according to the existing handles. You can delete a segment of the curve by clicking on it while SHIFT is pressed. Move Mode: -- That one is easy. Click-Dragging on a anchor/curve drags the complete stroke. SHIFT-Click-Dragging will move the complete vectors object around. PROBLEMS: - Right now the behaviour is a bit inconsistend with respect to selecting/unselecting anchors. This is
Fwd: Re: [Gimp-developer] Current state of path tool.
I've sent this yesterday, but I have bnot seen it on the list. I think my local IP may have got blacklisted, so I am trying again. Js -- -- Forwarded Message -- ok, 4:21 n the morning... I just could run gimp 1.3.19 now. I don't know how many of these changes came in after 1.3.19, but I can only see 2 modes on the tools options. I am feeling sleepy, and I could not follow the guidelines below . It seens me that the edit mode is not there at all. I will try to build the gimp from HEAD tomorrow (I sometimes have problens with this, but I am interested enough in the vector tool to help out. So, if I cannot build it, expect me on #gimp looking for some help) I hope you are willing to change some of these key strokes. I remember being able to iamgine something that would make more sense, while awake - so I will write more on later. Now I can only note that the behavior of the SHIFT key on the simetry of Handles should not toggle like that, and IMO should be more consistent. But I will have more to say on the keys once I get all the functionality you list bellow. The ability of changing a segment curvature by draging a randon point of it is quite amazing, rest assured. As for teh future plans, inr egards to import and export to other file formats, There is Python code from both Sven, and another implementation by me to export bezier paths to SVG. There is also some python code of mine to export them to Postscript and POV-Ray sphere sweeps. (http://hopey.nervo.org/~gwidion/gimp , Sven's code seens to float up somewhere in the Tools directory, and I am not certain if it moves to anywhere that makes sense when installing) . Needless to say, there is no code to read any of these back. If you feel like python will not be universal enough in Gimp installs, I can rewrite some of my scripts in C. So far, expect me to write more about vectors tomorrow. I will get some sleep now. Regards, JS -- On Friday 29 August 2003 6:04 pm, Simon Budig wrote: Hi all. Here is an overview on the current state of the path tool as well as a summary of its usage. Please try to use the tool and tell me about problems. If you have suggestions on how to improve the tool, please discuss them on the list. Bye, Simon Overview on the current state of the path tool. --- The path tool has three major modes. The Edit-Mode allows to create anchors/handles as well as moving of anchors/handles/curve-segments. The Insert/Delete-Mode enables you to insert anchors on curve-segments, connect strokes as well as deleting anchors and segments (splitting up a curve). The Move Mode moves whole strokes or the whole vectors object. Changing between modes: --- You can change between these modes either by clicking in the tool options or by using the CTRL/ALT modifiers. If CTRL is pressed the tool will switch to the Insert/Delete Mode, ALT does the same for the Move Mode. When you selected the mode in the tool options please note, that the CTRL/ALT modifier will switch back to the Edit-Mode when released. Edit-Mode: -- If there exists no vectors object, a click will create a new one. If a stroke exists and there is just one marked anchor at the end of a stroke a click in the canvas will extend the stroke. If there is no marked anchor or it is in the middle of a stroke a new stroke will be started. You can click on open ends of strokes and extending will continue there. If you click over an anchor or handle you can move them around. When dragging around handles the SHIFT-Key will restrict the opposite handle to symmetric movement. (Also after pressing down the mouse button to place the anchor you can drag out control handles and position them until you release the mousebutton. Both anchors will initially move symmetrically. If you want to break the symmetric movement you can push down and release the SHIFT key while dragging. This is a special case to enable quick creation of bezier strokes). If you click over a segment you can drag it around without the need to add more anchors to the curve. Also pressing SHIFT restricts the movement of the adjacent handles to symmetric ones. Insert/Create Mode: --- This tool only works when over the curve or over anchors. If over a handle. Clicking on the curve will insert a new anchor, you can drag it around directly afterwards. SHIFT-Clicking on a node will delete it. Clicking on an endpoint of a stroke enables you to drag out a straight line you can drag to another endpoint to connect these strokes. Please note that the resulting connection will be curved according to the existing handles. You can delete a segment of the curve by clicking on it while SHIFT is pressed. Move Mode: -- That one is easy. Click-Dragging on a anchor/curve drags the complete stroke.
[Gimp-developer] Regarding the vector tool
Ok, for startting: Closing paths should definitely be a matter of one click starightforward thing. So it must be doable on the default extending mode without any extra modifier key. I know you have beiong strugling with it - the previous ctrl_alt_shift_click, and the current ctrl + drag show you have being trying around. However, while I think the ctrl+click+drag as it is could be usable, it gives margin to gratuitous undefensable gimp bashing to whoever is learning it. So here is my proposes solution: your mode 2 add-insert point is not too feature loaded. It works correctly, I'd propose that in this mode it would be possible to extend the path, just as in mode 1. I mean, when one clicks in apont not already ona node or on a segment, that a new node would be created there. And, on this (insert/delete) node: if one clicks on an existing node, wihtout a modifier for deleting: if the current curve is open, then it would close the current curve on that node. if that node already had two segments going out add a new node overlapping it, with the same coordinates. the mode extend/move could stay as it is. The ability to add new nodes when clicking outside the curve would be avaliable on both this mode and the add/isnert, but I don't think that would be a problem. If it becomes a problem, them leave this mode to move only, and let extending the path up to the insert delete mode. In any case, the default mode should become the insert/delete (now a insert/extend/delete) mode. Please, give this a serious though ... I think the ability to straightforward closing a curve segement is worth it. A different issue is: On the MOVE mode, if there is a node with the handles collapsed, they won't come out unless you grab and bend one segment that connects to that node. However, clicking on a node, holding shift, and dragging is unused- I mean, it has got the same behaviour than clicking and draggin without shift. Therefore, I suggest that shift clicking on a node with collapsed handles and dragging become equivalent to shift-click on a handle of that node. Shift click on the move/stroke mode is yet unnused. I suppose you will link that to stroking, as it is on the mode name. I think that is it for now. I think that it is obvious, but since I am writting I will mention that there seens to be no way of currently making the GIMP redisplay a vector once it is hidden. I will assume you are working on that. Another issue is that, as in the 1.2 series, maybe even worse, working wirth vectors leave dirty pixels everywere on the image, until it is refreshed. It is of nearly ultimate importance that this doesn't happen in gimp 2.0 final. Mark those tiles as dirt with no mercy. :-) Also I hope you are aware that selecting another vector on the paths toolbox is all but ignored by the editing tool right now. Best regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Edit Alpha as Mask
I failed to send this to the list yesterday. I have a proposal to the matter of editting the alpha channel as mask, as follows: Original Message Subject: Re: [Gimp-developer] Edit Alpha as Mask Date: 10 Sep 2003 13:04:27 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Joao S. O. Bueno [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: (...) Yup... Instead of changing the alpha channel when adding a layer mask, create an option besides apply layer mask. I think Replace layer alpha with mask would be descriptive enough and add the needed functionality, You are bringing up a completely new point here and I think you want to repost this to the list. Sven -- J.S. -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Vector's PDB
Hi Simon, So...there are they guys talking about pre1 already... I could not have the time for myself to even compile 1.3.20 yet (will do in a few minutes, I hope) How is the vector stuff? Are the itnernal representaions, if note all thetouchs on the UI finished? If s, I believe that tomorrow, and during the niught from tomorrow to the next day, I will have time to make some work on the PDB, as I have talked to you the other day. Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] PO files
Can someone point me to a howto or explaination on how are the files firstly generated? I usually run everything in English here, but I was browsing the pt_BR.po, and it is looking a little worse than if the translations were done by an authomatic engine. I'd guess no one at the connectiva team listed in the file is a GIMP user at all. Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PO files
On Tuesday 16 September 2003 1:11 pm, Sven Neumann wrote: Hi, David Neary [EMAIL PROTECTED] writes: Sure. README.i18n contains the basics of how to use gettext. The inaccurate Rough Guide is like this... you copy an existing po template file to one named after your localisation, translate the messages (being careful to use UTF-8), add the po files to CVS, and when you have po files for each of the localised directories (the dirs starting with po), add the language to ALL_LINGUAS in Makefile.am You missed an important point here: You should coordinate your translation effort with the GTP (GNOME Translation Project). Please do not start working on translations (new or existing ones) without getting in contact with the translation team for the particular language you are interested in. Here goes what I got when writting the one in charge for pt_BR in the GTP pages: Hi. This is the qmail-send program at conectiva.com.br. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. -- [EMAIL PROTECTED]: Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 22270 invoked by uid 0); 16 Sep 2003 16:30:10 - Received: from perninha.conectiva.com.br (200.250.58.156) by burns.conectiva with SMTP; 16 Sep 2003 16:30:10 - Received: by perninha.conectiva.com.br (Postfix) id 1C23747432; Tue, 16 Sep 2003 13:35:04 -0300 (BRT) Delivered-To: [EMAIL PROTECTED] Does GTP have a list or something? I think I have heard from this Godoy in a local free-software list, I will check. Meanwhile I've written the guy listed in the GIMP pt_BR file - that mail did not seen to fail, and I will possibly get a reply. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PO files
On Wednesday 17 September 2003 9:30 am, Daniel Egger wrote: Re: [Gimp-developer] PO files Date: Today 9:30:45 am From: Daniel Egger [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Message was signed with unknown key. The validity of the signature cannot be verified. Problem: OpenPGP plug-in was not specified. Use the 'Settings-Configure KMail-Security' dialog to specify the plug-in or ask your system administrator to do that for you. Am Mit, 2003-09-17 um 13.29 schrieb Sven Neumann: Is this the official new list for the GTP? If so README.i18n should be changed. I might have missed something but what exactly do you think needs to be changed in README.i18n? I read in the thread that the GTP contact address is dead, if this is the case and it was mentioned in the README we should have changed it. However the broken address seems to come from somewhere else so this is a non-issue for us. yes, a non issue. The dead address was the e-mail for the pt_BR coordinator's e-mail. I found his up to date e-mail in another free software related list (and warned him that the GTP page should be updated). I am now in touch with the guys at the pt_BR gtp team, and I will be able to help there with the Gimp. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer Combination Modes - what files, please?
On Monday 22 September 2003 9:33 pm, Jeff Trefftzs wrote: Hi, I've been rooting through the source for gimp-1.3.20 looking in vain for the functions that handle the layer combination modes. Can someone please point me to the right files? TIA, gimp/app/paint-funcs The easies file to have a grasp on is paint-funcs-generic.h in that directory. Just changing the auto-generated enuns in the /gimp/tools tree (and ./configuring gimp to be int the mainterner mode), you can add extra modes. However, if you are messing around the modes, please DO contact me. I am working on a Custom layer mode which I plan to have ready in time for GIMP 2.2 . This is the ONE mode to unclutter the layer modes menu. :-) I have also implemented, before my work pn the custom layer mode, an extra xor layer mode, I can send you the diff to that, or even the rendering engine of the custon layer mode which is mostly ready. Regards, JS -- 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
Re: [Gimp-developer] Layer Combination Modes - what files, please?
Sven Neumann wrote: Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: On Monday 22 September 2003 9:33 pm, Jeff Trefftzs wrote: Hi, I've been rooting through the source for gimp-1.3.20 looking in vain for the functions that handle the layer combination modes. Can someone please point me to the right files? TIA, gimp/app/paint-funcs The functions in app/paint-funcs are scheduled for removal. The composite functionality lives in app/composite now. :-) Oh well... It reminds me..it was still gimp 1.3.17 when I last had time to tweak with my custom mode stuff. I will take a look at the new stuff soon - I found the code at paint-funcs a bit messy, I just hope they got a little cleanner. Are all the old funcs gone and rewritten? or was something copy pasted? Sven Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
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
2.2 features. was: Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
Ok. let's see. Sven Neumann wrote: 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. Well, I have never enve looked at Pango. 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. If Pango thinks about providing the pdf layers itself, them I will probably check what it does, and does need improvement. 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. Ok. 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. 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. 3) Plugin to manage postscript scriptlets (scale and color) The scriptlets would live in a .gimp-2.0 subdir, and be resources just like brushes and patterns. Them provide a bunch of scritlets like: - Radial stripes - Hex. grid - Peano's curve - more. (those two are ready) This one will need GS installed. 4) Scriptable graphic turtle plugin - Actually, i've made a Python g.t. to use with the GIMP. The uses of this one would overlap with the above...maybe this one will obsolete the one above. Instead of PS, there would be a LOGO like set of statements to make scrippted drawings. Besides that, what I am looking forward most for post 2.0 are: Brush transformations - dinamically resize and rotate the brush. Seens like much of what is needed for this is done already. Maybe even working And above all!! : MACRO RECORDER (with python output, please)... :-) Is someone looking at it? it made a lot of noise here a couple of months ago. I also think we can get in touch with the scribus guys to have some of that color-correction-cmyk-CIE in place just to shut some of the said professionals up (and me no longer needing to load my images on f$$corel draw before sending them to the printer). And, why not, get a edit in the GIMP option inside scribus :-) Sven ___ 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
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
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Will you excuse me...but ..what CTRL-Y has to with REDO alltogether? CTRL + R - R is the first letter in REDO. SHIFT + CTRl + Z - Shift acts as amodifier to the CTRL + Z UNDO. CTRl + X - Stays next to Z and allows for fat toggling as has been argued. But... CTRL-Y? Why not just stick with CTRL+R? Maybe to pick the worst of both worlds? (Non standard shortcut + non mnemonic + change from GIMP 1.2 + Have to use both hands to press) Please CTRL+R for REDO, and for California Gov.! Sven Neumann wrote: Hi, Raphal Quinet [EMAIL PROTECTED] writes: On Thu, 2 Oct 2003 08:34:25 +0200, David Neary [EMAIL PROTECTED] wrote: If this is an almost-concensus (only myself, Alan Horkan and Raphael seem to like the change), it seems reasonable to revert the redo shortcut to Ctrl-R. Please don't. If you replace the current Ctrl-Shift-Z by something else, try to replace it by something that is used by some other applications, such as Ctrl-Y. Do not bring back the old Ctrl-R. Unless Ctrl-Y collides with another suggested shortcut in the HIG, it seems like a reasonable choice then. We should ask the HIG people to make this the suggested Redo shortcut. BTW, as Guillermo already pointed out, there are some more shortcuts, like for example the one for Duplicate, where the HIG differs from our defaults. We should consider to change these. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 1.3.21 made it to slashdot.
Thanks to the native SVG support! :-) Surelly, it would be a nice time to have the new site in place already. JS -- http://slashdot.org/article.pl?sid=03/10/07/130202 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp 1.3.21 is on slashdot
That means that over the next hours, tens of thousands of people will point there browsers to www.gimp.org. Some people in the foruns, including me, have provided links to mmmaybe.gimp.org. However, the latest release on mmmaybe is 1.3.17. Could 1.3.21 be announced there in the next minutes? Also, it would be fine if someone could get a 1.3.21 Windows build soon. Regards, JS -- PS. I am not a subscriber to gimp-web . ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-1.3.21, fontconfig-2.2+ configure problems
On Wednesday 08 October 2003 2:43 pm, Jeff Trefftzs wrote: Hi, On Monday I downloaded the latest gimp-1.3.21, expecting to be able to have a sparkling new version to play with by sometime that afternoon. No such luck. I'm running into the following problem: checking PANGOFT2_CFLAGS... -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include checking PANGOFT2_LIBS... -Wl,--export-dynamic -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 checking for fontconfig = 2.2.0... Requested 'fontconfig = 2.2.0' but version of Fontconfig is 1.0.1 configure: error: Library requirements (fontconfig = 2.2.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. So far this loks straightforward -- I need a later version of fontconfig, right? So I go download the fontconfig-2.2.1-4.i386.rpm and the fontcnfig-devel-2.2.1-4.i386.rpm from RedHat and try to upgrade. Well, the upgrade doesn't quite work: Mandrake 9.1 here. The update went smoothly when I set mandrake cooker as a media to URPMI. No News Good News all the way until the GIMP got running. On thing you might try is to pick up MDK rpms...or better, compile fontconfig yourself. Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Spam bad!
On Saturday 25 October 2003 4:35 am, Patrick McFarland wrote: Re: [Gimp-developer] Spam bad! On 24-Oct-2003, Patrick McFarland wrote: Nuclear weapons good! Am I the only one getting spam via the mailing list? Nope..it is hitting everybody. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: [GUG] CMYK under Gimp.
Hi there, The subject of colour management surfaced in the last days on the GUG list. I am still with no time to look at the GIMP :'-( ...but this e-mail bellow just look TOO promising. I hope someone here can take a deep look at it. :-) JS -- -- Forwarded Message -- Subject: [GUG] CMYK under Gimp. Date: Tuesday 18 November 2003 17:10 From: Alastair Robinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, I hacked together a plugin some time ago that uses the LCMS colour-management library to convert images from RGB to CMYK, using ICC profiles. Since the GIMP currently has no method of storing CMYK image data internally, I create a collection of layers, one for each channel, and use a custom save routine to create a CMYK TIFF from the layers. The plugin can be found here: http://www.blackfiveservices.co.uk/separate.shtml While there's plenty of room for improvement, the plugin as it stands (with its source code) may give you some insight into what would be required for a more permanent solution... All the best, -- Alastair M. Robinson Email: [EMAIL PROTECTED] -- You know you've been hacking too long when... ...you wake up at 3:00am from a nightmare, and realize the reason for it: There is no #include stdio.h in the beginning of the dream!!! This realized, back to restful sleep... ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Weekly Progress Report on GIMP development
Hi Monis, is: gimp_path_get_point_at_dist working like the old one? I have a really cool script that renders a POV-ray sweep alogn a path that uses this. It will work in 2.0, or I will have to keep 1.2 around. :-) Anyway, I cannot spare time right now to write PDB's :-( (I had done it once, and might do again), but I will see if I can send you a more detailed e-mail on the process soon. Regards, JS -- On Thursday 20 November 2003 21:31, Simon Budig wrote: David Neary ([EMAIL PROTECTED]) wrote: Simon Budig wrote: Sven Neumann ([EMAIL PROTECTED]) wrote: - A couple of other issues with the libgimp* APIs have been resolved. The APIs should be ready for GIMP-2.0 now. Only the addition of libgimpthumb is still missing in CVS. With the notable exception of vectors stuff. Or did I miss something? Whatr changes to the vector tool will require libgimp API changes before 2.0? I wasn't aware of any... It is not the *Tool* itself, it is the vectors infrastructure. The Problem is, that the new vectors infrastructure provides more functionality than the old stuff. The compatibility API works with the new infrastructure, but is limited to the old functionality, in particular you cannot create a vectors object with multiple open strokes in it (Look at gimp-path-set-points: BEZIER_MOVE not only moves to a new location, but also closes the previous segment). So we need a new API that makes it possible to create that kind of vectors via PDB. Since we internally already have functions like bezier_stroke_new_moveto, bezier_stroke_curveto, bezier_stroke_arcto, etc. it would be nice to have them available for plugins too, since they make creation of bezier strokes really easy. I think I failed to communicate that properly, but I always considered this to be part of the new vector stuff - and this is the IMHO last part that is missing. I am scared a bit, because I have no real idea how that PDB stuff works. I hope this makes it clear what is wrong there. Oh, I forgot: Functionality-wise also missing is a GUI for the dashed strokes, but a) it is probably fairly easy and b) we might be able to live without it... I think I should describe what I have in mind for the UI, if someone wants to pick that up I'd be very happy about that. The description of a dashed stroke is an array of doubles: length stroke, length gap, length stroke, length gap, etc. the unit of these floats is the width of the stroke, this has the nice property, that it is scaling independant. The Widget to define this could look like this: [ === == = ] and you can paint with the mouse into it - either simply flip the pixels between black and white where the mouse gets dragged over, or stick to black/white painting when clicking on a white/black pixel. The widget should be able to provide the doubles mentioned above, maybe we need to two additional value-entries for overall dash-pattern length and the dash-offset at the beginning of the stroke. Any takers? Bye, Simon -- 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
Re: [Gimp-developer] About libgimp/gimpmisc* files
No vacancy here On Sunday 23 November 2003 13:56, David Odin wrote: gimpmiscui.h also defines the gimp_plug_in_get_path() function which is only used by the FractalExplorer, gfig, and gflare plug-ins. This function doesn't look really useful, since it is only a wrapper for gimp_gimprc_query(), with some error-checking. I would vote to remove it. Anyway, even if we keep it, it should at least be moved to libgimp/gimppaths_pdb.c. gimppaths_pdb.c is related to path (vector) objects. This gimp_plug_in_get_path seems to relate to filesystem paths. We better think of somewhere else for it to live. Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Default values for window management settings
On Tuesday 25 November 2003 11:42, Tino Schwarze wrote: Although I have a strong opinion against click-to-focus, it's probably the most widely used default and expert users are used to changing this setting anyway, so the default makes sense. However, it would be great, if the window manager's focus policy could be determined and the default changed acccordingly (since activate-on-focus will complicate things with a point-to-focus policy) I had an Horrible Experience (tm) regarding this yesterday. I was making a title in Gimp 1.3.23, and was using 140pt font. Suddenly, by accident I flipped the mouse wheel over the unit listbox ..it changed from PT to IN hell came over on my desktop. before I could do much, the keyboard froze as the GIMP tried to allocate more memory than avaliable in the whole city - I managed to xkill the gimp, but the X server remained frozen. I had to remote login and kill the X process. Since this the whole issue is not strictly related to activate on focus, but on memory consumption by the Text plugin, Sven, do you think it would be feasible to put a warning on the font-size selectors, just as there are when one tries to create an image too large? Bye, Tino. -- regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Discussion on transparency
Other effects aside, I am all for preserving the RGB values of each pixel, regardless of it's alpha value. If there is garbage in there, once the mask has the alpha channel, it can be selected by color and one can cut away the previously transparent areas quite easily. Also, the nominations copy from alpha channel and move to alpha channel sound clear enough, while layer's alpha channel by it is own was very obscure to me when I met it first time. Regards, JS -- On Friday 28 November 2003 16:30, [EMAIL PROTECTED] wrote: There's been some controversial discussion in bug #127930 http://bugzilla.gnome.org/show_bug.cgi?id=127930. Raphaël proposes a discussion in this mailing list if we're not convinced about it. Well, I'm not. Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Discussion on transparency
On Monday 01 December 2003 19:00, David Neary wrote: (...) And Alpha channel to Layer Mask is unclear? If there is an action of copy alpha to mask and one other of move alpha to mask, then alpha to mask, IMO, is not clear. Actually I dislike the way they are spelled right now (/me run yesterday's compile from the GIMP) hmm..there they are, under initialize layer mask to: Layer's alpha channel and Transfer Layer Alpha Channel Yes...definetly seems like copy layer's alpha channel will be easier to understand at first sight. Transfer or move are both good. Cheers, Dave. -- 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
Re: [Gimp-developer] Here Be Bounties
Since it talks specifically about GIMP python, which me, by chance, was trying for the very first time in gimp 1.3 (no kidding --- I've been on gimp 1.2 with my python fu stuff so far), it is interesting to mention that as of now gimpImage neither gimp.pdb.gimp_image_new seens to be working. Therefore it is currently impossible to create a new gimp image from python. I am posting it here instead of bugzilla just to check if I am missing something obvious. JS -- On Sunday 14 December 2003 15:41, Sven Neumann wrote: Hi, I'd like to draw your attention to this URL: http://www.markshuttleworth.com/bounty.html Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- 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
Re: [Gimp-developer] Here Be Bounties
On Sunday 14 December 2003 21:29, Manish Singh wrote: On Sun, Dec 14, 2003 at 09:24:54PM -0200, Joao S. O. Bueno wrote: On Sunday 14 December 2003 18:36, Manish Singh wrote: On Sun, Dec 14, 2003 at 05:41:59PM -0200, Joao S. O. Bueno wrote: Since it talks specifically about GIMP python, which me, by chance, was trying for the very first time in gimp 1.3 (no kidding --- I've been on gimp 1.2 with my python fu stuff so far), it is interesting to mention that as of now gimpImage neither gimp.pdb.gimp_image_new seens to be working. Therefore it is currently impossible to create a new gimp image from python. I am posting it here instead of bugzilla just to check if I am missing something obvious. What exactly are you seeing? It works fine here. I just tried to create a new Image from the python console,a nd got this: b=gimp.Image (1, 640, 480) Traceback (most recent call last): File console, line 1, in ? error: could not create image Try b = gimp.Image(640, 480, RGB) I'm not sure where you got the 1, idea from, it's not like this in pygimp 1.2 either. -Yosh It was just that. I tried the parameters in the wrong order - the documentation is ok on the PDB, but I was looking for documentation at the Python Image object, and when I did i not find it, I just forgot to look anywere else. Thank you. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphael, can I ask you a thing? You could maybe just add (or ask someone to add) a zero-out transparent pixels on the layers menu. This will make you possibly happy, and will NOT arbitrarily throw away data that is relevant to more than one group of users as this thread had shown. Maybe, if you want to be really picky and selfish about this - there are far more usability issues in GIMP as it is now - them instead of a menu option one have to actively click, there could be added an entry in preferences. Something like Automatically destroy color data from transparent pixels. Or some name equally warnfull about what it does. With that, GIMP could be kept for Image Manipulation thats why we use it for. However, I would agree that such an __option__ - to zero out data pixels - should be added to the .png save filter. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
PNG zeroing transparent pixels. Was.. Re: [Gimp-developer] Handling of transparent pixels
Ok, I managed to change my png plugin to handle cleaning out all transparent pixels. What do you say? Is it interesting to go in right now? If it is a PNG recomendation, then it might be a nice add on, and it is small enough to go in even now, before the first pre-2.0. a 640x480 pix image with a transparent hole of about half it's size got a 15% file size decrease. I will polish my changes a little and submit the patch do bugzilla. If anyone wanna try it, just tell me now. JS -- On Tuesday 16 December 2003 10:31, Joao S. O. Bueno wrote: Raphael, can I ask you a thing? You could maybe just add (or ask someone to add) a zero-out transparent pixels on the layers menu. This will make you possibly happy, and will NOT arbitrarily throw away data that is relevant to more than one group of users as this thread had shown. Maybe, if you want to be really picky and selfish about this - there are far more usability issues in GIMP as it is now - them instead of a menu option one have to actively click, there could be added an entry in preferences. Something like Automatically destroy color data from transparent pixels. Or some name equally warnfull about what it does. With that, GIMP could be kept for Image Manipulation thats why we use it for. However, I would agree that such an __option__ - to zero out data pixels - should be added to the .png save filter. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- 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
Re: [Gimp-developer] Handling of transparent pixels
Actually, this will be quite possible with the custom layer mode I was cooking a couple months ago, and which I plan do revive to Gimp 2.2 .. As an effect that applyes to the layer itself,like the dissolve layer mode, instead of on combinations, it is doable there. One will just have to write the effect (if he's writiing from scracth, here will be a handfull of pre-made custom layer modes) ST=0; VT=V1; LT=L1 , to mean that targets HSV are set to zero, self, and self, respectively. The RGBA values per pixel are kept unchanged by the Custom Layer Mode. On Tuesday 16 December 2003 17:40, Adam D. Moss wrote: [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: However, the layer effects people want is (in my eyes) exactly that: apply some saturation effect to a layer that you can later change without loss of fidelity. And that'd be pretty groovy, and it'd work BECAUSE the layer effect is conceptually (and in reality) a separate processing step rather than an attribute of the data it applies to. This is precisely how I see the layer mask versus the alpha channel. --Adam - ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Tuesday 16 December 2003 21:44, Patrick McFarland wrote: I tried PS to see how it handles Alpha. I became quite frustrated. Once I deleted a part of the image and saved and reloaded it, I found *no* way of increasing the opacity of partially transparent pixels, not to mention totally transparent ones, except by painting. All adjustment tools had RGB but no A. Maybe it's just that I'm missing something because I'm not experienced with it but now I think that PS is not my kind of program. GIMP is exactly the same way. I have no way of doing alpha only operations, except when hacking up the transparency mask. My suggestion above would fix this. Colors are RGB, and Alpha is altered through the transparency mask. Curves Tool, It is the alpha manipulation per excellence, IMO. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Sunday 21 December 2003 18:37, [EMAIL PROTECTED] wrote: Raphaël Quinet [EMAIL PROTECTED] wrote: (...) I actually think Joao S. O. Buenos patch to the PNG plug-in is a nice addition/work around the optimization problem - I have yet to try it out, though. I haven't tried it either, but it could indeed be a nice addition to the PNG plug-in. And what about the TGA and the TIFF and the insert-your-favourite-format-with-alpha-here formats? Isn't it better to solve the issue in a more general way, so that the user doesn't get confused if such-and-such load plug-in doesn't include the option to load the alpha as a mask? Actually, all my patch does is to make avalilable an extra option on the PNG save dialog - a save transparent pixel color values, which is true by default. It is an extra do the PNG save that doesn't break any other thing, and give to the user control that would only be achievable by some maneuvers of making a selection based on the alpha channel, and zeroing the colors inside it, and which is useful, for instance, to make the file get better compression. If it is found to be THAT useful, it could be moved to the GIMP preferences, but either way, each file format's save plugin would have to be changed to get aware of that. In any case this would be a Gimp 2.2 matter. (And I think BUG 129472 could be merged in just now, in time to the first pre-2.0 without breaking anything) Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gradient fill not working in CVS Head
Hi there, I am going out right now, and have no time to fill a proper bug report. I was working, and noted that gradient fill is working poorly in CVS HEAD - the first color, or beggning of the first segment of the gradient, is taking up almost all the area to be filled. Anyway, the fill is far from being linear. I took a look at the Changelog and saw no gradient related stuff but the recent patch that showed up in this list. Anyway, could someone confirm the bug, and fill the bug report/fix it? Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gradient fill not working in CVS Head
On Tuesday 23 December 2003 19:40, Sven Neumann wrote: Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: I am going out right now, and have no time to fill a proper bug report. I was working, and noted that gradient fill is working poorly in CVS HEAD - the first color, or beggning of the first segment of the gradient, is taking up almost all the area to be filled. I cannot reproduce this here. It might be a problem caused by some library on my system. We have to isolate it, nonetheless. Anyway, the fill is far from being linear. If you are doing a gradient from a dark to a light color, it won't look linear unless you gamma-correct your display. The color-picker should show you that the color values are linearily distributed. Actually, it is not gamma related. I have attached the files to bug 129931 for everyone involved to take a look. Sven Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gradient fill not working in CVS Head
On Tuesday 23 December 2003 20:10, [EMAIL PROTECTED] wrote: In another message you wrote: I was working, and noted that gradient fill is working poorly in CVS HEAD - the first color, or beggning of the first segment of the gradient, is taking up almost all the area to be filled. Have you checked the Offset setting? It's supposed to do exactly that. Like Homer would have said: bigger DOH! /bigger Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
I've tried Simons Patch, and it seemed very nice for me. Of course I am innoi position to word out what should and should not be commited, but from a user point of view, it is nice. Unfortunately I could not check GSR's patch because of compiling issues. Regards, JS -- On Monday 19 January 2004 23:22, Simon Budig wrote: (...) Unfortunately these two patches basically exclude each other and it will come to no surprise to you, that I'd prefer to see my own patch in 2.0. However, because it is so intrusive I won't commit it until somebody read my patch and gives me the OK to do it. Bye, Simon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Anti-counterfeit software: implications for Open Source
On Wednesday 21 January 2004 13:07, Sven Neumann wrote: Hi, I'd like to draw the GIMP developer's attention on this Advogato article. It has some interesting comments and links and somehow I get the feeling that it would be unwise to ignore this subject: http://advogato.org/article/742.html What is especially worrying me is that there seems to exist a proposal for EU legislation to require devices and software to include counterfeit deterrence technology: http://www.ecb.int/pub/legal/c_25520031024en00080008.pdf This document explicitely asks for comments and IMO it would be a good idea to prepare such a comment. We could do this as the GIMP developers or try to corporate with the FSF Europe. Sven A good point to focus this discussion seens to be pointing the Central Bank to the direction of including non-printable add-ons to currency, like holograms or other things. Our (Brazil's) latest bank note already have got an holographic strip on it, and ...it would be quite hard to reproduce that in the GIMP. :-) The idea of installing anti-counterfeit protection in any imaging device is similar to the one discussed for some time about the so called analog hole - in which the movie and audio industries try to address anti-copying tecnologies even on analog devices such as VCRs. Perfect nonsense, since the ones most interested in counterfeiting would just have to make a deal with a manufacturer in China, or other country with similar capabilities to get his hardware without such protection. In the case of software, it is even easier: all a conterfeiter would have to do would be to develop his own, in house software - which could be a little harder if all existing Open Source libraries related to graphics were forbidden, but not impossible. Spammers already do that. On the other hand, this very same idea threatens the very soul of Free Software, or Open Source. It is just not feasible., as it is plain obvious. The pdf pointed to by Sven however asks for a comment that could be well constructed together with FSF Europe, showing these and other facts. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Wednesday 21 January 2004 12:27, Simon Budig wrote: Joao S. O. Bueno ([EMAIL PROTECTED]) wrote: I've tried Simons Patch, and it seemed very nice for me. Of course I am innoi position to word out what should and should not be commited, but from a user point of view, it is nice. There are two things I'd like to know. As you know Gimp avoids opening too big image windows when loading an image. Right now the size of the image area is restricted to 0.75 * screen dimensions. This of course is perfectly Ok. However, I'd like to know which of the two following behaviours is preferrable in case of an image being too big for the screen: a) open the image as big as possible (zoom-to-fit to a window about 0.75 * screen dimensions), this roughly is the behavior of current CVS. b) open the image in the next smaller zoom preset (which would result in image windows smaller than the 0.75 * screen dimensions, but would have nice ratios) (since CVS does not yet really have any zoom presets its hard to compare...) Hmm... Actually, 0.75 is sometimes boring, when the whole image would fit in, say, 90% of the screen, and it shows up zoomed out. regarding your specific question, it would not be nice if the GIMP openned an image in a zoom factor that once changed could not get easily reproduced. So the answer is (b).However, if you could make it in a way that if the next bigger zoom ratio (in the 2^(1/2) steps you use) would be no larger than 80% or maybe 85% of the screen it would be the one used. On the other hand, I was not around when the choice for 75% was made, and there may be strong motives for that. Also I'd like to know if the zoom steps around 100% are fine grained enough. Homogenous zooming right now is implemented with a factor of 2^(1/2) (from 100% to 200% in two steps), but 2^(1/3), 2^(1/4) would work as well (three, resp. four steps from 100% to 200%) and give finer grained steps. Yes, it seens just ok. I would not like to have to hit '+' four times to get a image twice as large. Now let's see what others have to say. Opinions? Thanks, Simon Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Help translating GIMP
Hi there. I am translating it into brazillian portuguese. The GIMP translations are part of the Gnome Translation Project. I had even joined the lis of the pt_BR translators. Most likely there is are nice resources to it translators to. The home page for the gnome translation projects is: http://developer.gnome.org/projects/gtp/ Browse your way from there, and don not forget to get in touch with the coordinator of the team. Regards, JS -- On Saturday 31 January 2004 09:15, Olaf Marzocchi wrote: Hi, I'd like to retranslate GIMP in italian, the current translation almost sucks. I searched the main site but I haven't found anything, couls omeone tell me how to do it? Thanks Olaf ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- 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
Re: [Gimp-developer] Funding for GIMP or CinePaint
Daniel Egger escreveu: On Feb 25, 2004, at 10:35 am, Mark Shuttleworth wrote: Image manipulation is one of the key application areas that needs to be addressed for open source tools to become the mainstream desktop environment. I'm currently funding a number of different open source projects, and am considering funding work on the GIMP or CinePaint. I can only speak for myself but being somewhat impressed by the GNOME bounty system, I'd like to recommend you the following to boot: - Identify problem areas (talk to users, let usability experts speak up, etc.) Very well them, I think that regardless Mr. Shuttlework would choose to act on these lines, this is exactly the talk to users and usability experts stage. :-) So, let´s try to make an objective time line of the GIMP, like had been outlined before, and try and guess what could be sped up if there were apropriate funding? The GIMP 2.0 is getting out AnytimeNow(tm). After that, GIMP 2.2 with a lot of enhancements, but no changes on the bit depths (but according to what I've heard from the GEGL guys, with a little GEGL already in) should follow in 6 months or so. An them, in about one year, which IMHO is optimistic seeing the pace for the 2.0 release, there would be a GIMP 3.0 whith full support to other bit depths and color spaces, due to full integration with GEGL. That is about it that has been said around here, ain't it? Now what to say? these timelines apply if most of us go working on our spare-times, with a few exceptions. Maybe with funding, more people could go fulltime/partime into the project, and say, speed up GEGL development and integration. I think this is what we could think about and tell Mr. Shuttleworth. Also, he asked reasons to support GIMP rather than, or concurrently with, CinePaint. IMHO the GIMP interface has evolved more and better than CinePaint's. But I use that program too litle to know about all of it's features - and their's todo list posted here seemed ratehr impressive. Also, the inner code of the GIMP is expected to be cleaner and easier to extend than CinePaint's. But I had not actually picked into their code. - Split up tasks in handleable subtasks - Set up a website specifying all taks and the possible money to get - Wait for people to show up and implement the tasks - Pay the money Maybe mr. Shuttleworth would rather leave these steps to us - or to the Gimp Foundation(s). The bounty is to be paid once the feature or solution has been successfully integrated into the main GIMP CVS repository and acknowledged by the maintainer(s). This IMO works much better than any global funding where misc. people benefit while others probably doing the more interesting jobs do not. Servus, Daniel Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] l10n warning
Hi there. I am updating the translation because some strings had changed on the last couple days. I thought it is interesting to mention that the string: #: app/gui/image-menu.c:1744 Which is Other (%s) ... Is copyed from another one (as fuzzy) by gettext as a _Other (%d:%d) from somewhere else. That means that in a lot of languages we will have a %d %d in a printf-like string that will get just a string as a parameter. Well, some of you will certainly know better than I what this means - and I hope it only would be an issue in plain Console C printf's, not inside the GIMP. Nonetheless, better be safe than sorry. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] l10n warning
On Friday 19 March 2004 09:56, Raphal Quinet wrote: On Fri, 19 Mar 2004 02:17:06 -0300, Joao S. O. Bueno [EMAIL PROTECTED] wrote: Other (%s) ... Is copyed from another one (as fuzzy) by gettext as a _Other (%d:%d) from somewhere else. That means that in a lot of languages we will have a %d %d in a printf-like string that will get just a string as a parameter. Let's see the good side of that: the opposite would have been much, much worse. ;-) Trying to use %s in a printf-like statement when two integers are supplied as parameters could have some consequences on the stability of the GIMP... Nonetheless, better be safe than sorry. I agree. -Raphal Ok, Currently there are these files in which this string is wrong. [EMAIL PROTECTED]:~/gimp/po$ grep -A6 #: app/gui/image-menu.c:1744 *po |grep %d ca.po-msgstr Altres (%d:%d) ... ga.po-msgstr Eile (%d:%d) ... hr.po-msgstr Drugi (%d:%d) ... lt.po-msgstr Kitas (%d:%d) ... ms.po-msgstr Lain (%d:%d) ... pt_BR.po-msgstr Outro (%d:%d) ... zh_TW.po-msgstr (%d:%d) ... [EMAIL PROTECTED]:~/gimp/po$ I had submited the changes to pt_br yesterday, I think the anoncvs just did not catch on yet. (if the gnome l10n coordinator for pt_br comitted it at all.) Someone should check again for the others just before a 2.0 final tarball. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi all, Sven, would it be too troublesome to call this release that will just finish things that have started, as 2.0.X series, instead of a 2.2 ? JS -- On Thursday 25 March 2004 14:20, Sven Neumann wrote: Hi, Dave Neary [EMAIL PROTECTED] writes: - Do a 2.2 release in about three months. I think that's unrealistically short at this stage. There are people who have said that they want to do some concrete and long-standing TODO items, and 6 weeks to 2 months is not enough time to get most of those done and debugged properly. IMHO we should rather try to finish what has started already and get these new features to our users quickly. 2 months should be sufficient to get that done. Whatever cannot be achieved in this time will have to wait for the next release then (which could be by the end of the year). (...SNIP...) Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Monday 29 March 2004 07:21, Sven Neumann wrote: Hi, Hm,, I talk that much about postscript, because I have learned it, as it is supposed to be human writable. PDF however is a neat subset, and although I know little of it, I suppose I could handle PDF saving with ADOBE docs - that is all of the bellow could be done for both PS and PDF. In the meantime, however, we will need the PDB API's for both vector and Text layers, I think them I should address these first. I will browse through the text-core today, to start to get a feeling of how it works. My idea of saving text as curves would be: - having implemented a save vectors to postscript curves (which I had done in python-fu for gimp 1.2), create a vector from text thouhgh the PDB, and them use this vector to save as postscript curves, filling with the text layer's color (which also need to come from the PDB API) Such a plug-in would need to know if a text-layer had been modified after it was stroke. Is there a flag for it already on the core? I understand that if there was no prevision for it, it may be hard to implement. /me switches to the GIMP, creates text layer, paints on it, and tries to edit the text, thus answering his own question. Good, it is there. We will need a PDB proc. for that too. You made no comments on the vector layers api, do you think they are feasible into 2.2? Joao S. O. Bueno [EMAIL PROTECTED] writes: I have also one other improvement I think I could work on, and this would be great, so I might even postpone the above PDB stuff: Postscript saving plug-in. Actually, I have a similar list of things I believe I can implement in it, more or less in this order: - Add a save one layer per page option, with metadata on postscript comments to allow reloading without loosing layer Info. - Add a rough (or maybe full) transparency support for postscript saving - Allow to save vectors as postscript paths, along with meta data to get them back on GIMP - Allow to save GIMP unstransformed text layers as postscript stroken paths - this could allow a 150dpi image with text on it to get press-ready, without great loss of information,as text would be vectorial. - Add color correction to PS save. I had a similar idea but I think that PDF output would probably be more useful. For the text layer part if may even be easier because you could use PangoPDF. But then this is a rather large task and it depends on the vectors and text PDB API. Actually it goes even further. Your plug-in would want to query the text and vector objects in the core and at the moment there's no way to do that and not even a proposal how such an API could look like. On the other hand, such a plug-in would be very useful and the PDB APIs that it needs might pave the way for lots of other neat things. Lately I've been asked to help with a plug-in that would allow to create avg description files (see http://www.libavg.de/) from within GIMP and such a plug-in would also need access to the text layer properties. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp usability tests
On Thursday 22 April 2004 15:52, David Neary wrote: I hope I'm not the only one asking myself this question... what is a CSG operation? CSG stands for Constructive Solid Geometry, and is used to refer to operations like union, intersection, add and subtracting geometric forms in a computer represented drawing. Obviously Solid doesn't apply here. :-) joke Maybe we could use CPG - Constructive Plain Geometry instead ?/joke Nonetheless, the acronym is widely used enough that I and the at least those who replied on this thread could promptly understand what it was about. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
On Friday 23 April 2004 08:10, Sven Neumann wrote: Hi, Raphaël Quinet [EMAIL PROTECTED] writes: Currently, I think that having a look at the ChangeLog is the best way (although cumbersome) to figure out who is working on what. Maybe we could make this easier by processing the ChangeLog automatically, analyzing who is working on what and publishing a list of the top contributors to each part of the code in the last N months (e.g., stats per directory in the source tree). That would not be perfect, but maybe it would be better than what we have now because this would be updated automatically. Some time ago, I wrote a script that parses the GIMP ChangeLog files and tries to figure out who are the most active developers. Maybe I should try to hack it a bit more. That sounds like something that should be done using the CVS information, not by parsing the ChangeLog. Perhaps have a look at statcvs, a CVS Repository statistic analysis tool. Would not that turn up just those who have CVS access? Maybe a mix of both. Maybe split contributors in developers and small contributors. That way, one looking on the about dialog would not have to wait ages to see your name and Mitch's, for example. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image Info Dialog
Or..press ctrl+shift + i - it is faster than hovering and guessing . On Wednesday 28 April 2004 18:42, Alan Horkan wrote: On Tue, 27 Apr 2004, Carol Spears wrote: Perhaps additional information in the status bar messages showing the selection dimensions and offsets would work? (Shown as a standard transient message, I am definately not advocating permanently grabbing a chunk of the statusbar.) I think, I hope something non-intrusive and relatively trivial could be done to make things a little bit easier, ideas? Should I file a request for enhancement? There is an enhancement request for showing the selection dimensions in Bugzilla - search for it to add your comments/requests there. As for the otehr image info, I suggest usiong the shortcut (defaults to ctrl+shift+i) to get it fast. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improving the mouse wheel zoom
I like this idea. Stan, would you mind filling this as a request feature at GIMP bugzilla? It helps developers keep track of the features wanted, and you will have some feedback on it each time it is considered, or implemented, by the developers. http://bugs.gimp.org Thank you. JS -- On Tuesday 06 July 2004 15:44, Stan Gatchel wrote: All, I really enjoy and use GIMPv2 a lot. One small improvement I recommend is when zooming with mouse wheel (shift key down) have it zoom in to the location of the cursor, i.e, instead of zooming into the frame at the center (which is what I think GIMP currently does). When I do this now, I have to adjust the window view so I can see the area of interest. But if I can tell GIMP where I want to zoom in the field of view just by pointing with the cursor, this tedious adjustment operation can be avoided. I use zoom all the time so this would be a real time saver. Thanks, Stan Gatchel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fw: [Gimp-user] So it's a layer border - not a crop frame]
On Tuesday 10 August 2004 05:53, Sven Neumann wrote: Hi, Carol Spears [EMAIL PROTECTED] writes: hi, there is an interesting discussion on the gimp-users list. i forward this because i am suggesting that the floating layer stuff be changed or even removed from this new gimp that has layers and such that work so well now for so long. I don't think this needs any further discussion. I doubt that anyone would seriously disagree that floating selections should be removed or at least reduced. The point is that it needs an experienced GIMP hacker who wants to tackle this task. Hmmm..Just for me to get a feeling on how it would work them: Instead of creating a floating selection, as it is now, a new full featured layer would come up. Maybe the anchor button could be preserved, in order to allow a quick merge with another layer of choice (either the previously used layer, from which the selection was copied or floated, or the next layer selected). I think this way all today's functionality would be preserved. Does the GIMP core treat these floating selections too different of actual layers? Or would a hack like placing a call to gimp_floating_sel_to_layer placed just after a floating selection get created do the job? (I am not suggesting that his should be the 'fix') Sven JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Newly added plug-ins - artistic?
Hi, I just tried the new photocopy, cartoon and softglow plug-ins, and IMHO, when compared to similiar ones, the correct colocation of them would not be in the artistic category. They'd better fall under distorts, maybe with softglow going into Light Effects I have not checked the wiki for menu reorganization, and do not even know if it is still scheduled, so these comments might be redundant. However, BUG #116145 activity show no big deal coming soon in menu re-arranging. Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Of time, brushes and inks
Hi there, I've been greping the code in search for a nice implementation for enhancements described in bugs 143216 (Airbrush does not take into account speed ) and 150227 (PIPE_SELECT_VELOCITY unimplemented for painting with brush pipes) Basically, both need the time information of a paint event in order to give out interesting results. The one thing in the GIMP which uses this time information is the ink tool. While a more imediate solution might be re-implementing instantiating objects that are part of the ink tool operation in other parts of the GIMP (that would have the bennefict of functionality, while avoiding code duplication, but I guess the relevand code would have to leave the .c files with an *ink* in their name), while examining the time treatemnt in app/paint/gimpink.c there is this comment circa line 248: /* The time resolution on X-based GDK motion events is bloody * awful, hence the use of the smoothing function. Sadly this * also means that there is always the chance of having an * indeterminite velocity since this event and the previous * several may still appear to issue at the same * instant. -ADM */ Meaning that the timing we currently have with the ink tool is mostly a big hack and a lot of guessing. I think that both for the Ink tool and for a much nicer implementation of the airbursh tool, and even a future eye-poping implementation of bug 119240 ( Dynamic Brush stroke panel and/or Dynamic path stroke), a clean code would need at least 1/100 of a second resolution for mouse events. So, I am not intimate with GDK, but certain of you certainly are...could we reimplement for a next generation GDK (one that will be around for GIMP2.4/3.0) a new set of time resolutions for events? Is that limited by X11? If so...maybe we can change/ask to change things as deep in the X.org project, now in use in most desktop GNU/Linux distributions. regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Of time, brushes and inks
Too much silence. I see problems here :-) Probably means most people agree with the issue, but that I am not the only one who find it a hard question to deal with. I had tought on an unclean alternative to have a higher time resolution on gdk/gtk+ events, that would be to have a core GIMP time object with higher resolution. Events would then be timed GIMP side whenever they are received. The upside: this would not depend on other projetcs to implement. The downside: if for some reason the events get delayed to be passed to the GIMP, they'd be misshandled. On Saturday 21 August 2004 01:57, Joao S. O. Bueno wrote: Hi there, I've been greping the code in search for a nice implementation for enhancements described in bugs 143216 (Airbrush does not take into account speed ) and 150227 (PIPE_SELECT_VELOCITY unimplemented for painting with brush pipes) Basically, both need the time information of a paint event in order to give out interesting results. The one thing in the GIMP which uses this time information is the ink tool. While a more imediate solution might be re-implementing instantiating objects that are part of the ink tool operation in other parts of the GIMP (that would have the bennefict of functionality, while avoiding code duplication, but I guess the relevand code would have to leave the .c files with an *ink* in their name), while examining the time treatemnt in app/paint/gimpink.c there is this comment circa line 248: /* The time resolution on X-based GDK motion events is bloody * awful, hence the use of the smoothing function. Sadly this * also means that there is always the chance of having an * indeterminite velocity since this event and the previous * several may still appear to issue at the same * instant. -ADM */ Meaning that the timing we currently have with the ink tool is mostly a big hack and a lot of guessing. I think that both for the Ink tool and for a much nicer implementation of the airbursh tool, and even a future eye-poping implementation of bug 119240 ( Dynamic Brush stroke panel and/or Dynamic path stroke), a clean code would need at least 1/100 of a second resolution for mouse events. So, I am not intimate with GDK, but certain of you certainly are...could we reimplement for a next generation GDK (one that will be around for GIMP2.4/3.0) a new set of time resolutions for events? Is that limited by X11? If so...maybe we can change/ask to change things as deep in the X.org project, now in use in most desktop GNU/Linux distributions. regards, ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
A Monday 29 October 2007 16:24:11, Sven Neumann escreveu: I suggest that we keep brainstorming for the 2.6 roadmap for another week and then collect the ideas. It would be nice if we could end with a list of well-defined tasks. When that list is collected, I would like to discuss which of these tasks should be put on the roadmap for 2.6. Hi Sevn and others, I have been obn the process of moving myself to another city over the last few weeks (almost complet now, just waiting for my mobile nad main machinne to get here). ] As soons as that happens I should consolidate my work hours and spare a few of then for GIMP. The feature I'd like to work on is a brush stroke pannel to be able to set up stroking with curves for relating pressure, speed, angle, etc with opacity, size, jitter, color, etc... One other smallf eature I will want to add is the ability to add free- angled guides. I have this almost complete on my codebase, just .XCF saving for it is missing. I should commit that early on 2.6 cycle. Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Angled guides - was Re: 2.4 and how to continue from here
A Friday 09 November 2007 13:01:06, você escreveu: Hi, On Fri, 2007-11-09 at 12:36 -0300, Joao S. O. Bueno wrote: One other smallf eature I will want to add is the ability to add free- angled guides. I have this almost complete on my codebase, just .XCF saving for it is missing. I should commit that early on 2.6 cycle. I would like to get some feedback from the UI team and from some artists on this. And of course the patch would have to be reviewed before it is committed. I am not yet convinced that this is an important feature and I also have the impression that it's just added ad-hoc without seeing the big picture. It certainly has the potential to cause a lot of problems. I had never added a UI for it - I add then through scripts. And except for bugs with the guides thenselves (which i ironed out as I developed then), I never had any side effect from using them. Snapping to these guides or intesections of these guides and others works fine. If tehre are potential greater problems, just a larger userbase would be able to detect it, and then we just fix it, or remove the feature if it needs very large changes to other program areas to work properly. And rest assured I would not commit it without having an ok from you first. Of course I'd like more feedback from users and the UI team, but nearly everyone I had mentioned this had liked the idea. It is of little use in a program like GIMP where free handed drawing is not emphasized, but sometimes it is just nice it is there. (like for stamping a brush repeating it at a gven angle). My idea for UI is just writing some code for the rotate tool to be able to rotate guides, just as the move tool can move guides. i think that once tested this won't get in anyone's path and will be a little nice feature for GIMP. regards, js -- Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
A Sunday 11 November 2007 20:48:27, peter sikking escreveu: but the real question is the priority of this yet-another-feature. something like geometry tools integration has a much higher priority than this. There eason I proposed this at this stage is that I have this feature complete minus UI and XCF saving in my GIMP tree. It has been like that for over an year when I was told it was too late to make it into gimp 2.4. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Exporting Vectors to a SVG file
A Thursday 15 November 2007 14:27:30, Lionel Tarazon Alcocer escreveu: I am developing a plug-in which makes use of SVG files to store Gimp Vectors. The Import functionality is quite straight-on due to the gimp_vectors_import_from_file(), but I haven't found a function which works the other way around. Is there a function which exports paths/vectors to a SVG file or string? Given that this is quite straight-on at the GIMP GUI (right-button over a path, Export Path), I was wondering if I had missed it at the API. thanks Hi, I have a python script that does this. It has not been updated for the new vectors API in gimp 2.4 however. Anyway you can take a look at a simple translation of gimp bezier curves to svg equivalents, without using gimp internals: http://www.pion.com.br/~gwidion/paths.tar.gz js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option for the fill tool (feature suggestion/request)
Hi Shin, I'd hardly find this useful but for some very specific patterns. Instead, I'd suggest you tried using layers and layer masks in your workflow, more or less like this: once you select the area to be filled, create an empty layer, create a layer mask on it, choose from selection (and empty your selection afterwards) There you are - you now fill the whole layer with your pattern and transform it however you like, with translation (not move tool), scaling, rotation, etc... js -- On Thursday 22 November 2007 02:14:56 pm Shin Diggar wrote: Sorry, I'm not a programmer so I wouldn't know how to do this myself but I'd like to suggest a new feature for the fill tool. How about an option to use the cursor position as a start point for tiling fill-patterns rather than the top left corner of the layer? Perhaps this could be greyed-out when fill mode is set to colours rather than patterns. I still want the whole layer/selection filled, but wherever the cursor is when I click it is where the top-left pixel of the filling pattern should be aligned to. I'd find this useful sometimes, would anyone else? _ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changing the shape of a text layer
On Sunday 02 December 2007 01:29:39 am William Skaggs wrote: From: [EMAIL PROTECTED] I like the idea of having this functionality available. I have tried the patch and it seems very capable. There appears to be bug which presented itself when I did the following: ... Thanks for the bug report. I'll take a look at it. As a general comment, I would point out that this interface might present a problem in the future when in-place text editing is implemented. Since the primary function of the tool is text input, perhaps it would be better to require a modal key (ALT?) when adjusting the frame so that, in the future, unmodified mouse clicks could be used to specify cursor location and text selections. I hadn't thought about this, but it seems to me that it would be simpler to distinguish between clicking (used in in-place editing) and click-and-drag (used for modifying shape). I actually dislike the idea of having clicking modes - We might have clicking locations - ike, clicking in the handlers always do resize, and just draw the handlers so that no text falls inside them. Certain programs that do use the two modes for editing and dragging the text container are an absolute PITA to use exactly due to this. (OOo anyone?) js -- But in general I am absolutely delighted to leave that sort of question to the wisdom of Peter and his cohorts. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] dir(gimpfu.pdb) crashes
On Monday 03 December 2007 06:19:21 am Jayesh Salvi wrote: Hi, I am trying to see what all methods gimpfu.pdb offers, by running dir() operation on it. But it crashes as follows: [EMAIL PROTECTED] plug-ins]$ PYTHONPATH=$PYTHONPATH:/usr/lib64/gimp/2.0/python python Python 2.5 (r25:51908, Apr 10 2007, 10:27:40) [GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] on linux2 Type help, copyright, credits or license for more information. import gimpfu dir(gimpfu.pdb) LibGimpBase-ERROR **: gimp_wire_write_msg: the wire protocol has not been initialized aborting... Aborted [EMAIL PROTECTED] plug-ins]$ rpm -qf /usr/lib64/gimp/2.0/python gimp-2.4.2-1.fc7 Does anyone know if this is known error? Is someone fixing it? I won't be using dir() operation in final code, but can this abort happen in other situations as well? Gimpfu module can only be imported from a python console which is run under GIMP itself. Try that from the python console within GIMP. js -- Thanks, Jayesh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at the 24C3
On Sunday 16 December 2007 09:48, Sven Neumann wrote: Hi, as announced earlier, some GIMP developers are going to meet at the 24th Chaos Communication Congress (24C3) http://events.ccc.de/congress/2007/ We already discussed that travel costs for such events should be reimbursed from GIMP donation money. For this event, I would like to transfer EUR 1000 from the GIMP account. We would use that money mainly for travel costs. Should something be left, we will spend it on pizza. Does anyone see a problem with that? Please object now or never... never. :-) Enjoy it! js -- Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc
On Wednesday 16 January 2008 17:42, William Skaggs wrote: This mixes together two separate issues. Tags are, as I have already agreed, an excellent way of doing a search mechanism. They don't get rid of the need to have a workspace, though. Suppose I want to switch back and forth between five very different brushes. Must I remember and select a set of tags each time I switch? That would be very unpleasant. No, whether or not there is a tag-based search system, there still needs to be a way for the user to maintain a workspace holding a limited set of arbitrarily chosen brushes. What about using...tags... for that? The idea of such a workspace would be that it would display brushes containing a certain tag. In teh above use case, I'd just apply a one-of-five-very-different-brushes tag to all the brushes. For this to make sense it _must_ be very easy and fast to edit a resource's tags. But that could be refined later on the development. Actually, maybe it would make sense containers that could show several types of gimp data in a single dialog. So, if I am working with trees, I'd have palettes, gradients, and brushes which show up in a single window. More than one such dialog should be allowed to be open at once, so that a user could simply drag and drop things around (and internally, tags are added/removed transparently). So ... the workflow for the case of use above would be something like: create an empty multicontainer, go to another multicontainer displaying only brushes (the equivalent of today's brushes dialog), type in a tag to the first brush, drag it into the empty new container - repeat for brushes 2-5. Start painting. When it is over, destroy the current container, or just save it under an arbitray tag name for later re-use. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc
On Thursday 17 January 2008 14:45, William Skaggs wrote: From: peter sikking [EMAIL PROTECTED] chiming in here (getting back to speed). [...] Peter! Great to hear from you again! I absolutely agree about the virtues of a tagging system, but I fear that the difficulties are not being appreciated well enough. Here, for example, is just one of the problems: Problem: should tags be stored as part of a data file, or in a separate tags-database? separate tags database - which might be a xml file, I think. 1) If they are stored as part of the data file, then this calls for a new file format for every sort of gimp resource object, and changing tags calls for file system operations. ok - this won't happen. 2) If they are stored in a separate database, keyed by file names, then there is a great danger of losing the linkage between tags and object. If, for example, the user renames the directory holding some brushes, all of the tags for those brushes will be lost. The only way to prevent this sort of thing from happening is to make sure that all operations on resource files are mediated by Gimp (or some new utility program) that will make sure to keep the tags in sync with the data files. If for some reason a user's tags database gets corrupted, it will be a major disaster. I think we just need to worry about it being a minor disaster. I can think of recover scripts that could be written to restore some tags, in case of directory renaming, for example. There are many other issues of the same sort, which I don't believe have been thought through. I don´ t think so. It looks plain straightforward for me. I have worked with many web systems that reference filesystem paths for images, for example, and never had a maintanance problem due to that. Besides, yes, gimp would need some kind of scanning through resource folders, and possibly group all resopurces tehre under an all flag. That is needed so that one can download resources and add then to GIMP through the filesystem. The bottom line is that introducing tag-based resource organization is like setting up a virtual, non-hierarchical file system. The ordinary file system may be weak in comparison, but it is extremely robust, and users know how to manipulate it. A new tag-based file system can't possibly be robust until it has had an extensive testing period, and therefore exposes a user to the worst of all disasters: a corrupted file system. The solution I favor is to build a tag-based system *on top of* a filesystem-based system. That way: 1) The tag-based system can be built gradually, instead of being imposed all at once on a flat set of files. A flat set of files become a flat set under one tag in teh worst case scenario. 2) The user can manipulate files using ordinary filesystem operations without fear of wrecking gimp. Yes, that need to happen therefore the folders where resources are expected to be, as they are today should remain, IMHO. 3) A naive user who doesn't understand tags will still be able to use Gimp without having to learn about tags at the very beginning. This one is for Peter. In short: yes, there should be resources visible in a default GIMP install, first use. Maybe we could name a Basic tag for these start-up resources. A drop down for the most used tags could be fine as well. 4) A corrupted tags database will still be very bad, but won't make Gimp completely unusable. Indeed. As I said, the scanning should be made at gimp-load, and any resources found should be mapped to a default tag. Using something as simple as a hash of the entire file data could preserve all tags even when resources where moved across directories (rescanning hashest might need an explicit action) regards, js -- -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tagged resources such as brushes, gradients, etc
On Friday 18 January 2008 15:08, William Skaggs wrote: In any case, let me ask a basic sort of question about user interaction. Suppose I'm a user, painting with a set of brushes. I decide that I want to use a certain grunge brush. (Let's say I have a specific brush in mind, but all I remember about its tags is that it is a grunge brush from a set I imported last week.) What are the steps I have to take, as a user, in order to find the new brush and start using it, without losing access to the other brushes I am currently using? (I'm willing to assume that if I load everything with the grunge tag, I will be able to find the brush I want in there.) Of couse, this will have to be refined by the UI team. But I have two ideas for it: one would be abel to type in tags into a dialgo shwing brushes without lossing the ones already selected. Like, just typing more tags on the tag text entry widget, and having tehn combiend as or. The other one, is to allow the user to pop up another brushes dialog, in which he perfomes hs searches, He then can either select brushes from this ne dialog, or drag brushes from there to the first one, where they are transparently added to the group tag in use on the first window. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Libre Graphics Meeting 2008 - call for presentations
On Monday 25 February 2008, kamila giedrojc wrote: Dear GIMP team, Hi, I've added a talk I'd like to give there: http://create.freedesktop.org/wiki/index.php/PythonTalkLgm3 It goes well beyond GIMP, but I hope it is ok for everybody. js -- Libre Graphics Meeting 2008 is few steps from here. We are currently working on the program. I'm sure I can count on you. This week we are waiting for the emails from everyone who did not yet contact us, and would be interested in giving a talk, or conducting a workshop. I'd be grateful to get your responses up to March 2nd. You can also subscribe as a presenter in conference wiki http://create.freedesktop.org/wiki/index.php/Conference Don't hesitate to contact me if you have any questions. Cheers! Kamila --- Kamila Giedrojc Official Organiser Libre Graphics Meeting 2008 - Wroclaw kamila.giedrojc [at] gmail [dot] com www.libregraphicsmeeting.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC 2008
Hi, Iṕ've been talking to Schumanl and Prokoudine this afternoon, and they agreeded to indicate me to be GIMP's Google Summer of Code Admin (mostly: contact person), for 2008 edition. I am willing to pick the role, but I have to know if everyone agrees, or if someone else would like to do it (Iḋ'd still colaborate). Regardless of that the window for registration starts next Monday and it will be somewhat short. So we have to get things ready at http://wiki.gimp.org/gimp/SummerOfCode2008application and even more important (as this application is most bureacratic stuff I can fill in), we have to arrange the ideas we'd like to see implemented in this years' project - here http://wiki.gimp.org/gimp/SummerOfCode2008ideas We have up to March, the 12th to have this in order. If I am in charge I'd prefer doing it even earlier. This is not unmutable though, and even applying students can suggest their own ideas. And more important than filling the application, and having the ideas, are _mentors_ ! So people willing to mentor students, please do so at the application wiki page, and possibly indicate which ideas you would like to mentor. Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
